WO2022272155A1 - Partage d'état d'application chiffré de bout en bout - Google Patents

Partage d'état d'application chiffré de bout en bout Download PDF

Info

Publication number
WO2022272155A1
WO2022272155A1 PCT/US2022/035033 US2022035033W WO2022272155A1 WO 2022272155 A1 WO2022272155 A1 WO 2022272155A1 US 2022035033 W US2022035033 W US 2022035033W WO 2022272155 A1 WO2022272155 A1 WO 2022272155A1
Authority
WO
WIPO (PCT)
Prior art keywords
messaging
client
account
patch
client device
Prior art date
Application number
PCT/US2022/035033
Other languages
English (en)
Inventor
Simon FERYN
Vitali HARAVY
Cristina IVANOV
Pulkit KOTHARI
Theodore Elliot Yaung
Alisdair Henry JOHNSTONE
Jonathan Richard Millican
Bruno Rafael PENTEADO MURATORE
Yaron Naveh
Original Assignee
Whatsapp, Llc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Whatsapp, Llc filed Critical Whatsapp, Llc
Publication of WO2022272155A1 publication Critical patent/WO2022272155A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/606—Protecting data by securing the transmission between two devices or processes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/42—Mailbox-related aspects, e.g. synchronisation of mailboxes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/12—Transmitting and receiving encryption devices synchronised or initially set up in a particular manner
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M1/00—Substation equipment, e.g. for use by subscribers
    • H04M1/72—Mobile telephones; Cordless telephones, i.e. devices for establishing wireless links to base stations without route selection
    • H04M1/724—User interfaces specially adapted for cordless or mobile telephones
    • H04M1/72403—User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality
    • H04M1/7243—User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality with interactive means for internal management of messages
    • H04M1/72436—User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality with interactive means for internal management of messages for text messaging, e.g. short messaging services [SMS] or e-mails
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03—Protecting confidentiality, e.g. by encryption
    • H04W12/033—Protecting confidentiality, e.g. by encryption of the user plane, e.g. user's traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/12—Messaging; Mailboxes; Announcements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/52—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail for supporting social networking services

Definitions

  • the present disclosure generally relates to synchronizing data and, more particularly, to synchronizing data through end-to-end encryption.
  • Messaging may include the act of composing and sending electronic messages, typically consisting of alphanumeric characters, between two or more users of computing devices via a messaging system.
  • messages may be passed through and stored by intermediaries, from which they may be retrieved by the recipient. Because these messages are conventionally encrypted “in transit” (e.g., by an intermediary messaging server), they may be accessible either legitimately by the messaging service providers or illegitimately by various bad actors (e.g., hackers), which may compromise privacy, security, and trust.
  • a computer-implemented method comprising: receiving, by a messaging client executing on a first client device, a first data package for an account from a messaging server; decrypting, by the messaging client, an encrypted portion of the first data package to yield a first patch queue for the account; computing, by the messaging client, a hash value for the first patch queue; determining, by the messaging client, that the computed hash value matches an expected hash value specified in the first patch queue; and updating, by the messaging client, a messaging database for the account on the first client device based on one or more changes for the account specified in the first patch queue.
  • the method may further comprise: detecting, by the messaging client, a modification to the account database; generating, by the messaging client, a second patch queue reflecting the modification to the account database; computing, by the messaging client, a hash value for the second patch queue; encrypting, by the messaging client, the second patch queue and the hash value for the second patch queue; generating, by the messaging client, a second data package comprising the encrypted second patch queue and the encrypted hash value for the second patch queue; and transmitting, by the messaging client, the second data package to the messaging server.
  • the second data package may be stored by the messaging server.
  • the second data package stored by the messaging server may be accessible by instances of the messaging client associated with the account on a plurality of other client devices.
  • the patch queue may comprise a version identifier.
  • the method may further comprise prior to updating the messaging database: determining, by the messaging client, a version identifier associated with the messaging database; determining, by the messaging client based on a version identifier of the first patch queue, a plurality of changes for the account in the first patch queue that are subsequent to the version identifier associated with the messaging database; and updating, by the messaging client, the messaging database for the account based on the determined plurality of changes for the account in the first patch queue that are subsequent to the version identifier associated with the messaging database.
  • the one or more changes may comprise one or more of: (i) adding a new message to the messaging database, (ii) deleting a message from the messaging database, (iii) adding a contact record to the messaging database, (iv) removing a contact record from the messaging database, or (v) modifying an element of the messaging database.
  • the first patch queue may comprise at least one change to the account received from an instance of the messaging client executing on a second client device.
  • the second client device may be associated with the account.
  • the method may further comprise refreshing a graphical user interface of the messaging client on the first client device based on the updated messaging database.
  • Updating the messaging database for the account on the first client device may synchronize the messaging database for the account on the first client device with an instance of the messaging database for the account on the second client device.
  • a computer-readable storage medium comprising instructions that, when executed by a processor of a first client device, cause the processor to carry out the method of the first aspect.
  • the medium may be non-transitory.
  • an apparatus comprising: a processor; and a memory storing instructions that, when executed by the processor, cause the processor to carry out the method of the first aspect.
  • a computer program comprising instructions which, when the program is executed by a computer, cause the computer to carry out the method of the first aspect.
  • the messaging platform may allow users to access their account (or accounts) from multiple devices, such as smartphones, laptops, tablets, etc.
  • each device operates as a standalone client having its own session and identity (e.g., a unique identifier).
  • identity e.g., a unique identifier
  • each device may be “offline” for some periods of time, account state synchronization is needed to synchronize changes that occurred while a given device was offline.
  • end-to-end encryption of data in the messaging platform poses challenges in such a multi-device configuration.
  • a message may be encrypted by a first client device registered to an account
  • a second client device registered to the account cannot simply download the encrypted message from an intermediary server caching the encrypted message, as the second client device and/or server would not be able to view the encrypted message without the appropriate encryption keys to decrypt the message.
  • Advantages include secrecy (server unable to see the changes), privacy (server unable to see what is being changed), and integrity (server cannot tamper with the content being exchanged) of the user data.
  • Embodiments disclosed herein provide techniques for encrypted change logs, also referred to as patch queues, that can be used to synchronize account state (e.g., a complete messaging history) across all devices.
  • a first device registered to an account may generate an encrypted patch queue that reflects changes to the account on the first device, such as received messages, deleted messages, sent messages, etc.
  • the first device may send the encrypted patch queue to a messaging server that stores the encrypted patch queue for retrieval by other registered devices.
  • a second registered device may download the encrypted patch queue, decrypt the patch queue, and modify an instance of a messaging database for the account using the decrypted patch queue.
  • the messaging databases may be synchronized without the server being able to understand the changes (e.g., without being able to read message contents, etc.).
  • each patch queue (and/or the contents thereof) may be associated with a hash value computed by the device creating the patch queue.
  • a client device receiving or otherwise processing a patch queue may use the hash value included in the encrypted patch queue to determine whether the patch queue is valid. For example, the client device may compute a hash value (or checksum, etc.) for the patch queue and/or the contents of the patch queue. The client device may then compare the computed hash value to the hash value specified in the patch queue. If the comparison results in a match, the patch queue may be verified, and the client device may process the patch queue to update the messaging database on the client device.
  • the patch queue is not verified, and the client device may refrain from processing the patch queue to preserve security. Stated differently, if the comparison does not result in a match, the patch queue may be maliciously modified and/or otherwise corrupted, and the client device may reject the patch queue and refrain from updating the messaging database using the rejected patch queue.
  • the patch queue and/or contents thereof may be signed by a digital signature generated by the device that creates the patch queue using a private key associated with the account.
  • the receiving device may then attempt to verify the digital signature with a public key associated with the account. If the digital signature is verified using the public key, e.g., by decrypting the digital signature with the public key, the receiving device may process the patch queue to update the messaging database. Otherwise, if the digital signature is not verified, the client device may reject the patch queue and refrain from updating the messaging database using the rejected patch queue.
  • embodiments disclosed herein may provide strong versioning and conflict resolution for synchronization operations. For example, each patch queue may be associated with a version identifier.
  • the version identifier may allow different messaging clients to quickly synchronize messaging histories in the multi-device environment.
  • the version identifier can be categorized by a numeral (e.g., version 20 ).
  • a messaging client on a first device may have patch queue with version identifier 20 as the most recent version identifier reflected in the local messaging database on the first device.
  • the messaging client on the first device may send the version identifier to the server with a sync request.
  • the server may then generate a “snapshot” comprising one or more patch queues with version identifiers greater than 20 may exist (e.g., version identifier 21, 22, etc.) and transmit the snapshot of one or more patch queues with version identifiers greater than 21 to the client on the first device. Doing so facilitates the exchange of messaging updates without the server understanding the changes or underlying data and without the server transmitting the entire messaging history to the client on the first device.
  • the messages and/or operations reflected in a patch queue may be tagged with a timestamp. Since each message is associated with a timestamp, the multi-device system may use the timestamps for conflict resolution, e.g., to display messages in appropriate order in a graphical user interface (GUI) of the messaging client, accurately reflect message deletion, etc.
  • the conflict resolution may further be based on different conflict resolution rules, where different operations may be associated with different conflict resolution rules. For example, for a message pinning operation, the conflict resolution rule may specify to perform a pinning operation over an archiving operation, where the pinning operation occurred later in time relative to the archiving operation.
  • a conflict resolution rule for message deletion operations may specify to compute a union of any received deletion operations and delete all messages in the union.
  • the messaging system may provide specific encryption promises.
  • the encryption promises may include management of encryption keys.
  • encryption keys may be revoked and regenerated to enhance security. For example, if a user accesses their account on a public device, the messaging platform may revoke the existing encryption keys once the user logs off the public device, thereby removing access to the account by the public device. The messaging platform may then generate new encryption keys that are shared with remaining authorized devices, such as the user’s laptop, smartphone, etc. Doing so ensures that the public device is not able to access the encrypted account data.
  • anti-tampering schemes may be implemented in the messaging platform. For example, by encrypting a unique message identifier and corresponding data, the structure and integrity of data provided by server can be validated by all clients. Furthermore, doing so allows clients to detect when the server reorders messages and/or deletes messages.
  • patch queues provide a highly secure and efficient way of reflecting messaging account changes or updates.
  • security of the account may be further protected, as malicious actors do not have access to the encryption keys needed to mimic such functionality.
  • computing resources, bandwidth, and energy may be preserved by using the patch queues to synchronize changes in the multi-device environment. For example, rather than transmitting an entire account history (which may span days, months, years, or more) to a device that was offline for an hour, embodiments disclosed herein securely transmit only the updates that occurred while the device was offline.
  • FIG. 1 depicts an exemplary communication or computer system.
  • FIGs. 2A-2E depict exemplary graphical user interfaces of a messaging client.
  • FIG. 3 depicts a first exemplary data flow diagram.
  • FIG. 4 depicts a second exemplary data flow diagram.
  • FIG. 5 depicts a third exemplary data flow diagram.
  • FIG. 6 depicts a fourth exemplary data flow diagram.
  • FIG. 7 depicts a first exemplary flowchart.
  • FIG. 8 depicts a second exemplary flowchart.
  • FIG. 9 depicts a third exemplary flowchart.
  • FIG. 10 depicts a fourth exemplary flowchart.
  • FIG. 11A depicts an exemplary centralized communications service.
  • FIG. 11B depicts an exemplary distributed communications service.
  • FIG. 12 depicts an exemplary messaging service system.
  • FIG. 13 depicts an exemplary computing architecture.
  • FIG. 14 depicts an exemplary communication architecture.
  • FIG. 15 depicts an exemplary multicarrier communications device.
  • the user may be required to opt into any data collection before user data is collected or used.
  • the user may also be provided with the opportunity to opt out of any data collection.
  • the user Before opting into data collection, the user may be provided with a description of the ways in which the data will be used, how long the data will be retained, and the safeguards that are in place to protect the data from disclosure.
  • Any information identifying the user from which the data was collected may be purged or disassociated from the data.
  • any identifying information needs to be retained e.g., to meet regulatory requirements
  • the user may be informed of the collection of the identifying information, the uses that will be made of the identifying information, and the amount of time that the identifying information will be retained.
  • Information specifically identifying the user may be removed and may be replaced with, for example, a generic identification number or other non-specific form of identification.
  • the data may be stored in a secure data storage location that includes safeguards to prevent unauthorized access to the data.
  • the data may be stored in an encrypted format. Identifying information and/or non-identifying information may be purged from the data storage after a predetermined period of time.
  • embodiments and examples may be deployed in a wide variety of messaging systems, including messaging in a social network or on a mobile device (e.g., through a messaging client application or via short message service), among other possibilities.
  • An overview of exemplary logic and processes for engaging in synchronous video conversation in a messaging system is next provided.
  • a and “Z>” and c are intended to be variables representing any positive integer.
  • a complete set of components 122 illustrated as components 122-1 through 122-a may include components 122-1, 122-2, 122-3, 122-4, and 122-5.
  • FIG. 1 depicts an exemplary communication or computer system 100.
  • the communication or computer system 100 may be part of or implemented in a messaging platform (e.g., social networking platform, social media platform, standalone messaging platform, cross-platform messaging system, etc.).
  • the system 100 may include at least one or more intermediate messaging servers 104, one or more data stores 106 coupled to the messaging server(s) 104, and one or more client devices 112-1 through 112-n, where “n” is any positive integer greater than 1.
  • the one or more client devices 112 may include one or more sending client devices 112-1 and one or more receiving client devices 112- 2.
  • a messaging client (or messaging application, not pictured) on the sending client device 112-1 may send an encrypted message to a messaging client (also not pictured) on a receiving client device 112-2 via the messaging servers 104.
  • the sending and receiving client devices may be associated with different users, or accounts, in the messaging platform.
  • one or more components, such as the intermediate messaging servers 104 may be connected to or in communication with (persistently or selectively) one or more third party servers 107 (and/or any related components thereof).
  • the client devices 112-1 through 112-n may communicate with each other via the intermediate messaging server(s) 104.
  • any message sent via the messaging system 100 is encrypted by a transmitting device and decrypted by the receiving device using end-to-end (E2E) encryption. Doing so preserves account security by preventing any intermediate entities from viewing or otherwise accessing the contents of the encrypted message.
  • Each client device 112-1 through 112-n may have a unique identifier (ID) in the databases 106, and each client device 112-1 through 112-n may have a different session with the messaging server(s) 104.
  • each client device 112-1 through 112-n may store an instance of an account messaging database for any account to which the device has been registered.
  • the intermediate messaging servers 104 may be backend servers of the messaging platform and may run, support, or execute the messaging operations described herein.
  • a sending user may be associated with and operate the sending client device 112-1.
  • each of the client devices 112 may be associated with or belong to one or more users on the messaging platform (e.g., second user, third user, fourth user, fifth user, etc.).
  • a single user and/or user account
  • the first user may have accessed (or otherwise logged into) a first account in the messaging platform on client devices 112-1, 112- 3, and 112-4. Therefore, the messaging platform may facilitate access to an account on multiple client devices 112 registered to the account.
  • the multiple devices 112 may access the account at different times (e.g., the first account may be active, or online, on the client device 112-1, while client device 112-3 may be offline, and therefore not active in the messaging platform until a later time).
  • a mobile device such as a smartphone
  • FIG. 1 it may be understood that any computing device (e.g., stationary desktop computers, server computers, wearable computing devices, tablet devices, virtual reality devices, etc.) can also be the client devices within the messaging platform.
  • All communication between clients 112-1 through 112-n and servers 104 may be layered within a separate encrypted channel.
  • End-to-end capable clients may use, for example, Noise Pipes with Curve25519, Advanced Encryption Standard Galois/Counter Mode (AES_GCM), and Secure Hash Algorithm 256 (SHA256) from the Noise Protocol Framework for long running interactive connections.
  • the parameters for sehing up the encrypted channel may be stored in the data store (database) 106 at the server 104.
  • Such a configuration provides several desirable properties, including: fast, lightweight connection and resume; encryption of metadata to hide it from unauthorized network observers; information about the connecting user’s identity is not revealed; and no client authentication secrets are stored on the server 104.
  • Clients may authenticate themselves using a Curve 25519 key pair, so the server 104 only stores a client’s public authentication key. If the server’s user database 106 is ever compromised, no private authentication credentials will be revealed.
  • end-to-end encrypted protocols may prevent third parties (and even the communications service, including servers 104, itself) from having plaintext access to messages transmitted by the service. Even if encryption keys from a user’s device are physically compromised, they cannot be used to go back in time to decrypt previously transmitted messages.
  • a user may initially register with the messaging system 100.
  • the user’s registration information may be stored in the client database 106.
  • Each user may be associated with an entry indexed by an identifier assigned to the user account.
  • an application of the communications service associated with the registering user may transmit a public identity key, a public signed pre key with its signature, and one or more public one-time pre keys to the server 104.
  • the identity key may be a long-term Curve25519 key pair, generated at the time that the application is installed on the client device.
  • the signed pre-key may be a medium-term Curve25519 key pair, generated at install time and signed by the identity key.
  • the signed pre-key may be rotated on a periodic basis.
  • the one-time pre keys may be a queue 308 of Curve25519 key pairs for one-time use, generated at install time, and replenished as needed.
  • the server 104 may store these public keys associated with the user’s identifier. According to examples, at no time does the server 104 have access to any of the client’s private keys.
  • the client 112 initiating the session (“initiator”) may request the public identity key, public signed pre key, and a single public one-time pre key for the recipient 112
  • the server 104 may return the requested public key values.
  • a one-time pre key is only used once, so it is removed from the server storage after being requested.
  • the initiator may save the recipient’s identity key, the signed pre key, and the one-time pre key.
  • the initiator may then generate an ephemeral Curve25519 key pair.
  • the initiator may load its own identity key.
  • the initiator may calculate a master secret based on the keys.
  • the initiator may use a Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF) to create a root key and chain keys from the master secret, as discussed in more detail below.
  • a root key may be a 32-byte value that is used to generate chain keys.
  • a chain key may be a 32-byte value used to create message keys.
  • a message key may be an 80-byte value that is used to encrypt message contents.
  • 32 bytes may be used for an Advanced Encryption Standard-256 (AES-256) key
  • 32 bytes may be used for an HMAC Secure Hash Algorithm-256 (HMAC-SHA256) key
  • 16 bytes may be used for an initialization vector (IV).
  • the initiator 112 may immediately start sending messages to the recipient 112, even if the recipient is offline. Until the recipient responds, the initiator may include the information (in the header of all messages sent) that the recipient requires to build a corresponding session. This includes the initiator’s keys. Optionally the message may also include a public key and encrypted content.
  • the recipient may calculate the corresponding master secret using its own private keys and public keys advertised in the header of the incoming message.
  • the recipient deletes the one-time pre key used by the initiator.
  • the initiator may use HKDF to derive a corresponding root key and chain keys from the master secret.
  • clients may exchange messages that are protected with a message key using AES256 in cipher block chaining (CBC) mode for encryption, and HMAC-SHA256 for authentication.
  • CBC cipher block chaining
  • the messaging platform may facilitate the communication of messages, files, emoji, commands, account operations, and/or other digital content among client devices 112 in various ways. More generally, any type of file, command, operation, and/or digital content may be shared between client devices 112 via the messaging platform. As stated, however, in a multi-device platform, a given client device 112-n registered to an account may be offline for some period of time.
  • the offline device may not receive updates to the account that are reflected on other devices, such as messages received by other devices while the device is offline, messages sent by the account using other devices while the device is offline, operations performed to the account via the other devices while the device is offline, operations performed on the instances of the account messaging database on the other devices while the device is offline, etc.
  • the system can perform an initial synchronization between the devices, due to the various online/offline status of the client devices. For example, a first pairing a new companion device can be synchronized with the primary device to synchronize a message history (e.g., this may be performed one time). Once the history of messages is synchronized, the new device is populated with all the existing chats and all the messages in those chats. The data synchronization may also piggyback on the same mechanisms as the transcript message exchange, during a registration phase to establish some secret information. As a result, any changes in settings, application data, etc.
  • any of the devices will be synchronized in an encrypted manner, e.g., within a storage solution residing, at least partially, in the primary device, the companion device, or a server-side device. For example, if a user stars/bookmarks a message, this information will be encrypted and will be stored on a data synchronization storage and may be synced to all other devices in the way that this specific message will appear to be starred/bookmarked on all of them.
  • the synchronized data may include arbitrary user private data.
  • the synchronized data may include the following categories, such as chat properties (e.g., meaning that muted, pinned, and/or deleted chat-based information is synchronized with the storage and message properties such as deleted or starred messages are also synchronized). This may also include contact related information such as contact names and broadcast list names (e.g., favorite contacts, etc.) will also be synchronized. Additional categories such as most recently used GIFs stickers, emojis, and the like may also be synchronized. It is understood that this approach is not limited to synchronization of these specific settings, and it can be easily extended to synchronize arbitrary private data, such as messages, documents, etc. as well.
  • the data synchronization may include a cluster of processes that, when a new device is paired to an account, a primary device (e.g., the user’s phone) sends some encrypted materials to that new device, and on top of that the material is set up with encryption keys that are used to access application state data.
  • a primary device e.g., the user’s phone
  • the new paired device can go to the server and request application state information from the server, and the server will send it in the form of encrypted bundles of data.
  • the server does not know what data (e.g., what kind of data) those bundles contain, and it is up to device to fetch it and decrypt it.
  • one device may change application state data.
  • the set of such changes is encoded into a patch and encrypted.
  • the encrypted patch is sent in encrypted form (e.g., a patch queue) to the server, and the server stores this data in encrypted form.
  • this new information is pushed to that device so that device authenticates with the server and fetches the data input from that patch queue. Then, using the key material that that this device received during registration, it can decrypt the data, validate the consistency of that data, and also update local storage information with that new data.
  • embodiments and examples disclosed herein may leverage one or more encrypted patch queues (also referred to as “patch queues”), or encrypted change logs, that securely carry changes to a given account such that the changes can be synchronized across all devices registered to the account.
  • patch queues also referred to as “patch queues”
  • encrypted change logs that securely carry changes to a given account such that the changes can be synchronized across all devices registered to the account.
  • a patch queue is an ordered dictionary of dictionaries for an account, also referred to as account “deltas.”
  • a given patch queue may comprise one or more unique identifiers (IDs), a corresponding value for the ID, a version number for the patch queue, a hash value computed for the patch queue, a digital signature for the patch queue and/or the hash value, and any other metadata attribute of the patch queue.
  • the additional metadata may include timestamps associated with each unique ID (which may correspond to a message and/or other account operation or change). The value corresponding to the ID may reflect one or more changes to the account.
  • Exemplary changes include, but are not limited to, adding a received message to the messaging database, deleting a message from the messaging database, adding a contact record to the messaging database, removing a contact record from the messaging database, deleting a messaging thread, creating a new messaging thread, archiving a message, pinning a message (or applying a pin label to the message), starring a contact record, and modifying an element of the messaging database.
  • the value may include all data parameters required to implement the changes, such as a message text, sender/receiver identification information, etc.
  • the patch queue may be encrypted using encryption keys associated with an account and transmitted to the server(s) 104 for storage in the data stores 106, where the patch queue may be accessed by any of the devices registered to the account.
  • the encryption keys may include a public key to encrypt a patch queue and a corresponding private key to decrypt the patch queue.
  • the hash value may be computed using any suitable hash function or cryptographic algorithm. In some examples, the hash value of the patch queue is encrypted. In other examples, the hash value is not encrypted. In some examples, the digital signature is generated using the private key and verified using the public key. The digital signature may be encrypted and/or unencrypted.
  • the version number may be any unique version identifier, such as a sequential numeric identifier. Therefore, a first patch queue may have a version identifier of “0”, while a second patch queue may have a version identifier of “1”, and so on.
  • the communication system 100 is able to propagate changes to different registered devices based on the “delta” between the latest version identifier of a device registered to an account and the most recent version identifier for the account. For example, if device 112-3 is offline for some time and has the most recent version identifier of 20, the associated account (e.g., as reflected on device 112-1) may have a most recent version identifier of 21.
  • the client device 112-1 may have generated and transmitted a patch queue with version identifier 21 to the server(s) 104.
  • the device 112- 3 may request an update from the server(s) 104.
  • the request may comprise at least the version identifier of the device 112-3 (and/or the associated instance of the account messaging database). Therefore, the server(s) 104 may determine, without reading or otherwise exposing any of the encrypted data in the patch queues, that the client device 112-3 should receive the delta of patch queue with version identifier 20 and the patch queue with version identifier 21. Stated differently, the server(s) 104 may determine that the device 112-3 should receive the updates subsequent to version identifier 120. Doing so allows incremental updates to be shared in the system 100 rather than transmitting an entire account history to a given device (e.g., sending patch queues with version identifiers 0-21 to the device 112-3).
  • the server(s) 104 may build a “snapshot” for a requesting client device 112-n. For example, the server(s) 104 may determine that client device 112-3 needs patch queues with version identifiers 18-21. Therefore, the server(s) 104 may build a data package or encrypted patch queue from among the patch queues for the account stored in the database 106 and transmit a snapshot patch queue comprising the patch queues with version identifiers 18-21 to the device 112-3.
  • the snapshot patch queue may be encrypted using the public key of the account and decrypted by the device 112-3 using the private key of the account.
  • the server(s) 104 may use a hash algorithm that computes a cumulative hash value at the computational cost of hashing only new records (e.g., hashing patch queues with version identifiers 18-21 rather than hashing patch queues with version identifiers 0-21).
  • a hash algorithm that computes a cumulative hash value at the computational cost of hashing only new records (e.g., hashing patch queues with version identifiers 18-21 rather than hashing patch queues with version identifiers 0-21).
  • the server(s) 104 is unaware of the contents of the account data, but the server(s) 104 is able to act as a broker to share updates among the devices 112.
  • the devices 112 are able to identify unexpected results. For example, if a computed hash value does not match an expected hash value specified by a patch queue, the client devices 112 may reject the patch queue and refrain from updating a local instance of the account database. If, however, the hash values match, the client device 112 may accept the patch queue, and update the local instance of the account database using the patch queue (e.g., to add new messages, remove deleted messages, etc.). Similarly, if digital signature validation fails, the devices 112 may reject the patch queue and refrain from updating a local instance of the account database. If the digital signature is verified, the client device 112 may accept the patch queue, and update the local instance of the account database using the patch queue.
  • a device 112 may generate a patch queue responsive to one or more predefined triggers.
  • the triggers may include, but are not limited to, expiration of a predefined time interval (e.g., 1 second, 1 minute, 1-hour intervals, etc.), receipt of anew message, sending a new message, creating a new messaging thread, adding a contact record, deleting a contact record, deleting a message, archiving a message, pinning a message, starring a contact record, including an emoji in a message, deleting a message thread, etc.
  • a predefined time interval e.g., 1 second, 1 minute, 1-hour intervals, etc.
  • the devices 112 and/or the server(s) 104 may operate in a push/pull model. For example, a device 112 may generate and push a patch queue to the server(s) 104 any time an account update is detected. As another example, the server(s) 104 may request updates from a device 112 (e.g., a pull model). Furthermore, the server(s) 104 may push updates (e.g., one or more patch queues) to devices 112, e.g., according to predefined time intervals for pushing updates and/or when a device 112 returns to an online state. As another example, each device 112 may request, or pull, updates from the server(s) 104. Regardless of the model used, the sharing of patch queues allows all devices 112 registered to an account to synchronize instances of the messaging database for the account.
  • a device 112 may generate and push a patch queue to the server(s) 104 any time an account update is detected.
  • the server(s) 104 may request updates from a device
  • different devices 112-n may send conflicting commands to the server(s) 104 via one or more patch queues.
  • a client device 112-1 registered to an account may pin a message in a messaging interface of the messaging client, while a client device 112-2 may delete the message in the messaging interface of the messaging client.
  • the devices 112-n and/or the server(s) 104 may therefore apply different conflict resolution rules to resolve conflicting operations in different patch queues.
  • a “default” rule may specify that an action performed later in time is the operation that is effectuated by the system 100.
  • the server(s) 104 and/or the devices 112-1 may select the later in time operation, and implement the later in time operation.
  • the deletion operation performed by the device 112-2 occurs later than the pinning operation performed by device 112-1, the deletion operation is selected, and the message is deleted across all registered devices.
  • the rules are based on a type of the operation.
  • the conflict resolution rule may specify to compute a union of the deleted messages specified in each patch queue and delete all messages in the union. For example, if a first patch queue specifies to delete messages having IDs of 1, 2, 3, and a second patch queue species to delete messages 1, 3, and 4, the union may be messages 1, 3, and messages 1, 3 may be deleted from all devices 112 registered to the account.
  • cryptographic keys may be provided for an account and/or for communication threads between two or more accounts.
  • the system 100 may securely distribute encryption keys to the devices 112 using a secure cryptographic protocol that guarantees forward secrecy of the encryption keys.
  • a secure cryptographic protocol that guarantees forward secrecy of the encryption keys.
  • One example of such a protocol is the Signal Protocol. Examples may also utilize the anonymous key agreement protocol Elliptic Curve Diffie-Hellman (ECDH). Nonetheless, other encryption protocols and key agreement protocols may also be suitable.
  • the system 100 may generate new keys for an account and/or communication thread for any feasible reason .
  • the system 100 may generate new encryption keys responsive to user input. For example, if device 112-4 is a publicly accessible device, and a user accesses their account using device 112-4, the user may specify to revoke the keys once the user is finished using device 112-4. Doing so causes device 112-4 to be removed from the account. As another example, if device 112-3 access the account on a public data network, the user may specify to revoke the keys, which removes device 112-3 from the account.
  • the system 100 may programmatically revoke the keys and generate new keys based on detected events (e.g., the user accessing an account from a public device and/or a public or open data network). Furthermore, when the system 100 generates and distributes new encryption keys, the new encryption keys are transmitted to only those devices that remain associated with the account, but not any other devices (e.g., devices 113-3 and/or 112-4).
  • detected events e.g., the user accessing an account from a public device and/or a public or open data network.
  • the new encryption keys are transmitted to only those devices that remain associated with the account, but not any other devices (e.g., devices 113-3 and/or 112-4).
  • the communication system 100 may be configured to communicate with other communication systems, which may, according to examples, form a cross-platform messaging system. While the exemplary system illustrated in FIG. 1 and the features thereof were described for a messaging platform, it may not be limited thereto and may broadly include other types of systems, such as a computer system, for messaging platforms. Thus, it may be understood the examples described in further detail below may be implemented via the other types of systems.
  • FIG. 2A depicts an exemplary user interface 200 of a messaging client executing on a client device 112-1.
  • the user interface 200 includes message threads 202, 204, 206 for three different message threads of a first account.
  • the messaging client on the client device 112-1 may be registered to the first account.
  • an instance of a messaging account database for the first account may be stored on the client device 112-1.
  • the data for each thread 202-206 may be stored in the messaging account database for the first user account.
  • the threads 202-206 may include communications between two users (e.g., thread 202), while some threads may include group messaging threads (e.g., threads 204, 206).
  • multiple devices may be registered to the first account in the messaging system 100. Therefore, the messaging client may include logic to generate patch queues as described in greater detail herein.
  • the patch queue(s) may be encrypted using the encryption keys for the first account.
  • the patch queues reflect updates to the first account that may be used by other client devices 112-n to synchronize their respective instances of the messaging account database with the changes reflected in the messaging account database on the client device 112-1.
  • the messaging client on client device 112-1 may generate one or more patch queues to reflect the newly received messages.
  • the messaging client on client device 112-1 may then transmit the one or more patch queues to the server(s) 104 for storage and retrieval by other client devices 112-n registered to the first account.
  • FIG. 2B illustrates the user interface 200 of the messaging client on a second client device 112-2 that is registered to the first account.
  • the user interface 200 on client device 112-2 only includes message thread 206.
  • the client device 112-2 may be offline for some period of time, and has therefore not been updated and/or synchronized to include message threads 202, 204 depicted in Figure 2A.
  • the messaging client of client device 112-2 may request updates to the account from the server(s) 104.
  • the request for updates may include an account identifier, a version identifier of the latest patch queue used or otherwise stored by the messaging client on client device 112-2, and any other data.
  • the server(s) 104 may then identify the patch queues sent by client device 112-1 and transmit the identified patch queues to client device 112-2. As stated, however, in some examples, the server(s) 104 may generate a snapshot of the patch queues to include all needed updates for client device 112-2.
  • FIG. 2C illustrates the user interface 200 of the messaging client on the second client device 112-2 subsequent to receiving the patch queue(s) from the server(s) 104.
  • the messaging client on client device 112-2 may decrypt the patch queue(s) using the encryption keys for the first account. If the decryption is successful, the messaging client on client device 112-2 may validate the received patch queue(s), e.g., by hash verification and/or digital signature verification, etc. Once validated, the messaging client on client device 112-2 may use the patch queue(s) to update the messaging account database on the client device 112-2. Doing so may cause the messaging threads 202, 204 and all associated data to be stored in the messaging account database on the client device 112-2.
  • the GUI 200 of the messaging client on client device 112-2 may then be refreshed using the updated messaging account database on the client device 112-2.
  • the GUI 200 of messaging client on client device 112-2 has been updated to include messaging threads 202, 204, and 206.
  • the messaging client and messaging account database on client device 112-2 is synchronized with the messaging client and messaging account database on client device 112-1.
  • the synchronization preserves the security of the first account, as the server(s) 104 are not aware of the contents of the message threads 202, 204, 206. Doing so also maintains the end-to-end encryption provided by the system 100.
  • the smaller patch queues are transmitted to reflect a subset of the messaging database for the first account. Doing so conserves bandwidth, energy consumption, and other computing resources.
  • the patch queues may be used to propagate any type of change within the messaging system 100 to other devices.
  • FIG. 2D depicts an example where the chat thread 202 with User A is deleted using the user interface 200 of messaging client on client device 112-2.
  • the messaging client on client device 112-2 may generate at least one patch queue to reflect the deletion.
  • the at least one patch queue may be encrypted using the encryption keys for the first account.
  • the messaging client on client device 112-2 may then transmit the patch queue to the server(s) 104, where the patch queue may be accessed by other devices 112.
  • FIG. 2E depicts an example where the messaging client on client device 112-1 receives the patch queue from the server(s) 104.
  • the messaging client on client device 112-1 may decrypt the patch queue using the encryption keys for the first account. If the decryption is successful, the messaging client on client device 112-1 may validate the received patch queue, e.g., by hash verification and/or digital signature verification, etc. Once validated, the messaging client on client device 112-1 may use the patch queue to update the messaging account database on the client device 112-1. Doing so may cause the messaging threads 202 and all associated data to be deleted from the messaging account database on the client device 112-1. The GUI 200 of the messaging client on client device 112-1 may then be refreshed using the updated messaging account database on the client device 112-1.
  • GUI 200 of messaging client on client device 112-2 has been updated to remove messaging thread 202, while messaging threads 204 and 206 remain.
  • the messaging client and messaging account database on client device 112-1 is synchronized with the messaging client and messaging account database on client device 112-2.
  • FIG. 3 depicts an exemplary data flow diagram 300.
  • the data flow diagram 300 shows the communicative interaction among at least the client device 112-1, the one or more intermediate messaging servers 104, and the client device 112-2.
  • a user associated with a first account may engage in an authentication process with the server(s) 104.
  • authentication process 302 may involve at least the user entering or inputting one or more different types of credentials, such as a one-time PIN (OTP) code, login ID and password, biometric information (e.g., fingerprint scan), etc.
  • OTP one-time PIN
  • User authentication may be required to log in to the messaging server 104, or in other instances, user authentication may be required for specific types of operations, such as cash payment or transfers.
  • the first user may be automatically accepted as a verified user after having successfully logging in to the first account in a previous instance.
  • the authentication 302 includes the server 104 distributing encryption keys for the first account to the messaging client on client device 112-1 using a secure protocol.
  • the messaging client executing on client device 112-1 may receive messaging updates 304 from the server(s) 104.
  • the messaging updates 304 may include one or more patch queues.
  • the patch queues are generated by one or more other client devices 112 registered to the first account.
  • the server(s) 104 may generate a snapshot patch queue from the patch queues generated by the other client devices 112 registered to the first account.
  • the messaging client on client device 112-1 may decrypt the patch queue(s) received at 304 using the cryptographic keys associated with the first account.
  • the messaging client on client device 112-1 may further perform hash verification (or validation), by computing a hash value for the patch queues and comparing the computed hash value to an expected hash value specified in the patch queues received at 304. If the decryption is successful and the comparison results in a match, the messaging client on client device 112-1 may update an instance of the messaging database for the first account on client device 112-1. As stated, however, in some examples, the messaging client on client device 112-1 may further validate a digital signature of the patch queue before updating the messaging database for the first account.
  • the messaging updates 304 may include one or more new messages. Therefore, the messaging database is updated at 306 to include the new message, and the GUI of the messaging client on client device 112-1 may be updated to reflect the new message. Furthermore, based on the receipt of the new message, the messaging client on client device 112-1 may generate a patch queue at 308.
  • the messaging client on client device 112-1 may generally include an ID, value, expected hash value, digital signature, timestamp of the message, and any other metadata in the patch queue.
  • the messaging client on client device 112-1 may then encrypt the patch queue using the encryption keys for the first account.
  • the messaging client on client device 112-1 may then transmit the encrypted patch queue as at least a portion of a data package to the server(s) 104 for storage.
  • the messaging client on client device 112-2 may engage in authentication 310 as described above. Doing so may associate the messaging client on client device 112-2 with the first account (if not previously associated) and may optionally include the messaging client on client device 112-2 receiving encryption keys for the first account.
  • the messaging client on client device 112-2 may receive one or more patch queue(s) from the server 104.
  • the messaging client on client device 112-2 may decrypt the patch queue using the encryption keys for the first account. If the decryption is successful, the messaging client on client device 112-2 may perform hash verification for the received patch queues, e.g., computing a hash value for the patch queue and comparing the computed value to the expected value specified in the patch queue.
  • the messaging client on client device 112-2 may update the messaging account database on the client device 112-2. Doing so may store the message received at 304 by client device 112-1 in the messaging account database on client device 112-2. The GUI for the messaging client on client device 112-2 may then be updated using the account database. Doing so allows the user to view the new message via the messaging client on client device 112-2 and/or the messaging client on client device 112-1.
  • FIG. 4 depicts an exemplary data flow diagram 400.
  • authentication 402 of the first account on client device 112-1 may be performed via the authentication techniques (e.g., OTP, user login and password, biometric access, etc.) described above.
  • the messaging client executing on client device 112-1 may receive messaging updates 404 from the server(s) 104.
  • the messaging updates 404 may include one or more patch queues.
  • the patch queues are generated by one or more other client devices 112 registered to the first account.
  • the server(s) 104 may generate a snapshot patch queue from the patch queues generated by the other client devices 112 registered to the first account.
  • the messaging client on client device 112-1 may decrypt the patch queue(s) received at 404 using the cryptographic keys associated with the first account.
  • the messaging client on client device 112-1 may further perform digital signature verification (or validation), by using a public key to decrypt a digital signature specified in the patch queues. If the decryption is successful and the digital signature is verified, the messaging client on client device 112-1 may update an instance of the messaging database for the first account on client device 112-1. As stated, however, in some examples, the messaging client on client device 112-1 may further validate a hash value of the patch queue before updating the messaging database for the first account.
  • the messaging updates 404 may include one or more new messages. Therefore, the messaging database is updated at 406 to include the new message, and the GUI of the messaging client on client device 112-1 may be updated to reflect the new message. Furthermore, based on the receipt of the new message, the messaging client on client device 112-1 may generate a patch queue at 408.
  • the messaging client on client device 112-1 may generally include an ID, value, expected hash value, digital signature, timestamp of the message, and any other metadata in the patch queue.
  • the messaging client on client device 112-1 may then encrypt the patch queue using the encryption keys for the first account.
  • the messaging client on client device 112-1 may then transmit the encrypted patch queue as at least a portion of a data package to the server(s) 104 for storage.
  • the messaging client on client device 112-2 may engage in authentication 410 as described above.
  • the messaging client on client device 112-2 may receive one or more patch queue(s) from the server 104.
  • the messaging client on client device 112-2 may decrypt the patch queue using the encryption keys for the first account. If the decryption is successful, the messaging client on client device 112-2 may attempt to validate the digital signature of the patch queue using the public key of the first account.
  • the messaging client on client device 112-2 may update the messaging account database on the client device 112-2. Doing so may store the message received at 404 by client device 112-1 in the messaging account database on client device 112-2. The GUI for the messaging client on client device 112-2 may then be updated using the account database. Doing so allows the user to view the new message via the messaging client on client device 112-2 and/or the messaging client on client device 112-1.
  • FIG. 5 depicts an exemplary data flow diagram 500.
  • authentication 502 of the first account on client device 112-1 may be performed via the authentication techniques (e.g., OTP, user login and password, biometric access, etc.) described above.
  • the messaging client on client device 112-1 may receive messaging updates 504 from the server(s) 104.
  • the messaging updates 504 may include one or more patch queues.
  • the patch queues are generated by one or more other client devices 112 registered to the first account.
  • the server(s) 104 may generate a snapshot patch queue from the patch queues generated by the other client devices 112 registered to the first account.
  • the messaging client on client device 112-1 may decrypt the patch queue, perform hash verification, perform digital signature verification, and update the account database on the client device 112-1, e.g., to reflect the operation specified by messaging update 504.
  • the messaging client on client device 112-1 may generally include an ID, value, expected hash value, digital signature, timestamp of the message, and any other metadata in the patch queue.
  • the messaging client on client device 112-1 may then encrypt the first patch queue using the encryption keys for the first account, thereby yielding a first encrypted patch queue.
  • the messaging client on client device 112-1 may then transmit the first encrypted patch queue as at least a portion of a data package to the server(s) 104 for storage.
  • the messaging client on client device 112-2 may engage in authentication as described above.
  • the messaging client on client device 112-2 may receive one or more messaging updates from the server(s) 104.
  • the messaging updates 512 may include one or more patch queues.
  • the messaging client on client device 112-2 may decrypt the patch queue, perform hash verification, perform digital signature verification, and update the account database on the client device 112-2, e.g., to reflect the operation specified by messaging update 512.
  • the messaging client on client device 112-2 may generally include an ID, value, expected hash value, digital signature, timestamp of the message, and any other metadata in the patch queue.
  • the messaging client on client device 112-2 may then encrypt the first patch queue using the encryption keys for the first account, thereby yielding a second encrypted patch queue.
  • the messaging client on client device 112- 2 may then transmit the second encrypted patch queue as at least a portion of a data package to the server(s) 104 for storage.
  • the server(s) 104 may determine a conflict based on the first and second encrypted patch queues, e.g., based on detection of conflicting operations. However, as stated, because the patch queues are encrypted, the server(s) 104 are unaware of the underlying user data. Advantageously, however, the server(s) 104 may process the encrypted data without knowing the underlying data. The server(s) 104 may then determine one or more conflict resolution rules, e.g., the conflict resolution rule for a type of the conflicting operations. Based on the determined rule(s), the server(s) 104 may merge the first and second encrypted patch queues. Doing so ensures that the proper operations are implemented.
  • conflict resolution rules e.g., the conflict resolution rule for a type of the conflicting operations.
  • the server(s) 104 may create a merged patch queue that specifies to delete the union of the messages, e.g., the first and second messages.
  • the server(s) 104 may generate a merged patch queue that reflects the operations that result when the conflict resolution rules are applied.
  • the merged patch queue may specify to delete the first and second messages from the account.
  • the server(s) 104 may generally include one or more IDs, one or move values, an expected hash value, a digital signature, and any other metadata in the merged patch queue.
  • the server(s) 104 may then transmit the merged patch queue to all available devices that are registered to the account to synchronize all available devices, including the devices 112-1 and 112-2.
  • the devices 112-1 and 112-2 update their respective messaging databases using the merged patch queue.
  • the devices 112-1 and 112-2 may generally decrypt the merged patch queue, verify the hash value, and verify the digital signature before updating the messaging databases at 520.
  • FIG. 6 depicts an exemplary data flow diagram 600.
  • the system 100 and components thereof will be used to describe the features of the flow diagram 600 of FIG. 6.
  • authentication 602 of the first account on client device 112-1 may be performed via the authentication techniques (e.g., OTP, user login and password, biometric access, etc.) described above.
  • the messaging client on client device 112-1 may receive messaging updates 604 from the server(s) 104.
  • the messaging updates 604 may be any type of operation for the first account.
  • the messaging client on client device 112- 1 may generate a first encrypted patch queue for the first account based on the messaging updates 604.
  • the messaging client on client device 112-1 may then transmit the first encrypted patch queue to the server(s) 104 for storage.
  • the messaging client on client device 112-2 may engage in authentication as described above.
  • the messaging client on client device 112-2 may receive input specifying to revoke client device 112-1 from the first account. Therefore, the messaging client on client device 112-2 may generate and transmit a patch queue specifying to revoke client device 112-1 from the first account.
  • the server(s) 104 may revoke any existing encryption keys for the first account and generate new encryption keys for the first account. The server(s) 104 may further remove the client device 112-1 form the first account.
  • the server(s) 104 transmit the new encryption keys to device 112-2 (and any other online devices 112 that remain registered to the first account), but not to device 112-1, which has been removed from the account.
  • the server(s) 104 may distribute the new encryption keys to these devices as well.
  • Exemplary logic for implementing the above-described examples is next described in connection with FIGs. 7-10.
  • the exemplary logic may be implemented in hardware, software, or a combination of hardware and software (e.g., being implemented at least partially in hardware).
  • FIG. 7 is a flowchart depicting exemplary logic 700 performed by a system or system components, such as one or more client devices 112 and/or the servers 104, as described above.
  • the logic 700 may be embodied as digital logic, which may be implemented at least partially in hardware, embodying instructions for a processor circuit to perform the steps described below.
  • FIG. 7 depicts a particular arrangement of logical elements in a particular order, it is understood that the configuration depicted in FIG. 7 is but one example. In other examples, more elements may be provided and/or some elements may be omitted, some elements may be performed in parallel, and/or elements may be performed in a different order.
  • a messaging client on a first client device 112-1 may receive a data package.
  • the data package may comprise a patch queue for a first account.
  • the messaging client on the first client device 112-1 may decrypt the encrypted patch queue in the data package using encryption keys for the first account.
  • the messaging client on the first client device 112-1 may compute a hash value for the data package and/or a portion of the data package (e.g., the decrypted patch queue).
  • the messaging client on the first client device 112-1 compares the hash value computed at block 706 to a hash value specified in the decrypted patch queue.
  • the messaging client on the first client device 112-1 determines that the comparison at block 708 results in a match.
  • the messaging client on the first client device 112- 1 updates the messaging database on the first client device 112-1 using the decrypted patch queue based on the comparison resulting in a match.
  • the messaging client on the first client device 112-1 may further perform digital signature verification prior to updating the messaging database.
  • FIG. 8 is a flowchart depicting exemplary logic 800 performed by a system or system components, such as one or more client devices 112 and/or the servers 104, as described above.
  • the logic 800 may be embodied as digital logic, which may be implemented at least partially in hardware, embodying instructions for a processor circuit to perform the steps described below.
  • FIG. 8 depicts a particular arrangement of logical elements in a particular order, it is understood that the configuration depicted in FIG. 8 is but one example. In other examples, more elements may be provided and/or some elements may be omitted, some elements may be performed in parallel, and/or elements may be performed in a different order.
  • a messaging client on a first client device 112-1 may receive a data package.
  • the data package may comprise a patch queue for a first account.
  • the messaging client on the first client device 112-1 may decrypt the encrypted patch queue in the data package using encryption keys for the first account.
  • the messaging client on the first client device 112-1 may perform hash validation, e.g., by computing a hash value for the data package and/or a portion of the data package (e.g., the decrypted patch queue), and determining the computed hash value matches a hash value specified in the decrypted patch queue.
  • the messaging client on the first client device 112-1 validates the digital signature using the public key associated with the account. Generally, if the public key is able to decrypt the digital signature, the digital signature is validated.
  • the messaging client on the first client device 112-1 updates the messaging database on the first client device 112-1 using the decrypted patch queue based on the verification of the digital signature and the verification of the hash value.
  • FIG. 9 is a flowchart depicting exemplary logic 900 performed by a system or system components, such as one or more client devices 112 and/or the servers 104, as described above.
  • the logic 900 may be embodied as digital logic, which may be implemented at least partially in hardware, embodying instructions for a processor circuit to perform the steps described below.
  • FIG. 9 depicts a particular arrangement of logical elements in a particular order, it is understood that the configuration depicted in FIG. 9 is but one example. In other examples, more elements may be provided and/or some elements may be omitted, some elements may be performed in parallel, and/or elements may be performed in a different order.
  • a server 104 and/or a client device 112 may receive a first encrypted data package and a second encrypted data package.
  • the first and second encrypted data packages may comprise a first encrypted patch queue and a second encrypted patch queue, respectively, for a first account.
  • the server 104 and/or the client device 112 may determine one or more conflict rules for processing conflicting operations specified in the first and second patch queues.
  • the server 104 and/or the client device 112 may merge the first and second encrypted patch queues based on the determined conflict rules to generate a merged encrypted patch queue (e.g., a merged encrypted data package).
  • the server 104 and/or client device 112 may store the merged encrypted patch queues generated at block 906.
  • the client devices 112 registered to the first account may use the merged encrypted patch queues to update instance of the messaging account database for the first account as described in greater detail herein (e.g., decryption, hash verification, and/or digital signature verification).
  • FIG. 10 is a flowchart depicting exemplary logic 1000 performed by a system or system components, such as one or more client devices 112 and/or the servers 104, as described above.
  • the logic 1000 may be embodied as digital logic, which may be implemented at least partially in hardware, embodying instructions for a processor circuit to perform the steps described below.
  • FIG. 10 depicts a particular arrangement of logical elements in a particular order, it is understood that the configuration depicted in FIG. 10 is but one example. In other examples, more elements may be provided and/or some elements may be omihed, some elements may be performed in parallel, and/or elements may be performed in a different order.
  • a server 104 and/or a second client device 112-2 may receive a first encrypted data package from a first client device 112-1.
  • the first encrypted data package may comprise a patch queue for a first account.
  • the first and second devices 112-1, 112-2 may be registered to the first account.
  • the server 104 may receive an instruction to revoke the first client device 112-1 from the first account, e.g., from the second client device 112-2 and/or the first client device 112-1.
  • the server 104 may revoke the encryption keys for the first account and remove the first device 112-1 from the first account.
  • the server 104 may generate a new set of encryption keys for the first account.
  • the server 104 may use a secure protocol to distribute the new set of encryption keys generated at block 1008 to any device 112 that remains associated with the first account, which includes device 112-2, but does not include device 112-1.
  • FIGS. 11A and 11B depict various examples of communications systems and are discussed in more detail below.
  • FIG. 11A depicts an exemplary centralized communications system 1100, which facilitates encrypted communication between two or more users (e.g., business page user and a potential customer user).
  • the centralized system 1100 may implement some or all of the structure and/or operations of a messaging or communications service in a single computing entity, such as entirely within a single centralized messaging server device, e.g., communications server 1126.
  • the centralized system 1110 may further implement all systems, logic, apparatuses, methods, and functionality described herein with reference to FIGs. 1-10.
  • the communications system 1100 may include a computer-implemented system having software applications that include one or more components. Although the communications system 1100 shown in FIG. 11A has a limited number of elements in a certain topology, the communications system 1100 may include more or fewer elements in alternate topologies.
  • a communications system 1100 may be generally arranged to receive, store, and deliver communications, such as messages.
  • the communications may include or may be associated with media or content items.
  • a client device 1110 may transmit communications addressed to one or more recipient users, user accounts, or other identifiers resolving to receiving client devices 1110.
  • the client devices 1110 are representative of the client devices 112-1 through 112-n of Figure 1.
  • each of the client devices 1110 and their respective messaging clients 1120 are associated with a particular user or users of the communications service 1100.
  • the client devices 1110 may be cellular devices such as smartphones and may be identified to the communications service 1100 based on a phone number associated with each of the client devices 1110.
  • each client may be associated with a user account registered with the communications service 1100.
  • each client may be addressed through various techniques for the reception of communications. While in some examples the client devices 1110 may be cellular devices, in other examples one or more of the client devices 1110 may be personal computers, tablet devices, any other form of computing device.
  • the client 1110 may include one or more input devices 1112 and one or more output devices 1118.
  • the input devices 1112 may include, for example, microphones, keyboards, cameras, electronic pens, touch screens, and other devices for receiving inputs including message data, requests, commands, user interface interactions, selections, and other types of input.
  • the output devices 1118 may include a speaker, a display device such as a monitor or touch screen, and other devices for presenting an interface to the communications system 1100.
  • the client 1110 may include a memory, which may be a non-transitory computer readable storage medium, such as one or a combination of a hard drive, solid state drive, flash storage, read only memory, or random-access memory.
  • the memory may a representation of an input 1114 and/or a representation of an output 1116, as well as one or more applications.
  • the memory may store a messaging client 1120 and/or a social networking client that allows a user to interact with a social networking service.
  • the input 1114 may be textual, such as in the case where the input device 1112 is a keyboard.
  • the input 1114 may be an audio or video recording, such as in the case where the input device 1112 is a microphone or camera.
  • the input 1114 may be subjected to automatic speech recognition (ASR) logic in order to transform the audio recording to text that is processable by the communication system.
  • ASR automatic speech recognition
  • the ASR logic may be located at the client device 1110 (so that the audio recording is processed locally by the client 1110 and corresponding text is transmitted to the communications server 1126), or may be located remotely at the communications server 1126 (in which case, the audio recording may be transmitted to the communications server 1126 and the communications server 1126 may process the audio into text).
  • Other combinations are also possible — for example, if the input device 1112 is a touch pad or electronic pen, the input 1114 may be in the form of handwriting, which may be subjected to handwriting or optical character recognition analysis logic in order to transform the input 1112 into processable text.
  • the client 1110 may be provided with a network interface 1122 for communicating with a network 1124, such as the Internet.
  • the network interface 1122 may transmit the input 1112 in a format and/or using a protocol compatible with the network 1124 and may receive a corresponding output 1116 from the network 1124.
  • the network interface 1122 may communicate through the network 1124 to a communications server 1126, which may be operative to receive, store, and forward messages between messaging clients.
  • the communications server 1126 may include a network interface 1122, communications preferences 1128, and communications logic 1130.
  • the communications preferences 1128 may include one or more privacy settings for one or more users and/or video communications.
  • the communications preferences 1128 may include one or more settings, including default settings, for the logic described herein.
  • the server 1126 is representative of the server(s) 104 of Figure 1.
  • the communications logic 1130 may include digital content anti-counterfeiting logic 1132 for at least generating one or more sensor responsive elements and configuring digital content being communicated in the network with the generated sensor responsive elements via the communications server 1126, as described above.
  • the network interface 1122 of the client 1110 and/or the communications server 1126 may also be used to communicate through the network 1124 with a social networking server 1136.
  • the social networking server 1136 may include or may interact with a social networking graph 1138 that defines connections in a social network.
  • the communications server 1126 may connect to the social networking server 1136 for various purposes, such as retrieving connection information, messaging history, event details, etc. from the social network.
  • a user of the client 1110 may be an individual (human user), an entity (e.g., an enterprise, business, or third-party application), or a group (e.g., of individuals or entities) that interacts or communicates with or over the social networking server 1136.
  • the social networking server 1136 may be a network-addressable computing system hosting an online social network.
  • the social networking server 1136 may generate, store, receive, and send social-networking data, such as, for example, user-profile data, concept-profile data, social- graph information, or other suitable data related to the online social network.
  • the social networking server 1136 may be accessed by the other components of the network environment either directly or via the network 1124.
  • the social networking server 1136 may include an authorization server (or other suitable component(s)) that allows users to opt in to or opt out of having their actions logged by social networking server 1136 or shared with other systems (e.g., third-party systems, such as the communications server 1126), for example, by setting appropriate privacy settings.
  • a privacy setting of a user may determine what information associated with the user may be logged, how information associated with the user may be logged, when information associated with the user may be logged, who may log information associated with the user, whom information associated with the user may be shared with, and for what purposes information associated with the user may be logged or shared.
  • Authorization servers may be used to enforce one or more privacy settings of the users of social networking server 1136 through blocking, data hashing, anonymization, or other suitable techniques as appropriate.
  • one or more of the content objects of the online social network may be associated with a privacy setting.
  • the privacy settings (or “access settings”) for an object may be stored in any suitable manner, such as, for example, in association with the object, in an index on an authorization server, in another suitable manner, or any combination thereof.
  • a privacy setting of an object may specify how the object (or particular information associated with an object) can be accessed (e.g., viewed or shared) using the online social network. Where the privacy settings for an object allow a particular user to access that object, the object may be described as being “visible” with respect to that user.
  • a user of the online social network may specify privacy settings for a user-profile page identify a set of users that may access the work experience information on the user-profile page, thus excluding other users from accessing the information.
  • the privacy settings may specify a “blocked list” of users that should not be allowed to access certain information associated with the object.
  • the blocked list may specify one or more users or entities for which an object is not visible.
  • a user may specify a set of users that may not access photos albums associated with the user, thus excluding those users from accessing the photo albums (while also possibly allowing certain users not within the set of users to access the photo albums).
  • privacy settings may be associated with particular elements of the social networking graph 1138.
  • Privacy settings of a social-graph element such as a node or an edge, may specify how the social-graph element, information associated with the social- graph element, or content objects associated with the social-graph element can be accessed using the online social network.
  • a particular concept node corresponding to a particular photo may have a privacy setting specifying that the photo may only be accessed by users tagged in the photo and their friends.
  • privacy settings may allow users to opt in or opt out of having their actions logged by social networking server 1136 or shared with other systems.
  • the privacy settings associated with an object may specify any suitable granularity of permitted access or denial of access.
  • access or denial of access may be specified for particular users (e.g., only me, my roommates, and my boss), users within a particular degrees-of-separation (e.g., friends, or friends-of-friends), user groups (e.g., the gaming club, my family), user networks (e.g., employees of particular employers, students or alumni of particular university), all users (“public”), no users (“private”), users of third-party systems, particular applications (e.g., third-party applications, external websites), other suitable users or entities, or any combination thereof.
  • this disclosure describes using particular privacy sehings in a particular manner, this disclosure contemplates using any suitable privacy settings in any suitable manner.
  • the social networking server 1136 may send a request to the data store for the object.
  • the request may identify the user associated with the request.
  • the requested data object may only be sent to the user (or a client system 1110 of the user) if the authorization server determines that the user is authorized to access the object based on the privacy settings associated with the object. If the requesting user is not authorized to access the object, the authorization server may prevent the requested object from being retrieved from the data store, or may prevent the requested object from be sent to the user.
  • an object may only be generated as a search result if the querying user is authorized to access the object. In other words, the object must have a visibility that is visible to the querying user. If the object has a visibility that is not visible to the user, the object may be excluded from the search results.
  • targeting criteria may be used to identify users of the social network for various purposes.
  • Targeting criteria used to identify and target users may include explicit, stated user interests on social networking server 1136 or explicit connections of a user to a node, object, entity, brand, or page on social networking server 1136.
  • such targeting criteria may include implicit or inferred user interests or connections (which may include analyzing a user’s history, demographic, social or other activities, friends’ social or other activities, subscriptions, or any of the preceding of other users similar to the user (based, e.g., on shared interests, connections, or events)).
  • Particular examples may utilize platform targeting, which may involve platform and “like” impression data; contextual signals (e.g., “Who is viewing now or has viewed recently the page for Example Corp.?”); light-weight connections (e.g., “check-ins”); connection lookalikes; fans; extracted keywords; EMU advertising; inferential advertising; coefficients, affinities, or other social-graph information; friends-of-friends connections; pinning or boosting; deals; polls; household income, social clusters or groups; products detected in images or other media; social- or open-graph edge types; geo-prediction; views of profile or pages; status updates or other user posts (analysis of which may involve natural-language processing or keyword extraction); events information; or collaborative filtering. Identifying and targeting users may also implicate privacy settings (such as user opt-outs), data hashing, or data anonymization, as appropriate.
  • contextual signals e.g., “Who is viewing now or has viewed recently the page for Example Corp.?”
  • light-weight connections e.g.,
  • FIG. 11A depicts an exemplary distributed communications system 1150, in which functionality for selecting dominant/relevant participants and displaying a reduced-size interface is distributed and remotely accessible from the messaging server.
  • the distributed communications system 1150 may further implement all systems, logic, apparatuses, methods, and functionality described herein with reference to FIGs. 1-10.
  • Examples of a distributed system 1150 include a client-server architecture, a 3- tier architecture, an N-tier architecture, a tightly coupled or clustered architecture, a peer-to- peer architecture, a master-slave architecture, a shared database architecture, and other types of distributed systems.
  • FIG. 11B Many of the components depicted in FIG. 11B are identical to those in FIG. 11A, and a description of these elements is not repeated here for the sake of brevity.
  • the primary difference between the centralized example and the distributed example is the addition of a separate messaging server 1152, which hosts the relevant messaging logic 1132.
  • the messaging server 1152 may be distinct from the communications server 1126 but may communicate with the communications server 1126, either directly or through the network 1124, to provide the functionality of the messaging logic 1132 to the communications server 1126.
  • the example depicted in FIG. 11B may be particularly well suited to the example to be deployed alongside existing messaging or communication systems, for example when it is difficult or undesirable to replace an existing messaging server.
  • the communications server 1126 may have limited resources (e.g., processing or memory resources) that limit or preclude the addition of the additional pivot functionality. In such situations, the capabilities described herein may still be provided through a separate messaging server, such as the messaging server 1152.
  • FIG. 12 illustrates an example of a plurality of servers implementing various functions of a messaging service 1200. It will be appreciated that different distributions of work and functions may be used in various examples of a messaging service 1200.
  • the messaging service 1200 may comprise a domain name front end 1202.
  • the domain name front end 1202 may be assigned one or more domain names associated with the messaging service 1200 in a domain name system (DNS).
  • DNS domain name system
  • the domain name front end 1202 may receive incoming connections and distribute the connections to servers providing various messaging services via a network bus 1206.
  • the messaging service 1202 may comprise one or more chat servers 1204.
  • the chat servers 1204 may comprise front-end servers for receiving and transmitting user-to-user messaging updates such as chat messages. Incoming connections may be assigned to the chat servers 1204 by the domain name front end 1202 based on workload balancing.
  • the messaging service 1200 may comprise backend servers 1208.
  • the backend servers 1208 may perform specialized tasks in the support of the chat operations of the front- end chat servers 1204.
  • a plurality of different types of backend servers 1208 may be used. It will be appreciated that the assignment of types of tasks to different backend serves 1208 may vary in different examples.
  • some of the back-end services provided by dedicated servers may be combined onto a single server or a set of servers each performing multiple tasks divided between different servers in the example described herein.
  • tasks of some of dedicated back-end servers described herein may be divided between different servers of different server groups.
  • the messaging service 1200 may comprise one or more offline storage servers 1210.
  • the one or more offline storage servers 1210 may store messaging content for currently offline messaging clients in hold for when the messaging clients reconnect.
  • the messaging service 1200 may comprise one or more sessions servers 1212.
  • the one or more session servers 1212 may maintain session state of connected messaging clients.
  • the messaging service 1200 may comprise one or more presence servers 1214.
  • the one or more presence servers 1214 may maintain presence information for the messaging service 1200. Presence information may correspond to user-specific information indicating whether or not a given user has an online messaging client and is available for chatting, has an online messaging client but is currently away from it, does not have an online messaging client, and any other presence state.
  • the messaging service 1200 may comprise one or more push storage servers 1216.
  • the one or more push storage servers 1216 may cache push requests and transmit the push requests to messaging clients.
  • Push requests may be used to wake messaging clients, to notify messaging clients that a messaging update is available, and to otherwise perform server-side- driven interactions with messaging clients.
  • the messaging service 1200 may comprise one or more group servers 1218.
  • the one or more group servers 1218 may maintain lists of groups, add users to groups, remove users from groups, and perform the reception, caching, and forwarding of group chat messages.
  • the messaging service 1200 may comprise one or more block list servers 1220.
  • the one or more block list servers 1220 may maintain user-specific block lists, the user-specific incoming-block lists indicating for each user the one or more other users that are forbidden from transmitting messages to that user.
  • the one or more block list servers 1220 may maintain user-specific outgoing-block lists indicating for each user the one or more other users that that user is forbidden from transmitting messages to. It will be appreciated that incoming-block lists and outgoing-block lists may be stored in combination in, for example, a database, with the incoming-block lists and outgoing-block lists representing different views of a same repository of block information.
  • the messaging service 1200 may comprise one or more last seen information servers 1222.
  • the one or more last seen information servers 1222 may receive, store, and maintain information indicating the last seen location, status, messaging client, and other elements of a user’s last seen connection to the messaging service 1200.
  • the messaging service 1200 may comprise one or more key servers 1224.
  • the one or more key servers may host public keys for public/private key encrypted communication.
  • the messaging service 1200 may comprise one or more profile photo servers 1226.
  • the one or more profile photo servers 1226 may store and make available for retrieval profile photos for the plurality of users of the messaging service 1200.
  • the messaging service 1200 may comprise one or more spam logging servers 1228.
  • the one or more spam logging servers 1228 may log known and suspected spam (e.g., unwanted messages, particularly those of a promotional nature).
  • the one or more spam logging servers 1228 may be operative to analyze messages to determine whether they are spam and to perform punitive measures, in some examples, against suspected spammers (users that send spam messages).
  • the messaging service 1200 may comprise one or more statistics servers 1230.
  • the one or more statistics servers may compile and store statistics information related to the operation of the messaging service 1200 and the behavior of the users of the messaging service 1200.
  • the messaging service 1200 may comprise one or more web servers 1232.
  • the one or more web servers 1232 may engage in hypertext transport protocol (HTTP) and hypertext transport protocol secure (HTTPS) connections with web browsers.
  • HTTP hypertext transport protocol
  • HTTPS hypertext transport protocol secure
  • the messaging service 1200 may comprise one or more chat activity monitoring servers 1234.
  • the one or more chat activity monitoring servers 1234 may monitor the chats of users to determine unauthorized or discouraged behavior by the users of the messaging service 1200.
  • the one or more chat activity monitoring servers 1234 may work in cooperation with the spam logging servers 1228 and block list servers 1220, with the one or more chat activity monitoring servers 1234 identifying spam or other discouraged behavior and providing spam information to the spam logging servers 1228 and blocking information, where appropriate to the block list servers 1220.
  • the messaging service 1200 may comprise one or more sync servers 1236.
  • the one or more sync servers 1236 may sync a messaging system (e.g., the system 100) with contact information from a messaging client, such as an address book on a mobile phone, to determine contacts for a user in the messaging service 1200.
  • the messaging service 1200 may comprise one or more multimedia servers 1238.
  • the one or more multimedia servers may store multimedia (e.g., images, video, audio) in transit between messaging clients, multimedia cached for offline endpoints, and may perform transcoding of multimedia.
  • the messaging service 1200 may comprise one or more payment servers 1240.
  • the one or more payment servers 1240 may process payments from users.
  • the one or more payment servers 1240 may connect to external third-party servers for the performance of payments.
  • the messaging service 1200 may comprise one or more registration servers 1242.
  • the one or more registration servers 1242 may register new users of the messaging service 1200.
  • the messaging service 1200 may comprise one or more voice relay servers 1244.
  • the one or more voice relay servers 1244 may relay voice-over-intemet-protocol (VoIP) voice communication between messaging clients for the performance of VoIP calls.
  • VoIP voice-over-intemet-protocol
  • FIG. 13 illustrates an exemplary computing architecture 1300 suitable for implementing various previously described examples.
  • the computing architecture 1300 may comprise or be implemented as part of an electronic device, such as a computer 1301.
  • system and “component” are intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution, examples of which are provided by the exemplary computing architecture 1300.
  • a component can be, but is not limited to being, a process running on a processor, a processor, a hard disk drive, multiple storage drives (of optical and/or magnetic storage medium), an object, an executable, a thread of execution, a program, and/or a computer.
  • an application running on a server and the server can be a component.
  • One or more components can reside within a process and/or thread of execution, and a component can be localized on one computer and/or distributed between two or more computers. Further, components may be communicatively coupled to each other by various types of communications media to coordinate operations. The coordination may involve the uni -directional or bi-directional exchange of information. For instance, the components may communicate information in the form of signals communicated over the communications media. The information can be implemented as signals allocated to various signal lines. In such allocations, each message is a signal. Further examples, however, may alternatively employ data messages. Such data messages may be sent across various connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.
  • the computing architecture 1300 includes various common computing elements, such as one or more processors, multi-core processors, co-processors, memory units, chipsets, controllers, peripherals, interfaces, oscillators, timing devices, video cards, audio cards, multimedia input/output (I/O) components, power supplies, and so forth.
  • processors such as one or more processors, multi-core processors, co-processors, memory units, chipsets, controllers, peripherals, interfaces, oscillators, timing devices, video cards, audio cards, multimedia input/output (I/O) components, power supplies, and so forth.
  • the computing architecture 1300 comprises a processing unit 1302, a system memory 1304 and a system bus 1306.
  • the processing unit 1302 can be any of various commercially available processors, including without limitation an AMD® Athlon®, Duron® and Opteron® processors; ARM® application, embedded and secure processors; IBM® and Motorola® DragonBall® and PowerPC® processors; IBM and Sony® Cell processors; Intel® Celeron®, Core (2) Duo®, Itanium®, Pentium®, Xeon®, and XScale® processors; and similar processors. Dual microprocessors, multi-core processors, and other multi -processor architectures may also be employed as the processing unit 1302.
  • the system bus 1306 provides an interface for system components including, but not limited to, the system memory 1304 to the processing unit 1302.
  • the system bus 1306 can be any of several types of bus structure that may further interconnect to a memory bus (with or without a memory controller), a peripheral bus, and a local bus using any of a variety of commercially available bus architectures.
  • Interface adapters may connect to the system bus 1306 via a slot architecture.
  • Example slot architectures may include without limitation Accelerated Graphics Port (AGP), Card Bus, (Extended) Industry Standard Architecture ((E)ISA), Micro Channel Architecture (MCA), NuBus, Peripheral Component Interconnect (Extended) (PCI(X)), PCI Express, Personal Computer Memory Card International Association (PCMCIA), and the like.
  • the computing architecture 1300 may comprise or implement various articles of manufacture.
  • An article of manufacture may comprise a computer-readable storage medium to store logic.
  • Examples of a computer-readable storage medium may include any tangible media capable of storing electronic data, including volatile memory or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writeable or re writeable memory, and so forth.
  • Examples of logic may include executable computer program instructions implemented using any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, object-oriented code, visual code, and the like. Examples may also be at least partly implemented as instructions contained in or on a non-transitory computer-readable medium, which may be read and executed by one or more processors to enable performance of the operations described herein.
  • the system memory 1304 may include various types of computer-readable storage media in the form of one or more higher speed memory units, such as read-only memory (ROM), random-access memory (RAM), dynamic RAM (DRAM), Double-Data-Rate DRAM (DDRAM), synchronous DRAM (SDRAM), static RAM (SRAM), programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, polymer memory such as ferroelectric polymer memory, ovonic memory, phase change or ferroelectric memory, silicon-oxide-nitride-oxide-silicon (SONOS) memory, magnetic or optical cards, an array of devices such as Redundant Array of Independent Disks (RAID) drives, solid state memory devices (e.g., USB memory, solid state drives (SSD) and any other type of storage media suitable for storing information.
  • the system memory 1304 can include non-volatile memory 1308 and/or volatile memory
  • the computing architecture 1300 may include various types of computer-readable storage media in the form of one or more lower speed memory units, including an internal (or external) hard disk drive (HDD) 1312, a magnetic floppy disk drive (FDD) 1314 to read from or write to a removable magnetic disk 1316, and an optical disk drive 1318 to read from or write to a removable optical disk 1320 (e.g., aCD-ROM or DVD).
  • the HDD 1312, FDD 1314 and optical disk drive 1320 can be connected to the system bus 1306 by an HDD interface 1322, an FDD interface 1324 and an optical drive interface 1326, respectively.
  • the HDD interface 1322 for external drive implementations can include at least one or both of Universal Serial Bus (USB) and IEEE 1394 interface technologies.
  • USB Universal Serial Bus
  • the drives and associated computer-readable media provide volatile and/or nonvolatile storage of data, data structures, computer-executable instructions, and so forth.
  • a number of program modules can be stored in the drives and memory units 1308, 1312, including an operating system 1328, one or more application programs 1330, other program modules 1332, and program data 1334.
  • the one or more application programs 1330, other program modules 1332, and program data 1334 can include, for example, the various applications and/or components of the messaging systems 100 or 400.
  • a user can enter commands and information into the computer 1301 through one or more wire/wireless input devices, for example, a keyboard 1336 and a pointing device, such as a mouse 1338.
  • Other input devices may include microphones, infra-red (IR) remote controls, radio-frequency (RF) remote controls, game pads, stylus pens, card readers, dongles, fingerprint readers, gloves, graphics tablets, joysticks, keyboards, retina readers, touch screens (e.g., capacitive, resistive, etc.), trackballs, trackpads, sensors, styluses, and the like.
  • IR infra-red
  • RF radio-frequency
  • a monitor 1342 or other type of display device is also connected to the system bus 1306 via an interface, such as a video adaptor 1344.
  • the monitor 1342 may be internal or external to the computer 1301.
  • a computer typically includes other peripheral output devices, such as speakers, printers, and so forth.
  • the computer 1301 may operate in a networked environment using logical connections via wire and/or wireless communications to one or more remote computers, such as a remote computer 1344.
  • the remote computer 1344 can be a workstation, a server computer, a router, a personal computer, portable computer, microprocessor-based entertainment appliance, a peer device or other common network node, and typically includes many or all of the elements described relative to the computer 1301, although, for purposes of brevity, only a memory /storage device 1346 is illustrated.
  • the logical connections depicted include wire/wireless connectivity to a local area network (LAN) 1348 and/or larger networks, for example, a wide area network (WAN) 1350.
  • LAN and WAN networking environments are commonplace in offices and companies, and facilitate enterprise-wide computer networks, such as intranets, all of which may connect to a global communications network, for example, the Internet.
  • the computer 1301 When used in a LAN networking environment, the computer 1301 is connected to the LAN 1348 through a wire and/or wireless communication network interface or adaptor 1352.
  • the adaptor 1352 can facilitate wire and/or wireless communications to the LAN 1348, which may also include a wireless access point disposed thereon for communicating with the wireless functionality of the adaptor 1352.
  • the computer 1301 can include a modem 1354, or is connected to a communications server on the WAN 1350, or has other means for establishing communications over the WAN 1350, such as by way of the Internet.
  • the modem 1354 which can be internal or external and a wire and/or wireless device, connects to the system bus 1306 via the input device interface 1340.
  • program modules depicted relative to the computer 1301, or portions thereof can be stored in the remote memory/storage device 1346. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers can be used.
  • the computer 1301 is operable to communicate with wire and wireless devices or entities using the IEEE 802 family of standards, such as wireless devices operatively disposed in wireless communication (e.g., IEEE 802.11 over-the-air modulation techniques).
  • the communication can be a predefined structure as with a conventional network or simply an ad hoc communication between at least two devices.
  • Wi-Fi networks use radio technologies called IEEE 802.1 lx (a, b, g, n, etc.) to provide secure, reliable, fast wireless connectivity.
  • a Wi-Fi network can be used to connect computers to each other, to the Internet, and to wire networks (which use IEEE 802.3-related media and functions).
  • FIG. 14 is a block diagram depicting an exemplary communications architecture 1400 suitable for implementing various examples as previously described.
  • the communications architecture 1400 includes various common communications elements, such as a transmitter, receiver, transceiver, radio, network interface, baseband processor, antenna, amplifiers, filters, power supplies, and so forth.
  • the communications architecture 1400 includes one or more clients 1402 and servers 1404.
  • the clients 1402 and the servers 1404 are operatively connected to one or more respective client data stores 1406 and server data stores 1408 that can be employed to store information local to the respective clients 1402 and servers 1404, such as cookies and/or associated contextual information.
  • the clients 1402 and the servers 1404 may communicate information between each other using a communication framework 1410.
  • the communications framework 1410 may implement any well-known communications techniques and protocols.
  • the communications framework 1410 may be implemented as a packet-switched network (e.g., public networks such as the Internet, private networks such as an enterprise intranet, and so forth), a circuit- switched network (e.g., the public switched telephone network), or a combination of a packet- switched network and a circuit-switched network (with suitable gateways and translators).
  • the communications framework 1410 may implement various network interfaces arranged to accept, communicate, and connect to a communications network.
  • a network interface may be regarded as a specialized form of an input output interface.
  • Network interfaces may employ connection protocols including without limitation direct connect, Ethernet (e.g., thick, thin, twisted pair 10/100/1000 Base T, and the like), token ring, wireless network interfaces, cellular network interfaces, IEEE 802.11a-x network interfaces, IEEE 802.16 network interfaces, IEEE 802.20 network interfaces, and the like. Further, multiple network interfaces may be used to engage with various communications network types. For example, multiple network interfaces may be employed to allow for the communication over broadcast, multicast, and unicast networks. Should processing requirements dictate a greater amount speed and capacity, distributed network controller architectures may similarly be employed to pool, load balance, and otherwise increase the communicative bandwidth required by clients 1402 and the servers 1404.
  • connection protocols including without limitation direct connect, Ethernet (e.g., thick, thin, twisted pair 10/100/1000 Base T, and the like), token ring, wireless network interfaces, cellular network interfaces, IEEE 802.11a-x network interfaces, IEEE 802.16 network interfaces, IEEE 802.20 network interfaces, and the
  • a communications network may be any one and the combination of wired and/or wireless networks including without limitation a direct interconnection, a secured custom connection, a private network (e.g., an enterprise intranet), a public network (e.g., the Internet), a Personal Area Network (PAN), a Local Area Network (LAN), a Metropolitan Area Network (MAN), an Operating Missions as Nodes on the Internet (OMNI), a Wide Area Network (WAN), a wireless network, a cellular network, and other communications networks.
  • a private network e.g., an enterprise intranet
  • a public network e.g., the Internet
  • PAN Personal Area Network
  • LAN Local Area Network
  • MAN Metropolitan Area Network
  • OMNI Operating Missions as Nodes on the Internet
  • WAN Wide Area Network
  • wireless network a cellular network, and other communications networks.
  • FIG. 15 illustrates an example of a device 1500 for use in a multicarrier OFDM system, such as the messaging system 100.
  • the device 1500 may implement, for example, software components 1502 as described with reference to the messaging logic or any related logic for sending or receiving digital content that has been configured with one or more sensor responsive elements.
  • the device 1500 may also implement a logic circuit 1504.
  • the logic circuit 1504 may include physical circuits to perform operations described for the messaging system 100.
  • device 1500 may include a radio interface 1506, baseband circuitry 1508, and a computing platform 1510.
  • the device 1500 may implement some or all of the structure and/or operations for the messaging system 100 and/or logic circuit 1504 in a single computing entity, such as entirely within a single device.
  • the device 1500 may distribute portions of the structure and/or operations for the messaging system 100 and/or logic circuit 1504 across multiple computing entities using a distributed system architecture, such as a client-server architecture, a 3-tier architecture, an N-tier architecture, a tightly-coupled or clustered architecture, a peer- to-peer architecture, a master-slave architecture, a shared database architecture, and other types of distributed systems.
  • a distributed system architecture such as a client-server architecture, a 3-tier architecture, an N-tier architecture, a tightly-coupled or clustered architecture, a peer- to-peer architecture, a master-slave architecture, a shared database architecture, and other types of distributed systems.
  • the radio interface 1506-a may include a component or combination of components adapted for transmitting and/or receiving single carrier or multi-carrier modulated signals (e.g., including complementary code keying (CCK) and/or orthogonal frequency division multiplexing (OFDM) symbols) although the examples are not limited to any specific over-the-air interface or modulation scheme.
  • the radio interface 1506-a may include, for example, a receiver 1512, a transmitter 1514 and/or a frequency synthesizer 1516.
  • the radio interface 1506-a may include bias controls, a crystal oscillator and/or one or more antennas 1518.
  • the radio interface 1506-a may use external voltage-controlled oscillators (VCOs), surface acoustic wave filters, intermediate frequency (IF) filters and/or RF filters, as desired. Due to the variety of potential RF interface designs an expansive description thereof is omitted.
  • VCOs voltage-controlled oscillators
  • IF intermediate frequency
  • the baseband circuitry 1508-a may communicate with the radio interface 1506-a to process receive and/or transmit signals and may include, for example, an analog-to-digital converter 1520 for down converting received signals, and a digital -to-analog converter 1522 for up-converting signals for transmission. Further, the baseband circuitry 1508-a may include a baseband or physical layer (PHY) processing circuit 1524 for PHY link layer processing of respective receive/transmit signals. The baseband circuitry 1508-a may include, for example, a processing circuit 1526-a for medium access control (MAC)/data link layer processing. The baseband circuitry 1508-a may include a memory controller 1528 for communicating with the processing circuit 1526-a and/or a computing platform 1510-a, for example, via one or more interfaces 1530.
  • PHY physical layer
  • the baseband circuitry 1508-a may include a memory controller 1528 for communicating with the processing circuit 1526-a and/or a computing platform 1510-a, for example, via one
  • the PHY processing circuit 1524 may include a frame construction and/or detection module, in combination with additional circuitry such as a buffer memory, to construct and/or deconstruct communication frames, such as radio frames.
  • the MAC processing circuit 1526-a may share processing for certain of these functions or perform these processes independent of the PHY processing circuit 1524.
  • MAC and PHY processing may be integrated into a single circuit.
  • the computing platform 1510-a may provide computing functionality for the device 1500. As shown, the computing platform 1510-a may include a processing component 1532. In addition to, or alternatively of, the baseband circuitry 1508, the device 1500 may execute processing operations or logic for the messaging systems 100 or 400 and logic circuit 1504 using the processing component 1532.
  • the processing component 1532 (and/or the PHY 112- 14 and/or MAC 112-16) may comprise various hardware elements, software elements, or a combination of both.
  • Examples of hardware elements may include devices, logic devices, components, processors, microprocessors, circuits, processor circuits, circuit elements (e.g., transistors, resistors, capacitors, inductors, and so forth), integrated circuits, application specific integrated circuits (ASIC), programmable logic devices (PLD), digital signal processors (DSP), field programmable gate array (FPGA), memory units, logic gates, registers, semiconductor device, chips, microchips, chip sets, and so forth.
  • ASIC application specific integrated circuits
  • PLD programmable logic devices
  • DSP digital signal processors
  • FPGA field programmable gate array
  • Examples of software elements may include software components, programs, applications, computer programs, application programs, system programs, software development programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, procedures, software interfaces, application program interfaces (API), instruction sets, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. Determining whether an example is implemented using hardware elements and/or software elements may vary in accordance with any number of factors, such as desired computational rate, power levels, heat tolerances, processing cycle budget, input data rates, output data rates, memory resources, data bus speeds and other design or performance constraints, as desired for a given implementation.
  • the computing platform 1510-a may further include other platform components 1534.
  • Other platform components 1534 include common computing elements, such as one or more processors, multi-core processors, co-processors, memory units, chipsets, controllers, peripherals, interfaces, oscillators, timing devices, video cards, audio cards, multimedia input/output (I/O) components (e.g., digital displays), power supplies, and so forth.
  • processors multi-core processors, co-processors, memory units, chipsets, controllers, peripherals, interfaces, oscillators, timing devices, video cards, audio cards, multimedia input/output (I/O) components (e.g., digital displays), power supplies, and so forth.
  • I/O multimedia input/output
  • Examples of memory units may include without limitation various types of computer readable and machine readable storage media in the form of one or more higher speed memory units, such as read-only memory (ROM), random-access memory (RAM), dynamic RAM (DRAM), Double-Data-Rate DRAM (DDRAM), synchronous DRAM (SDRAM), static RAM (SRAM), programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, polymer memory such as ferroelectric polymer memory, ovonic memory, phase change or ferroelectric memory, silicon-oxide- nitride-oxide-silicon (SONOS) memory, magnetic or optical cards, an array of devices such as Redundant Array of Independent Disks (RAID) drives, solid state memory devices (e.g., USB memory, solid state drives (SSD) and any other type of storage media suitable for storing information.
  • ROM read-only memory
  • RAM random-access memory
  • DRAM dynamic RAM
  • DDRAM
  • the device 1500 may be, for example, an ultra-mobile device, a mobile device, a fixed device, a machine-to-machine (M2M) device, a personal digital assistant (PDA), a mobile computing device, a smart phone, a telephone, a digital telephone, a cellular telephone, user equipment, eBook readers, a handset, a one-way pager, a two-way pager, a messaging device, a computer, a personal computer (PC), a desktop computer, a laptop computer, a notebook computer, a netbook computer, a handheld computer, a tablet computer, a server, a server array or server farm, a web server, a network server, an Internet server, a work station, a mini computer, a main frame computer, a supercomputer, a network appliance, a web appliance, a distributed computing system, multiprocessor systems, processor-based systems, consumer electronics, programmable consumer electronics, game devices, television, digital television, set top box, wireless access point, base station, node
  • the device 1500 may be included or omitted in various examples of the device 1500, as suitably desired.
  • the device 1500 may be configured to be compatible with protocols and frequencies associated one or more of the 3GPP LTE Specifications and/or IEEE 802.16 Standards for WMANs, and/or other broadband wireless networks, cited herein.
  • Examples of device 1500 may be implemented using single input single output (SISO) architectures. However, certain implementations may include multiple antennas (e.g., antennas 1518) for transmission and/or reception using adaptive antenna techniques for beamforming or spatial division multiple access (SDMA) and/or using MIMO communication techniques.
  • the components and features of the device 1500 may be implemented using any combination of discrete circuitry, application specific integrated circuits (ASICs), logic gates and/or single chip architectures. Further, the features of the device 1500 may be implemented using microcontrollers, programmable logic arrays and/or microprocessors or any combination of the foregoing where suitably appropriate.
  • At least one computer-readable storage medium 1536 may include instructions that, when executed, cause a system to perform any of the computer-implemented methods described herein.
  • Terminology may be described using the expression “one example” or “an example” along with their derivatives. These terms mean that a particular feature, structure, or characteristic described in connection with the example is included in at least one example.
  • the appearances of the phrase “in one example” in various places in the specification are not necessarily all referring to the same example.
  • the features described above are recognized to be usable together in any combination. Thus, any features discussed separately may be employed in combination with each other unless it is noted that the features are incompatible with each other.
  • a procedure is here, and generally, conceived to be a self-consistent sequence of operations leading to a desired result. These operations are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical, magnetic, or optical signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It proves convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. It should be noted, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to those quantities.
  • Coupled and “connected” along with their derivatives. These terms are not necessarily intended as synonyms for each other.
  • the terms “connected” and/or “coupled” may be used to indicate that two or more elements are in direct physical or electrical contact with each other.
  • the term “coupled,” however, may also mean that two or more elements are not in direct contact with each other, but still co-operate or interact with each other.
  • Various examples also relate to apparatus or systems for performing these operations. This apparatus may be specially constructed for the required purpose, or it may comprise a general-purpose computer as selectively activated or reconfigured by a computer program stored in the computer.
  • the procedures presented herein are not inherently related to a particular computer or other apparatus.
  • Various general-purpose machines may be used with programs written in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these machines will appear from the description given.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Power Engineering (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Human Computer Interaction (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

Selon des exemples de modes de réalisation, l'invention concerne des techniques de partage d'état d'application chiffré de bout en bout. Dans un mode de réalisation, un client de messagerie peut recevoir, d'un serveur de messagerie, un premier paquet de données pour un compte. Le client de messagerie peut déchiffrer une partie chiffrée du premier paquet de données pour produire une première file d'attente de correctifs pour le compte. Le client de messagerie peut calculer une valeur de hachage pour la première file d'attente de correctifs et déterminer que la valeur de hachage calculée correspond à une valeur de hachage attendue. Le client de messagerie peut mettre à jour une base de données de messagerie pour le compte sur le premier dispositif client sur la base d'un ou de plusieurs changements pour le compte spécifiés dans la première file d'attente de correctifs.
PCT/US2022/035033 2021-06-25 2022-06-25 Partage d'état d'application chiffré de bout en bout WO2022272155A1 (fr)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US202163215216P 2021-06-25 2021-06-25
US202163215334P 2021-06-25 2021-06-25
US63/215,216 2021-06-25
US63/215,334 2021-06-25
US202217848064A 2022-06-23 2022-06-23
US17/848,064 2022-06-23

Publications (1)

Publication Number Publication Date
WO2022272155A1 true WO2022272155A1 (fr) 2022-12-29

Family

ID=82694112

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2022/035033 WO2022272155A1 (fr) 2021-06-25 2022-06-25 Partage d'état d'application chiffré de bout en bout

Country Status (1)

Country Link
WO (1) WO2022272155A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150186668A1 (en) * 2013-12-30 2015-07-02 Moka5, Inc. Protecting data in insecure cloud storage
EP3364330A1 (fr) * 2017-02-17 2018-08-22 WhatsApp, Inc. Procédés et systèmes de traitement de messages de contenu éphémères
US20180241871A1 (en) * 2017-02-17 2018-08-23 Whatsapp Inc. Methods and systems for displaying an ephemeral content message
US11010485B1 (en) * 2017-03-02 2021-05-18 Apple Inc. Cloud messaging system

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150186668A1 (en) * 2013-12-30 2015-07-02 Moka5, Inc. Protecting data in insecure cloud storage
EP3364330A1 (fr) * 2017-02-17 2018-08-22 WhatsApp, Inc. Procédés et systèmes de traitement de messages de contenu éphémères
US20180241871A1 (en) * 2017-02-17 2018-08-23 Whatsapp Inc. Methods and systems for displaying an ephemeral content message
US11010485B1 (en) * 2017-03-02 2021-05-18 Apple Inc. Cloud messaging system

Similar Documents

Publication Publication Date Title
US11882231B1 (en) Methods and systems for processing an ephemeral content message
US11973750B2 (en) Federated identity management with decentralized computing platforms
US10461939B2 (en) Secure device registration for multi-factor authentication
US10542013B2 (en) User behavior profile in a blockchain
US9647836B2 (en) Secure storage for shared documents
US11658952B1 (en) Methods and systems for transmitting anonymized information
US11700247B2 (en) Securing a group-based communication system via identity verification
US9871813B2 (en) Method of and system for processing an unauthorized user access to a resource
US10127317B2 (en) Private cloud API
US9900318B2 (en) Method of and system for processing an unauthorized user access to a resource
EP3364330B1 (fr) Procédés et systèmes de traitement de messages de contenu éphémères
US11616742B2 (en) Methods and systems for end-to-end encrypted message history exchange
US9646149B2 (en) Accelerated application authentication and content delivery
EP4030687A1 (fr) Authentification d'informations anonymes
US20220255923A1 (en) Collaboration application integration for user-identity verification
WO2022272155A1 (fr) Partage d'état d'application chiffré de bout en bout
US11750574B1 (en) End-to-end encrypted interactive messaging using message templates
US11526588B2 (en) Systems and methods for digital content anti-counterfeiting

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22747197

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 22747197

Country of ref document: EP

Kind code of ref document: A1