Transition between private and non-private state

Abstract

A method implemented using one or more processors, comprising: examining an ongoing message exchange thread involving at least one human participant, a first automated assistant, and a second automated assistant; determining, at least in part based on the examination, a probability that one or more messages added to the message exchange thread by the at least one human participant or the first automated assistant are considered private by the at least one participant, the probability being determined based on the message exchange thread content and sensor-based data; and establishing that the determined probability satisfies one or more thresholds.and in response to the finding that the determined probability meets one or more thresholds, the omission of storing one or more messages exchanged between the first automated assistant and the second automated assistant in a message log, wherein the probability is determined based on the detection of one or more N-grams classified as sensitive in the current message exchange thread, and the one or more N-grams are classified as sensitive based on the historical behavior of a multitude of participants in a multitude of message exchange threads outside the current message exchange thread.

Description

background Message exchange threads, such as chat, email exchanges, text messaging, etc., can contain information that may be sensitive (e.g., confidential) to one or more of the participants. A participant in the message exchange thread may wish that at least some of the thread's content is not retained in its original, sensitive form (e.g., in a log) or at least made available. Many internet applications allow a user to switch the application to a private state (e.g., "confidential," "incognito mode," "private," etc.) if the user is about to engage in an activity they consider sensitive. However, this transition—especially with message exchange clients such as chat clients, text messaging clients, email clients, etc.—must, in most cases, be initiated manually by the user.Furthermore, the user must also change the application's state from private; this does not usually happen automatically, especially in messaging clients. Consequently, information that a user would otherwise prefer to keep confidential or not retain at all may have been inadvertently preserved (e.g., in a message exchange log, as a copy of a message exchange thread, etc.) because the user forgot to change the application's state to private. This preserved information could potentially be exposed to unauthorized participants. Likewise, the user may inadvertently lose content that they would otherwise prefer to keep if they forget to change an application, such as a chat client, from a private state. Summary The subject matter of this patent is defined by the independent claims. This patent is generally directed to techniques for automatically transitioning applications—especially those that enable the exchange of messages between users (e.g., messaging clients such as chat applications, email clients, websites that allow message threads, etc.)—into (and in some cases out of) a private state based on a variety of signals associated with the messages and / or the participants themselves. When in the private state, information considered sensitive (e.g., confidential) can be obfuscated (e.g., by scrambling names or other sensitive words or phrases), or the application can refrain from storing the sensitive information (e.g., in a log or in a message thread copy). Automatically transitioning applications to (and in some cases from) a private state can offer several advantages. These can include reducing the amount of interaction required between the user and their device, thereby decreasing the processing and overhead necessary to handle this information. Furthermore, in some cases, it can improve the security of user data, as the data may not be stored or may be obfuscated. In various implementations, an ongoing message exchange thread between one or more participants can be examined, for example, by individual message exchange clients operated by the participants themselves, and / or centrally by one or more servers that enable the message exchange thread. Based on this examination, a probability can be determined (e.g., calculated) that one or more messages sent by one participant to another as part of the ongoing message exchange thread will be considered private by at least one given participant. This probability can be determined in various ways based on different signals. In some implementations, the probability can be determined based on the content of one or more messages. For example, certain expressions in some implementations can be classified as "privacy trigger expressions" which, when detected, cause one or more message-sharing clients operated by a participant in the current message-sharing thread to enter a private state. These privacy trigger expressions might include expressions such as "confidential," "Let's keep this between us," "Can you promise not to tell anyone?", and so on. In some such implementations, one or more messages that follow (and in some cases precede) such a privacy trigger expression can be unlearned, e.g.,, until a user manually moves a messaging client out of private mode or until it is detected that the subject of the discussion has changed to a less sensitive subject. In other implementations, certain n-grams or combinations of n-grams (whether adjacent or not) can be used to trigger the transition to private state. For example, suppose a user in a message-exchange thread provides the statement: "I heard Bill is getting fired because he was caught stealing money." n-grams such as "fired," "caught," and "steal" can trigger the transition to private state alone or together. In some implementations, one or more of the n-grams, along with an entity name (e.g., "Bill"), can trigger the transition to private state. In some such implementations, the statement can be obfuscated in private state (e.g., "I heard that * is getting fired because * was caught stealing money") if it (e.g.,(as part of a copy of the message exchange thread), so that potentially user-identifying n-grams are no longer available. In other implementations, the entire statement can be redacted or simply not stored in the message exchange thread copy. Additionally or alternatively, some implementations may use one or more other signals associated with one or more message exchange participants to determine the probability that one or more messages exchanged in the message exchange thread would be considered private by at least one participant. In some implementations, historical behavior associated with one or more of the message exchange thread participants, or in some cases, associated with message exchange thread participants generally (e.g., participants in other message exchange threads), may be considered. This historical behavior might, for example,This includes the browsing history of one or more participants, the historical use of a browser's private state by one or more participants, the historical use of a private state associated with a message exchange client by one or more participants, and so on. For example, it is assumed that one or more employees in an employee-enabled message exchange thread manually move their respective message exchange threads into a private state each time a particular item is discussed as part of the employee-enabled message exchange thread. In various implementations, this historical behavior associated with these employees can be "learned" so that similar behavior can later be detected and trigger the automatic transition to a private state. In some implementations, one or more trained machine learning models, such as convolutional neural network models and / or recurrent neural network models, can be used to determine the probability that message exchange content would be considered private by one or more participants. For example, a machine learning model can be trained using tagged training examples associated with instances in which message exchange thread participants manually transferred message exchange clients into private states. Features of these training examples might include, for example, one or more n-grams contained in the message exchange thread, expressions (e.g., "Can you keep this between us") contained in the message exchange thread, contextual clues (e.g., participants' identities, participants' locations, etc.).), historical user behavior associated with one or more participants, etc. Once the machine learning model has been trained, it can be applied to multiple inputs, for example, on individual computing devices running message-exchange clients or on central nodes enabling message-exchange threads, to determine the probability that, given inputs, one or more message-exchange thread participants would consider at least part of the message-exchange thread private. In some implementations, such machine learning models can be stored on and / or applied to the computing devices of individual participants. In various implementations, the probability that a particular message exchange thread participant would consider at least part of a message exchange thread to be private can be compared to one or more thresholds. The probability can be calculated numerically (e.g., in a range of 1 to 100, 0.0 to 1.0, etc.) and compared to a minimum threshold (e.g., 60, 0.7, etc.). If the probability exceeds the minimum threshold, a message exchange client operated by the message exchange thread participant can be converted to a private state. In some implementations, a request can be provided to the participant (e.g., by the message exchange client) requesting permission to convert the message exchange client to a private state. In other implementations, no such request is required.In yet other implementations, permission to transition to the private state can only be requested if the probability measure meets a first, minimum threshold (e.g., 50, 0.5), but not a second, e.g., higher threshold (e.g., 80, 0.8). If only a single participant's message exchange client enters a private state, the message exchange thread content, which is potentially considered private, cannot be held on that participant's computer device but may instead be held on the computer devices of other participants. Accordingly, in some implementations, if a single participant's message exchange client enters a private state, that client (or another component, such as a central, cloud-based component managing the message exchange thread) can issue a command to the message exchange clients of other participants to enter private states. In some implementations, the other participants may be prompted for permission (e.g., with an explanation of why) to enter the private state.In other implementations, the message exchange clients of other participants can be automatically switched to a private state. In some implementations, a procedure executed by one or more processors is created that includes: examining an ongoing message exchange thread between two or more participants, each operating two or more respective message exchange clients; determining, at least partially based on the examination, a probability that one or more messages sent by one of the two or more participants to another of the two or more participants as part of the ongoing message exchange thread would be considered private by at least one given participant of the two or more participants; and determining, by one or more of the processors, that the determined probability satisfies one or more thresholds.and converting one or more of the two or more message-exchanging clients into a private state in response to the determination that the specified probability meets one or more thresholds. These and other implementations may optionally include one or more of the following features. In various implementations, determining the probability may be based, at least in part, on the content of one or more messages that form part of the ongoing message exchange thread. In various implementations, determining the probability may also be based on historical behavior associated with the given participant. In various implementations, the historical user behavior may include the browsing history of the given participant. In various implementations, the historical user behavior may also include the historical use of a private state associated with a web browser by the given participant.In various implementations, historical user behavior can include the historical use of a private state associated with a message exchange client by the given participant. In various implementations, determining the probability can also be based on historical behavior associated with two or more participants in the running message exchange thread. In various implementations, determining the probability can also be based on historical behavior associated with multiple participants in multiple message exchange threads outside the running message exchange thread. In various implementations, the historical behavior associated with multiple participants in multiple message exchange threads can include one or more mappings between the content of one or more messages exchanged in the multiple message exchange threads and a manual transition of the respective message exchange clients into a private state by one or more of the multiple participants. In various implementations, determining the probability can involve applying multiple inputs associated with the given participant to a neural network model, where the neural network model is trained to provide an output containing the probability based on the multiple inputs. In various implementations, the neural network model can be stored on a computer device used by the given participant to participate in the running message exchange thread. Alternatively, in various implementations, the neural network model can be downloaded to the computer device used by the given participant, and the neural network model can be trained using training examples obtained from multiple message exchange threads outside the running message exchange thread.In various implementations, the procedure can further involve transmitting a command that causes the second message-exchange client to enter private state from a first message-exchange client (one of two or more) to a second message-exchange client (one of two or more), with the transmission occurring in response to the determination that a certain probability of one or more thresholds is met. Thus, a first client can control a second client to enter private state, thereby reducing user interaction on the part of the second client. Furthermore, it can potentially eliminate the need to determine separately for each client whether to enter private state.Instead, the determination can be executed only with respect to the first client, with the second client also being controlled based on this determination. This can reduce overall processing. In various implementations, one or more of the two or more message-exchange clients in the private state can obfuscate at least part of a log of messages exchanged as part of the running message-exchange thread. In various implementations, one or more of the two or more message-exchange clients in the private state can at least temporarily refrain from updating a log of messages exchanged as part of the running message-exchange thread. In various implementations, the procedure may further include a given message exchange client providing a request for permission to transition the given message exchange client into the private state, in response to the determination that the probability meets one or more thresholds. Furthermore, some implementations include one or more processors of one or more computer devices, wherein the one or more processors are operable to execute applications stored in allocated memory, and wherein the applications are configured to cause the execution of any of the procedures mentioned above. Some implementations include at least one non-transitory, computer-readable storage medium that stores computer instructions executable by one or more processors to perform any of the procedures mentioned above. It should be noted that all combinations of the foregoing concepts and additional concepts described in more detail herein are considered to be part of the subject matter disclosed herein. For example, all combinations of the claimed subject matter appearing at the end of this disclosure are considered to be part of the subject matter disclosed herein. Brief description of the drawings Fig. 1 is a schematic representation of an exemplary environment in which implementations disclosed herein can be implemented. Fig. 2 shows an example of using components of the exemplary environment from Fig. 1 when triggering an application transition to a private state. Fig. 3 shows an example of using components of the exemplary environment from Fig. 1 when training one or more machine learning models. Fig. 4A and Fig. 4B each show an exemplary client device and one or more examples of how a private mode can be triggered automatically. Fig. 4C shows an example of a message exchange thread copy that has been partially obfuscated. Fig. 5 is a flowchart that shows an exemplary procedure for automatically transitioning an application to a private state in accordance with implementations disclosed herein.Figure 6 represents an exemplary architecture of a computer device. Detailed description Figure 1 shows an exemplary environment in which the techniques disclosed herein can be implemented. The exemplary environment includes a communication network 101, which enables communication between the various components in the environment. In some implementations, the communication network 101 may include the Internet, one or more intranets, and / or one or more bus subsystems. Optionally, the communication network 101 may utilize one or more standard communication technologies, protocols, and / or interprocess communication techniques. Furthermore, the exemplary environment includes one or more client devices 1061-N, an electronic communications system 110, a privacy state system 120, a training engine 135, and a training example engine 137. The exemplary environment also includes user data 158, training examples 152, and one or more machine learning models 156. The user data 158, the training examples 152, and the one or more machine learning models 156 can each be stored on one or more appropriate computer-readable media. Some non-restrictive examples of one or more client devices include: 1061-N, which include one or more of the following: a desktop computer device, a laptop computer device, a tablet computer device, a mobile telephone computer device, a vehicle computer device (e.g., a vehicle communication system, a vehicle entertainment system, a vehicle navigation system), a standalone interactive loudspeaker (e.g., a so-called "smart speaker"), or a wearable device that incorporates a computer device (e.g., a watch with a computer device, glasses with a computer device, a virtual or augmented reality computer device). Additional and / or alternative client devices may be provided.For various examples presented, it is assumed that client device 1061 is a client device of a first user, that client device 1062 is a client device of a second user, that client device 1063 is a client device of a third user, and so on. However, it should be noted that the privacy status system 120 can be connected via an interface to any of several client devices and / or other electronic devices of a given user that form a coordinated “ecosystem” of client devices of that given user. For example, user data 158 used by the privacy status system 120, as described here, may include sensor-based data and / or other data based on client device 1061, as well as other data based on other electronic devices of a user of client device 1061.However, for the sake of brevity, some of the examples described in this revelation focus on a single client device of a corresponding user. The electronic communication system 110, the privacy status system 120, and / or the engines 135 and / or 137 can each be implemented in one or more computer devices that communicate, for example, over a network (e.g., over network 101 and / or another network). The electronic communication system 110, the privacy status system 120, and the engines 135 and 137 are exemplary components through which the systems and techniques described herein can be implemented and / or with which the systems and techniques described herein can be interfaced. They can each contain one or more memories for storing data and software applications, one or more processors for accessing data and executing applications, and other components that enable communication over a network.In some implementations, the electronic communication system 110, the privacy status system 120, and / or the engines 135 and / or 137 may include one or more components of the exemplary computer device shown in Fig. 6. The operations performed by the electronic communication system 110, the privacy status system 120, and / or the engines 135 and / or 137 may be distributed across multiple computer systems, which may wholly or partially include one or more client devices 106. In some implementations, one or more aspects of the electronic communications system 110 and / or the privacy status system 120 and / or the engines 135 and / or 137 may be combined in a single system and / or one or more aspects may be implemented in one or more of the one or more client devices 1061-N. For example, the client device 1061 may contain an instance of one or more aspects of the privacy status system 120, and each of the additional one or more client devices 1062-N may also contain an instance of one or more aspects of the privacy status system 120. As another example, each of the one or more client devices 1061-N may each contain an instance of the electronic communications system 110 (where the electronic communications system 110 may be, for example, an application installed and running on each of the devices).As yet another example, one or more aspects of the electronic communications system 110 and the privacy status system 120 may be combined. The Electronic Communications System 110 can include one or more remote servers and / or one or more client-side applications dedicated to exchanging one or more types of electronic communications between client devices (often referred to here as "message exchange threads"). Types of electronic communications that can be exchanged in a message exchange thread include, for example, emails, Rich Communication Services (RCS) messages, Short Message Service (SMS) messages, Multimedia Messaging Service (MMS) messages, Over-the-Top (OTT) chat messages, social networking messages, audible communications (e.g., telephone calls), audio-video communications, and so on.As an example, the electronic communication system 110 can contain one or more remote servers that manage message exchange threads between different client devices 106, and these different client devices 106 can optionally each contain a corresponding message exchange client 107. As another example, the electronic communication system 110 can be implemented solely via client-side applications running in corresponding client devices. Examples of the privacy status system 120 are described with respect to a user of the client device 1061. When users operate client devices 106 in general (e.g., 1061, ...) to participate in message exchange threads, these users can be referred to as message exchange thread "participants." In some implementations, the privacy status system 120 can be implemented wholly or partially in the client device 1061. In some implementations, one or more of the components of the privacy status system 120 can additionally or alternatively be implemented in one or more servers that are remote from the client device 1061. For example, one or more components can be implemented in a remote server of the electronic communications system 110. In various implementations, the privacy state system 120 may include a data engine 122, a privacy probability engine 124, a privacy transition engine 126, and / or a feedback engine 132. In some implementations, aspects of engines 122, 124, 126, and / or 132 may be omitted, combined, and / or implemented in a component separate from the privacy state system 120. The data engine 122 selects user data 158 for use in determining the probability that a message exchange thread participant would consider an ongoing message exchange thread to be sensitive. In some implementations, the user data 158 includes sensor-based data generated from sensor outputs of the client device 1061 and / or one or more other electronic devices of the participant. In some implementations, the user data 158 additionally or alternatively includes computer-based action data generated from participant activity via the client device 1061 and / or one or more other electronic devices of the participant. In some implementations, the user data 158 additionally or alternatively includes historical data indicating historical behavior associated with the participant.In some implementations, this historical behavior may include the participant's browsing history, the participant's use of a private state associated with an application such as a web browser, a chat history, and / or the participant's historical use of a private state associated with the message exchange client 107. In some implementations, user data can contain 158 aggregate data points associated with multiple users (or message exchange thread participants). For example, in some implementations, the aggregate data can specify historical behavior associated with two or more participants in a running message exchange thread and / or behavior associated with multiple participants in multiple message exchange threads outside of the running message exchange thread. In some implementations, the historical behavior associated with multiple participants in multiple message exchange threads can include one or more mappings between the content of one or more messages exchanged in the multiple message exchange threads and a manual transition of the respective message exchange clients into private states by one or more of the multiple participants.As described here, the user of the client device 1061 (i.e., the participant) can be given an opportunity to control whether and / or which user data 158 the data engine 122 and / or other components of the privacy status system 120 can access. Sensor-based data can be generated, for example, based on output from a global positioning system (GPS) sensor, an accelerometer, a microphone, a camera, a gyroscope, and / or one or more other sensors. Sensor-based data can include sensor output data (e.g., output as received by the sensor) and / or generalized sensor data determined based on output from one or more sensors. For example, the sensor-based data can include audio output data from a microphone and / or one or more generalizations of that audio output data. These generalizations can include, for example,The data may include an average decibel level (and / or another statistical measure of decibel level) over a period of time, one or more classifications of the audio output data based on applying the data to a classifier (e.g., one or more classifications such as "noisy," "quiet," "music," etc.). As another example, the sensor-based data may additionally or alternatively include GPS output data and / or one or more generalizations of the GPS data. These generalizations may include, for example, a classification of a location specified by the GPS data (e.g., a restaurant, a movie theater, a gym), a specific location specified by the GPS data (e.g., Restaurant A, Movie Theater A), etc.As yet another example, the sensor-based data may additionally or alternatively include accelerometer output data and / or one or more generalizations of such data. These one or more generalizations of the accelerometer output data may include an average velocity (and / or another statistical measure of velocity) based on the data from the accelerometer, one or more classifications of activity based on the application of the data to a classifier (e.g., one or more classifications such as "running," "walking," "standing"), etc. Computer-based action data generated based on user activity via the client device 1061 and / or via one or more other electronic devices of the user may include, for example: calendar entries and / or other electronic documents generated via the one or more devices; one or more documents with which interaction is performed (e.g., accessed) via the one or more devices; one or more applications currently being used or recently used via the one or more devices; one or more states of one or more applications currently being used or recently used via the one or more devices; the average processing power (or other statistical measure of processing power) consumed over a recent period; etc. The privacy probability engine 124 uses the data selected by the data engine 122 to determine the probability that a particular message exchange thread participant (e.g., a user of the client device 1061) will consider the content of an ongoing message exchange thread to be sensitive. The probability determined by the privacy probability engine 124 depends on the user data 158 and the message exchange thread content. In various implementations, the privacy probability engine 124 can receive "fresh" data from the data engine 122 continuously, periodically, or at other regular and / or irregular intervals to dynamically determine the probability that a message exchange thread participant will consider the content of the ongoing message exchange thread to be sensitive.In some implementations, the privacy probability engine 124 applies the data as input to one or more of the machine learning models 156, generates an output based on the input via this one or these multiple machine learning models 156, and determines the probability based on the generated output. The privacy transition engine 126 can be configured to transition one or more applications running in one or more client devices 106 into and / or out of a so-called "private state." As an application's "private state" is used here, it refers to an application state in which the application takes various measures to ensure that different types of information associated with the application's operation are protected, obfuscated, or simply not retained at all. For example, when a web browser is transitioned into a private state, it may refrain from storing a history of websites or other network resources visited or otherwise accessed by the web browser while in that private state.Additionally, the web browser can refrain from storing information such as cookies, user credentials, etc. while it is in a private state. In the context of message exchange client applications 1071-N, a private state can refer to a state in which the message exchange client 107 refrains from storing, obfuscating, and / or filtering messages exchanged between one or more participants in a message exchange thread and / or between a participant in a message exchange thread and a so-called "automated assistant." An "automated assistant" can refer to a software process with which a user can interact dialogically, for example, using typed text or spoken input (which can be converted to text). For example, client devices 106 in the form of standalone interactive speakers can allow users to enter into a human-computer dialogue with an automated assistant, in which the user can ask questions (e.g.,It can search for documents, find information, ask for weather / scores, etc.) and / or issue commands (e.g., play a specific song, turn on the lights, set a timer, save a reminder, etc.). Other client devices, such as smartphones, tablet computers, smartwatches, etc., may contain automated assistants that enable a similar interactive dialogue with a user. The privacy transition engine 126 can determine that the probability determined by the privacy probability engine 124 satisfies one or more thresholds. Based on such a determination, the privacy transition engine 126 can transition one or more message exchange clients 107 (or more generally, a client device 106) into a private state or trigger their transition. Various types of thresholds can be compared to a probability that the content of a message exchange thread would be considered sensitive to at least one participant. In some implementations where the probability calculated by the privacy probability engine 124 is expressed as a number or as a measure (e.g., in a range of 0.0–1.0, 0–100, etc.), a numerical threshold can be used. In some implementations, multiple thresholds can be used.For example, one or more message exchange clients 107 can provide an audible or visible output in the form of a request for permission to transition the message exchange client 107 to a private state if a probability determined by the privacy probability engine 124 meets a first threshold but not a second, higher threshold. However, one or more message exchange clients 107 operated by participants in the running message exchange thread can automatically transition to private states, with or without notifying the respective participants operating the message exchange clients 107, if both the first and second thresholds are met. In various implementations where a running message exchange thread includes multiple participants operating multiple message exchange clients 107, the transition of one message exchange client 107 to a private state may or may not result from one or more of the other message exchange clients 107 transitioning to private states. For example, in some implementations, a first message exchange client 107 transitioning to a private state may send a command to a second message exchange client, causing the second message exchange client to transition to the private state. In some implementations, this transition may occur, for example, in response to a determination by the privacy probability engine 124 that the probability meets one or more thresholds, such as those determined by the privacy transition engine 126. It is assumed that an instance of the privacy state system 120 (containing respective instances of the data engine 122, the privacy probability engine 124, and / or the privacy transition engine 126), operating in a given client device 106, determines that there is a certain probability that a participant running a respective message exchange client 107 in the given client device 106 would consider the content of a running message exchange thread to be sensitive. Furthermore, it is assumed that the probability satisfies a first threshold but not a second threshold. In some implementations, such a scenario would only cause the privacy transition engine 126 to transition the local message exchange client 107 into the private state.In other implementations, such a scenario would cause the local message exchange client 107 to enter a private state and request that other message exchange clients 107 participating in the message exchange thread also enter private states (in which case they would, for example, request permission from a respective message exchange thread participant). The feedback engine 132 can use solicited and / or unsolicited feedback from the user / participant of a client device 106 to provide it to the training example engine 137. The training example engine 137 can use the feedback when generating further training examples to refine one or more of the one or more machine learning models 156. As an example, suppose a participant in a message exchange thread manually transitions their respective message exchange client 107 into a private state. The feedback engine 132 can provide the training example engine 137 with an indication of the manual transition as well as various inputs (e.g., user data 158, content of the message exchange thread) that are currently applicable to the manually transitioning participant.The training example engine 137 can then use the data to generate a training example input of a training example, and can generate a training example output of the training example based on the manual transition of the message exchange client 107 into the private state. Figure 2 illustrates an example of using components of the exemplary environment from Figure 1 to determine probabilities that message exchange thread participants would consider the content of an ongoing message exchange thread to be sensitive. In Figure 2, user data 158 is generated based on output from sensors 204 of the client device 1061, states and / or other data from applications 206 of the client device 1061, documents 208 generated by and / or accessed through the client device 1061, and historical data 210 indicating historical behavior associated with the message exchange thread participant operating the client device 1061. The output from the one or more sensors 204 is used to generate sensor-based user data 158.The output from the one or more applications 206 and / or from the one or more documents 208 is used to generate computer-based action data of the user data 158. The historical data 210 is used to generate / identify historical behavior of the user data 158. In some implementations, the user data 158 can be generated based on output generated by sensors of additional or alternative electronic devices of the user (e.g., sensors of a user's watch that communicates electronically with the client device 1061) and / or user actions via these additional or alternative electronic devices of the user. The data engine 122 selects a subset of data 201A from the user data 158 to provide to the privacy probability engine 124. In Fig. 2, the privacy probability engine 124 can apply the data 201A, along with message exchange thread content 212, as input to one of the machine learning models 156 and generate an output based on the applied input via the machine learning model. The generated output can directly indicate a probability that the message exchange thread participant would consider the message exchange thread content to be sensitive and can be provided to the privacy transition engine 126.As an example, the input applied to the machine learning model could be a vector of values ​​based on data 201A, including values ​​based on sensor-based data, computer-based action data, historical behavioral data, and the content 212 of the running message exchange thread. The content 212 of the running message exchange thread could contain text and / or other content (e.g., images, sounds, etc.) that has been introduced into the running message exchange thread (e.g., by a participant operating a message exchange client 107). The output 203A could, for example, indicate a probability that a message exchange thread participant would consider content from the message exchange thread (regardless of whether it has already been inserted into the thread or is about to be) to be sensitive. The privacy transition engine 126 determines, based on output 203A, whether the local message exchange client 107, operating in client device 1061, should be transitioned to a private state. In some implementations, the privacy transition engine 126 also transmits, for example, privacy commands 2051-Nan to one or more other client devices 1062-N, which operate message exchange threads 1071-N and are used by participants to join the running message exchange thread. As noted above, in different implementations, the other client devices 1062-N can automatically transition to private states, they can request permission from their respective participants to transition to private states, and so on. In some implementations, the privacy transfer engine 126 transmits the privacy commands 2051-N directly to appropriate additional client devices 106. In some other implementations, the privacy transfer engine 126 transmits the privacy commands 2051-Nan to one or more intermediate components (e.g., the electronic communication system 110), which then transmit the status notification to the appropriate additional client devices. In some implementations, the privacy transfer engine 126 transmits the privacy commands 2051-N automatically. In some other implementations, the privacy transfer engine 126 transmits the privacy commands 2051-N only in response to an affirmative user interface input provided by the client device 1061. Although Fig.2A represents three separate privacy commands that are provided for different client devices; in some implementations, more or fewer privacy commands may be transmitted and / or they may be passed to more or fewer additional message exchange thread participants for presentation. Fig. 3 presents an example of the use of components of the exemplary environment from Fig. 1 in the training of one or more machine learning models 156 for use in determining a probability that a message exchange client would consider the content of an ongoing message exchange thread to be sensitive, as shown in Fig. 2. In Fig. 3, the training example engine receives 137 training data instances 1361-N. Each of the training data instances contains content from a message exchange thread and other inputs (e.g., sensor-based data, computation-based action data, historical data) that would be applicable to a specific message exchange thread participant if a message exchange client 107 operated by the participant were transitioned (automatically or manually) to or from a private state. For example, training data instance 1361 can contain a first vector of message exchange thread content, data values, and an indication of whether the transition to the private state was automatic or manual. Furthermore, training data instance 1362 can contain, for example, a second vector of message exchange thread content, data values, and an indication of whether the transition to the private state was automatic or manual.In some implementations, at least some of the training data instances can be created based on a corresponding message exchange thread participant manually transitioning a message exchange client 107 into (or from) a private state. Additionally or alternatively, in some implementations, at least some of the training data instances can be created based on a corresponding message exchange client 107 being automatically transitioned into (or from) a private state. Additional or alternative techniques for creating training data instances can be used. The training example engine 137 uses the training instances to generate training examples 1541-N. Each of the training examples 1541-N contains a training example input, based on the data of a corresponding training data instance, and a training example output, which indicates, for example, whether the transition to (or from) a private state was desired or undesired (which can be determined, for example, by the feedback engine 132). The generated training examples 1541-N are stored as training examples 152, which are used by the training engine 135 to train at least one of the machine learning models 156. In some implementations, the training engine 135 trains a machine learning model based on the training examples 152 by applying the training example input and backward propagation based on the training example output. In some implementations, the same trained machine learning model 156 can be used for client device 1061 and for other client devices of other users. In some implementations, the trained machine learning model 156 used for client device 1061 can optionally be further trained based on user data 158 from the message exchange thread participant operating client device 1061 and / or based on feedback from the participant provided by the feedback engine 132. Further training of the machine learning model 156 based on user data 158 and / or feedback from the message exchange thread participant can allow the machine learning model to be further adapted to the message exchange thread participant operating a particular client device 106.As an example, previous user data 158 can directly specify a transition to / from a private state and associated data for a participant and can be used by the training example engine 137 to generate one or more additional training examples for use by the training engine 135. Turning now to Figures 4A-C, a further description of various components and techniques described here is given. Figures 4A-B depict the exemplary client device 1061 from Figure 1 and one or more examples of how a message exchange client (not shown in Figures 4A-B) can be converted into a private state in response to a determination that there is a sufficient probability that at least one participant in the running message exchange thread would consider content of the message exchange thread to be sensitive. The client device 1061 from Figures 4A and 4B includes a display screen 140. The display screen 140 also includes system interface elements 481, 482, 483 with which the user can interact to cause the client device 1061 to perform one or more actions. In Fig. 4A, a first message exchange thread participant (“you” in Fig. 4A), operating client device 1061, has provided an initial message, “I want to tell you something…”, in the running message exchange thread. Another participant, Sally, has responded: “What is it?” The first participant then states, “Can you keep this between us?” In various implementations, such a statement can be considered a “privacy trigger expression” which, when detected, causes a message exchange client 107 (not shown in Fig. 4A) operated by the first participant to enter a private state (or at least prompts the first participant to indicate whether they wish to enter the private state).As noted above, privacy trigger expressions can include other, similar expressions such as "confidential," "Let's keep this private," "Can you promise not to tell anyone?", etc. In some such implementations, one or more messages following (or in some cases preceding) such a privacy trigger expression may not be retained until, for example, the first participant manually exits the message exchange client from the privacy state, or until it is detected that the topic of discussion has changed to a less sensitive subject. Consequently, Sally's response "Okay," as well as message content provided by the first participant in the message afterward (i.e., the content enclosed by box 480), may not be retained in a copy or log of the ongoing message exchange thread.Additionally or alternatively, in some implementations messages exchanged after the transition can be obfuscated (e.g., replaced or redacted with meaningless text or symbols) before being stored in a copy or log. Privacy trigger expressions can be configured manually or learned over time. For example, a privacy trigger expression might simply be a component of the thread content 212 (see Fig. 2) applied via a machine learning model (with one or more other inputs) to determine the probability that a message-exchange thread participant would consider a message-exchange thread to be sensitive. In some implementations, privacy trigger expressions can be learned when message-exchange thread participants provide certain expressions immediately before or after message-exchange clients 107 manually transition to private states. Thus, for example,While other message-exchange thread participants transition their message-exchange clients 107 into private states before or after something like "Can we keep this private?" is said, such expressions are used as part of one or more training examples to train a machine learning model. Of course, message-exchange threads can transition from private states in response to other, so-called "non-privacy trigger expressions." For example, an expression such as "To move on to something more enjoyable..." or "Let's get back to official" can trigger the transition of one or more message-exchange clients 107 from private states to non-private states. In addition to or instead of privacy trigger expressions, some implementations may use one or more n-grams, alone or together, that form part of the message exchange thread content as signals. In Fig. 4B, for example, a first message exchange thread participant operating client device 1061 has provided an initial message, "Imagine!", in the running message exchange thread. Another participant, Sally, has responded, "What?". The first participant then observes, "Bob got fired for stealing money!" In various implementations, different n-grams of such a statement, such as the name of a particular known entity ("Bob") or other n-grams (e.g., "fired", "steal"), alone or together, may trigger a message exchange client 107 (in Fig. 4B).(Figure 4B not shown), which is operated by the first participant, transitions to a private state (or at least prompts the first participant for an input indicating whether it wishes to transition to the private state). Although all the trigger n-grams in Figure 4B are contained in a single statement by the first participant, this is not intended to be restrictive. In various implementations, n-grams from different messages provided by different participants can also be used together to trigger the transition of a message-sharing client to a private state. Figure 4C shows an example of a portion of a secured copy of the message exchange thread shown in Figure 4B. In this example, the message from the first participant, which states "Bob was fired for stealing money!", has been at least partially obfuscated, so that the name "Bob" and the n-gram "stolen" have been scrambled. In various implementations, this obfuscated content may remain instead of the uncensored content to prevent others from seeing the potentially sensitive statement. In addition to, or instead of, the signals identified above that can trigger a message exchange client to enter a private state, some implementations may use common discussion topics (alone or in conjunction with aspects of historical user behavior) to trigger this transition. For example, in some implementations, discussing potentially sensitive topics such as health issues, vulgar language, politics, personal information, financial information, etc., may cause a message exchange client (or all message exchange clients participating in a message exchange thread) to enter a private state. Of course, the specific topics that trigger a private state transition may change and / or evolve over time.For example, as described above, different machine learning models can be continuously trained over time to identify when potentially sensitive topics are discussed. For instance, one or more machine learning models can be trained with examples representing cases where specific topics are discussed in message threads and where one or more participants in those threads manually move their respective message clients into private states. Additionally or alternatively, one or more machine learning models can be trained with training examples representing cases where specific topics are discussed in message exchange threads and one or more message exchange clients are automatically transitioned to private states (and the respective participants either provide no negative feedback or provide positive feedback). Similar techniques can be used to automatically transition message exchange clients out of a private state. For example, it is assumed that one or more participants in a message exchange thread were discussing a sensitive topic, which caused one or more of their respective message exchange clients to transition to private states. It is further assumed that the participants change the topic of discussion to a less sensitive one.In various implementations, this change of topic can trigger a transition by one or more of the message exchange clients 107 from the private state back to a non-private state (in which message exchange thread content is not obfuscated and is retained in native form). Several techniques can be used to determine discussion topics in a message thread. In some implementations, one or more topic classifiers, such as on-demand classifiers using a floating window of message thread content, can be used to identify one or more current discussion topics. Topic classifiers can take the form of machine learning models or rule-based models. In some implementations, machine learning-based topic classifiers can be trained to provide an output (such as a binary output or a probability) indicating whether a particular topic is being discussed. In other implementations, a topic classifier can be trained to provide an output indicating whether several different topics are being discussed.For example, a topic classifier can be configured to provide output indicating probabilities or confidence levels that several different topics are being discussed. In some implementations, only those topics with probabilities / confidence levels that meet one or more thresholds can be identified as discussion topics. In other implementations, only the n topics with the highest probability / confidence level can be identified as discussion topics. As noted above, in addition to the content of a message exchange thread, other signals can be considered when determining the probability that the content of an ongoing message exchange thread would likely be considered sensitive by at least one message exchange thread participant. In some implementations, context signals or clues associated with one or more client devices 106 (e.g., sensor data 204 in Fig. 2) operated by message exchange thread participants can be analyzed. It is assumed that a particular message exchange thread participant tends to manually transfer a message exchange client to a private state during certain times of day and / or while the participant is in a particular location.In various implementations, the participant's message exchange client can be automatically switched to a private state during these same times of day and / or while the participant is in the same specific location. In some implementations, the states of one or more applications running in a client device 106 can also be used to determine the probability that the content of a running message exchange thread would likely be considered sensitive by at least one message exchange thread participant. Assuming that a particular message exchange thread participant running a message exchange client 107 in a client device 106 also has a web browser open, the client device 106 and the web browser are manually transferred to a private state.In some implementations, particularly if the participant tends (or participants in general tend) to transition a message exchange client 107 into a private state while browsing in a private state, the fact that the web browser is currently in a private state (alone or together with other signals described here) can trigger the message exchange client to also transition into a private state. More generally, in some implementations, one or more states of one or more other applications operating in the participant's client device 106 can be used as features of a vector that serves as a training example for (further) training a machine learning model when a message exchange client 107 transitions into a private state (manually by a message exchange participant or automatically without negative feedback). When determining the probability that one or more message exchange thread participants would consider message exchange thread content to be sensitive, various aspects of documents (e.g., 208 in Fig. 2) can also be considered. It is assumed that a user has stored a document on their client device 106 (and / or in cloud storage) and that the document is configured with strong security guards (e.g., password-protected, limited number of users with access, encrypted, etc.). In some implementations, topics associated with this document and / or its metadata can be flagged as sensitive based on these strong security guards.In some implementations, discussion of such topics by a document owner in a message exchange thread can trigger the transition of a message exchange client 107 operated by the owner into a private state. Additionally or alternatively, one or more message exchange clients 107 operated by participants in the message exchange thread can be transitioned into a private state if the document owner or another message exchange thread specifically references the document (e.g., provides a link to the document, grants permission to access the document, etc.). Although the examples described here typically involved multiple human participants in the message exchange thread, this is not intended to be restrictive. As noted above, in some implementations, a message exchange thread can exist between a single human participant and a non-human participant, such as an automated assistant. In some such implementations, the techniques described here can be used to automatically transfer the message exchange client used by the human participant into a private state, for example, to prevent messages exchanged with the automated assistant from persisting or to obfuscate them. In some implementations, it is possible that the techniques described here could be used to obfuscate or otherwise prevent messages exchanged between multiple non-human participants from persisting. For example, messages exchanged between multiple automated assistants associated with different applications, different domains (e.g., a personal automated assistant exchanging messages with an automated food delivery assistant), etc., could be obfuscated and / or not stored based on the messages containing content likely to be considered sensitive to one or more people, such as a user on whose behalf one or more of the automated assistants are acting, and / or a user being served by one or more of the automated assistants.It is assumed that one person is shopping for a birthday present for another. Furthermore, it is assumed that both people tend to interact with the same automated assistant, such as a self-contained interactive speaker in a household. If the first person enters into a human-computer dialogue with the automated assistant to search for suitable birthday presents, the first person would likely consider any messages exchanged with the automated assistant to be sensitive, as they would not want the second person to consume the content. Accordingly, the automated assistant might, for example,In response to spoken n-grams such as "birthday present" and the identity of the second person, or in response to an utterance such as "What should I get Alice for her birthday?", the automated assistant may enter a private state in which it ceases to retain the content of the human-computer dialogue between the first person and the automated assistant. Additionally or alternatively, the Message Exchange Client 107 may enter a private state if the first person uses a graphical user interface, such as a Message Exchange Client 107, to interact with the automated assistant. A similar transition to a private state may occur during a human-computer dialogue if the person is discussing potentially sensitive topics, such as finance, health, or other topics known or learned to be sensitive. Figure 5 is a flowchart illustrating an exemplary procedure 500 for determining the probability that the content of a message-exchange thread would be considered sensitive by one or more participants and for transitioning one or more message-exchange clients or other components into private states in accordance with implementations disclosed herein. For convenience, the operations of the flowchart are described with reference to a system performing the operations. The system may include various components of different computer systems, such as one or more components of the privacy state system 120. Although operations of the procedure 500 are shown in a particular order, this order is not intended to be restrictive. One or more operations may be rearranged, omitted, or added. In block 502, the system examines the content of a running message exchange thread. As noted above, in some implementations, the system can use a floating window to examine a specific portion of a running message exchange thread. In various implementations, the size of the floating window can be determined temporally and / or spatially. The floating window of examined content might, for example, contain content from the last x minutes, from the last y messages, and so on (where x and y are non-zero integers). In other implementations, every message integrated into a message exchange thread, or even portions of each message, can be examined. In various implementations, message exchange participants may have the option to disable this examination (which would prevent the remaining operations of procedure 500 from being executed). In block 504, the system can, at least partially, determine a probability that content in the message exchange thread would be considered sensitive by one or more participants in the message exchange thread, based on the examination in block 502. In some implementations, this probability can be determined solely based on the content of the message exchange thread (e.g., privacy trigger expressions, various combinations of n-grams, sensitive discussion topics, etc.). In other implementations, this probability can additionally be determined based on other signals, such as sensor data from one or more client devices operated by message exchange thread participants, documents stored or otherwise controlled by one or more message exchange participants, or the historical behavior of one or more message exchange thread participants (e.g.,Under what circumstances one or more participants manually triggered the transition to the private state (or did not object to the automatic transition to the private state), etc., can be determined. As noted above, in some implementations, the message exchange thread content and / or these other signals can be used as various inputs and applied to a machine learning model. The machine learning model can be trained to provide an output indicating the probability. In block 506, the system can determine whether the probability determined in block 504 meets a threshold. If the answer is no (e.g., if the probability that any participant would consider the message exchange thread content sensitive is relatively low), procedure 500 can return to block 502 and resume the examination of the message exchange thread content. If the answer in block 506 is yes, procedure 500 can then proceed to block 508. In block 508, the system can determine whether the probability determined in block 504 meets a threshold, which in many cases may be higher than the initial threshold assigned to block 506. If the answer in block 508 is yes (e.g.,(If the message exchange client is highly likely to be considered sensitive by one or more message exchange thread participants, procedure 500 can proceed to block 510. In block 510, one or more message exchange clients operated by one or more message exchange thread participants can be automatically transferred to private states in which the contents of the message exchange thread are obfuscated or not retained.) If, on the other hand, the response in block 508 is no (for example, if there is a reasonable probability that a message-exchange thread participant would consider the message-exchange thread content to be sensitive, but the probability is not high enough to be considered safe), procedure 500 can proceed to block 512. In block 512, a prompt can be provided, for example, by a message-exchange client as an audible or visual output, requesting permission from one or more message-exchange thread participants to transition a message-exchange client to a private state. In block 514, if a participant grants the requested permission, procedure 500 can proceed to block 510, which was described earlier. If the response in block 514 is no, procedure 500 can proceed back to block 502, and no transition to a privacy state can be triggered. Back in block 510, in some implementations, the system can transmit, or cause one or more message exchange clients to transmit, one or more privacy commands to other message exchange clients (or more generally, client devices) used to participate in the message exchange thread. These privacy commands can cause the receiving message exchange clients (or more generally, the receiving client devices) to enter private states (for example, automatically or in response to a user providing permission upon request). Although not shown in Figure 5, in some implementations, the transmission of privacy commands to different message exchange clients can be prepared based on the probability determined in block 504. If the probability exceeds a certain threshold (for example,If the probability of a participant granting such permission (e.g., in response to a request for such permission) is met (the second threshold assigned to block 508), the privacy commands can be transmitted automatically. However, if the probability does not meet a threshold, the privacy commands can only be transmitted in response to a participant granting such permission. In addition to or instead of prompting message exchange thread participants for permission to transition message exchange clients into private states, some implementations allow message exchange clients to transition automatically, and participants then have the opportunity to provide feedback about the automatic transition. For example, a user might be notified, perhaps through audible or visual output, that their client device and / or message exchange client has transitioned into a private state. The participant can then provide feedback, such as manually transitioning back to a non-private state, or provide other input indicating disapproval of the transition. Based on this feedback, the system (e.g.,By using this case as the basis for a training example of a machine learning model, one can "learn" that the participant does not want to transition to a private state under the current circumstances. Furthermore, similar techniques to those shown in Fig. 5 can, of course, be used to automatically transition a message-sharing client (or more generally, a client device) from a private state to a non-private (or less private) state. In various implementations, message exchange clients can operate alongside any number of other applications in client devices. In some implementations, one or more of these other (e.g., third-party) applications may be able to "listen in" on message exchange threads in which the message exchange clients participate. For example, a street vendor ordering application may listen on message exchange threads between users to determine, for instance, whether the users are discussing dinner (in which case the street vendor ordering application may join the message exchange thread and offer to place a street vendor order). As another example, in some implementations, one or more search applications may listen in message exchange threads to determine whether to use exchange content to prepare and submit search queries.In some implementations, content of the message exchange thread may be obfuscated or otherwise not made available to such third-party applications if it is determined that participants in a message exchange are discussing potentially sensitive information, causing one or more message exchange clients to enter private states. Fig. 6 is a block diagram of an exemplary computer device 610, which can optionally be used to perform one or more aspects of the techniques described herein. In some implementations, the client computer devices 1061-N and / or the privacy status system 120 and / or one or more other components may include one or more components of the exemplary computer device 610. The computer device 610 typically includes at least one processor 614, which communicates with a number of peripheral devices via a bus subsystem 612. These peripheral devices may include a memory subsystem 624, which may contain, for example, a main memory subsystem 625 and a file storage subsystem 626, user interface output devices 620, user interface input devices 622, and a network interface subsystem 616. The input and output devices enable user interaction with the computer device 610. The network interface subsystem 616 provides an interface to external networks and is coupled with corresponding interface devices in other computer devices. The user interface input devices 622 may include a keyboard, pointing devices such as a mouse, trackball, touchpad or graphics tablet, a scanner, a touchscreen built into the display, audio input devices such as voice recognition systems, microphones and / or other types of input devices. In general, the use of the term "input device" is intended to include all possible types of devices and methods for inputting information into the computer device 610 or into a communications network. The user interface output devices 620 may include a display unit system, a printer, a fax machine, or non-visual displays such as audio output devices. The display unit system may include a cathode ray tube (CRT), a flat-panel display device such as a liquid crystal display (LCD), a projection device, or any other mechanism for producing a visible image. The display unit system may also provide a non-visual display, such as through audio output devices. In general, the term "output device" is intended to include all possible types of devices and methods for outputting information from the computer device 610 to the user or to another machine or computer device. The 624 memory subsystem stores program and data constructs that provide the functionality of some or all of the modules described here. For example, the 624 memory subsystem can contain the logic for executing selected aspects of the procedure shown in Fig. 5. These software modules are generally executed by the processor 614, either alone or in conjunction with other processors. The main memory 625 used in the memory subsystem 624 can include several main memory locations, including read / write main memory (RAM) 630 for storing instructions and data during program execution, and read-only memory (ROM) 632, which stores fixed instructions. A file storage subsystem 626 can provide persistent storage for program and data files and may include a hard disk drive, a floppy disk drive along with associated removable media, a CD-ROM drive, an optical drive, or removable media cartridges. The modules implementing the functionality of certain implementations can be executed by the file storage subsystem 626 in the memory subsystem 624 or in other machines to which the respective subsystem or subsystem is connected.The processors 614 can be accessed and stored. The bus subsystem 612 provides a mechanism to enable the various components and subsystems of the computer device 610 to communicate with each other as intended. Although the bus subsystem 612 is shown schematically as a single bus, alternative implementations of the bus subsystem may use multiple buses. The computer device 610 can be of various types, including a workstation, a server, a computer cluster, a blade server, a server farm, or any other data processing system or computer device. Because of the constantly evolving nature of computers and networks, the description of the computer device 610 shown in Fig. 6 is intended only as a specific example to illustrate some implementations. Many other configurations of the computer device 610 are possible, comprising more or fewer components than the computer device shown in Fig. 6. In situations where the systems described here collect or otherwise monitor personal information about users, or use personal information and / or monitored information (e.g., messages exchanged in message threads), users may be given an opportunity to control whether programs or features collect user information (e.g., information about a user's social network, social actions or activities, occupation, user preferences, or current geographic location), or to control whether and / or how content that may be more relevant to the user is received from the content server. Furthermore, certain data may be processed in one or more ways to remove personally identifiable information before it is stored or used.For example, a user's identity can be handled in such a way that no personally identifiable information can be determined for the user, or a user's geographic location, where geographic location information is obtained, can be generalized (such as to a city, postal code, or state level) in such a way that a specific geographic location of a user cannot be determined. Thus, the user can have control over how information about the user is collected and / or used. For example, in some implementations, message exchange thread participants operating message exchange clients configured with selected aspects of this disclosure can opt out of message exchange thread content being monitored, so that, for example,a participant who wishes to transition a messaging client into or out of a private state would do so manually. This patent is generally directed to techniques for automatically transitioning applications—especially those enabling the exchange of messages between users—into and / or out of a private state based on a multitude of signals associated with the messages and / or the participants themselves. In various implementations, an ongoing message exchange thread between two or more participants, each operating two or more respective exchange clients, can be examined. Based at least partially on this examination, a probability can be determined that one or more messages sent by one of the participants to another as part of the ongoing message exchange thread would be considered private by at least one of the two or more participants.It is possible to determine whether a given probability meets one or more thresholds, and in response, one or more of the message exchange clients can be moved into a private state. Although several implementations have been described and illustrated here, a multitude of other means and / or structures can be used to perform the function and / or to obtain the results and / or one or more of the advantages described here, each of these variants and / or modifications being considered to be within the scope of protection of the implementations described here. More generally, all parameters, dimensions, materials, and configurations described here are intended to be exemplary, and the actual parameters, dimensions, materials, and / or configurations will depend on the specific application or applications for which the teachings are used. A person skilled in the art will recognize, or be able to determine, many equivalents to the specific implementations described here simply through routine experimentation.Therefore, the foregoing implementations are, of course, only examples and can be realized in ways other than those specifically described and claimed within the scope of protection of the attached claims and their equivalent implementations. Implementations of the present disclosure are directed to each individual feature, system, article, material, kit, and / or method described herein. Furthermore, any combination of two or more such features, systems, articles, materials, kits, and / or methods is included within the scope of protection of the present disclosure, provided that these features, systems, articles, materials, kits, and / or methods are not inconsistent with each other.

Claims

A method implemented using one or more processors, comprising: examining an ongoing message exchange thread involving at least one human participant, a first automated assistant, and a second automated assistant; determining, at least in part based on the examination, a probability that one or more messages added to the message exchange thread by the at least one human participant or the first automated assistant are considered private by the at least one participant, the probability being determined based on the message exchange thread content and sensor-based data; and establishing that the determined probability satisfies one or more thresholds.and in response to the finding that the determined probability meets one or more thresholds, the omission of storing one or more messages exchanged between the first automated assistant and the second automated assistant in a message log, wherein the probability is determined based on the detection of one or more N-grams classified as sensitive in the current message exchange thread, and the one or more N-grams are classified as sensitive based on the historical behavior of a multitude of participants in a multitude of message exchange threads outside the current message exchange thread. Method according to claim 1, wherein the probability is further determined on the basis of the historical behavior associated with the at least one participant. Method according to claim 1, wherein the probability is determined on the basis of the detection of one or more topics or metadata in the ongoing message exchange thread that are related to a document controlled by the at least one participant. System according to claim 1, wherein the one or more N-grams are classified as sensitive based on the historical behavior associated with the at least one participant. Method according to claim 1, wherein the one or more N-grams are classified as sensitive based on browser histories associated with a large number of users. A system comprising one or more processors and memory that stores instructions, which, in response to the execution of the instructions, causes the one or more processors to: examine an ongoing message exchange thread involving at least one human participant, a first automated assistant, and a second automated assistant; determine, at least in part based on the examination, the probability that one or more messages added to the message exchange thread by the at least one human participant or the first automated assistant are considered private by the at least one participant, the probability being determined based on the message exchange thread content and sensor-based data; determine that the determined probability satisfies one or more thresholds;and in response to the finding that the determined probability meets one or more thresholds, to refrain from storing one or more messages exchanged between the first automated assistant and the second automated assistant in a message log, wherein the probability is determined based on the detection of one or more N-grams classified as sensitive in the current message exchange thread, and the one or more N-grams are classified as sensitive based on the historical behavior of a multitude of participants in a multitude of message exchange threads outside the current message exchange thread. The system according to claim 6, wherein the probability is further determined on the basis of the historical behavior associated with the at least one participant. The system according to claim 6, wherein the probability is determined on the basis of the detection of one or more topics or metadata in the ongoing message exchange thread that are related to a document controlled by the at least one participant. System according to claim 6, wherein the one or more N-grams are classified as sensitive based on the historical behavior associated with the at least one participant. The system according to claim 6, wherein the one or more N-grams are classified as sensitive based on browser histories associated with a large number of users. Non-volatile, machine-readable medium comprising instructions which, in response to the execution of instructions by a processor, cause the processor to: examine an ongoing message exchange thread involving at least one human participant, a first automated assistant, and a second automated assistant; determine, at least in part based on the examination, the probability that one or more messages added to the message exchange thread by the at least one human participant or the first automated assistant are considered private by the at least one participant, the probability being determined based on the message exchange thread content and sensor-based data; determine that the determined probability satisfies one or more thresholds;and in response to the finding that the determined probability meets one or more thresholds, to refrain from storing one or more messages exchanged between the first automated assistant and the second automated assistant in a message log, wherein the probability is determined based on the detection of one or more N-grams classified as sensitive in the current message exchange thread, and the one or more N-grams are classified as sensitive based on the historical behavior of a multitude of participants in a multitude of message exchange threads outside the current message exchange thread. Non-transitory, computer-readable medium according to claim 11, wherein the probability is further determined on the basis of the historical behavior associated with the at least one participant. Non-volatile, computer-readable medium according to claim 11, wherein the probability is determined on the basis of the detection of one or more topics or metadata in the ongoing message exchange thread that are associated with a document controlled by the at least one participant. Non-transitory, computer-readable medium according to claim 11, wherein the one or more N-grams are classified as sensitive based on the historical behavior associated with the at least one participant.

Images