Scalable real-time location sharing framework

Abstract

This disclosure relates to systems and methods for performing operations including: storing a front-end (FE) instance and multiple real-time graph (RTG) instances on a distributed storage system, each of the multiple RTG instances including multiple device objects, the FE instance being configured to communicate with a client device associated with a first user; establishing a bidirectional streaming remote procedure call (RPC) connection between the FE instance and the multiple RTG instances; receiving a status update from the client device by the FE instance; determining by the FE instance that a first device object corresponding to the client device is stored on a first RTG instance among the multiple RTG instances; and sending a first message including a status update from the FE instance to the first RTG instance to update the first device object.

Description

[0001] Priority requirements

[0002] This application claims the benefit of priority to U.S. Patent Application Serial No. 16 / 946,284, filed June 15, 2020, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This disclosure generally involves real-time location sharing. Background Technology

[0004] The popularity of online interaction between users continues to grow. Users have many ways to interact with other users online. They can communicate with their friends using messaging apps, play multiplayer video games online with other users, or perform other actions using various other apps. Users also increasingly want to see where their friends are currently located. Attached Figure Description

[0005] In accompanying drawings that are not necessarily drawn to scale, the same reference numerals may describe similar parts in different views. To facilitate identification of any particular element or action being discussed, one or more of the highest-order digits of the reference numerals indicate the drawing number in which the element was first introduced. Some examples are shown in the accompanying drawings by way of example, not limitation:

[0006] Figure 1 It is a diagrammatic representation of a networked environment in which the content of this disclosure can be deployed, based on some examples.

[0007] Figure 2 It is a graphical representation of a messaging system with both client-side and server-side functionalities, based on some examples.

[0008] Figure 3 It is a graphical representation of the data structures maintained in the database based on some examples.

[0009] Figure 4 It is a graphical representation based on some example messages.

[0010] Figure 5 It is a graphical representation of a distributed real-time state update server based on some examples.

[0011] Figure 6 This is another graphical representation of a distributed real-time state update server based on some examples.

[0012] Figure 7 It is a graphical representation based on some example RTG instances.

[0013] Figures 8A to 8CIt is a graphical representation of message exchange between device objects in a distributed real-time state update server, based on some examples.

[0014] Figure 9 It is a graphical representation of sending updates based on different versions of the friend list, using some examples.

[0015] Figures 10A to 10D This is a flowchart illustrating example operations of a distributed real-time state update server based on an example.

[0016] Figure 11 It is a graphical representation of a machine in the form of a computer system, based on some examples, in which a set of instructions can be executed to cause the machine to perform any or more of the methods discussed herein.

[0017] Figure 12 It is a block diagram showing a software architecture in which examples can be implemented. Detailed Implementation

[0018] The following description includes illustrative examples of systems, methods, techniques, instruction sequences, and computer program products that implement the contents of this disclosure. In this description, numerous specific details are set forth for illustrative purposes to provide an understanding of the various examples. However, it will be apparent to those skilled in the art that the examples can be practiced without these specific details. Generally, well-known examples of instructions, protocols, structures, and techniques need not be shown in detail.

[0019] Typically, users access messaging apps not only to communicate with their friends, but also to determine their friends' current locations. Some messaging apps display current locations as part of the chat interface where users exchange messages, and may also display locations on interactive maps. For example, an avatar representing a user could be located at the corresponding location of each user on a map. Obtaining friends' current locations consumes significant computing and network resources. Specifically, each friend's location could be pushed to a specific user's device that needs to exchange a large number of messages over the network. This can degrade network performance and unnecessarily consume network bandwidth.

[0020] In some systems, a specific user device can poll for the location of its friends. For example, a user device can send a request to a server with the identifiers of one or more friends to receive the current location of one or more friends. However, even in these systems, network bandwidth and system resources are wasted. Specifically, sometimes the location of a friend requested by a given user device may not change very frequently, and polling for the location of such a friend results in the same location being sent back to the given user device, wasting system resources. Furthermore, the latency introduced due to polling or pushing friends' locations to various users reduces the accuracy of the locations being transmitted. That is, for example, if a given friend is actively moving around, the location transmitted to the requesting device may not reflect the friend's actual current location. This makes such a system less attractive and degrades the overall user experience.

[0021] The disclosed examples seek to improve the efficiency and speed of providing real-time status updates, such as location information, to client devices using a distributed storage system. The distributed storage system uses real-time graph instances to store device objects representing the status information (e.g., location information) of individual users. These device objects communicate with each other through front-end instances. When a given user's location changes, that location is updated in the user's device object. This location is then intelligently and automatically propagated to the device objects of the user's friends. When a given friend requests the user's current location, such as when the given friend opens an interactive map of an avatar, the given friend's device communicates with the front-end instance to retrieve the user's device's location stored in the given friend's device object. This reduces overall network traffic and increases the rate at which location updates are delivered and exchanged. This minimizes the lag between when a location is requested and when it is provided to a given user, providing the user with a real-time location-sharing experience.

[0022] Specifically, according to the disclosed example, a Front End (FE) instance and multiple Real-Time Graph (RTG) instances are stored on a distributed storage system. In some cases, multiple FE instances and multiple RTG instances can be stored, with the number of FE instances increasing / decreasing proportionally based on the load and number of client devices, and the RTG instances having a fixed size. Each of the multiple RTG instances includes multiple device objects, and the FE instance is configured to communicate with the client device associated with the first user. A bidirectional streaming Remote Procedure Call (RPC) connection is established between the FE instance and the multiple RTG instances. The FE instance receives status updates from the client devices and determines that the first device object corresponding to the client device is stored on the first RTG instance of the multiple RTG instances. The FE instance sends a first message including the status update to the first RTG instance to update the first device object. The first device object identifies the user's friend and provides status updates to the device objects of the user's friends. When a given friend of the user eventually requests a status update such as the user's location, this information is readily available in the given friend's device object and delivered to the given friend's device in real time.

[0023] In this way, based on the disclosed examples, the device resources (e.g., processor cycles, memory, and power usage) required to complete the task are reduced.

[0024] Networked computing environment

[0025] Figure 1 This is a block diagram illustrating an example messaging system 100 for exchanging data (e.g., messages and associated content) over a network. The messaging system 100 includes multiple instances of client devices 102, each hosting multiple applications including messaging clients 104. Each messaging client 104 is communicatively coupled to a messaging server system 108 and other instances of the messaging client 104 via a network 106 (e.g., the Internet). The messaging server system 108 may include a distributed real-time status update server 107, in which case each messaging client 104 receives status updates (e.g., location updates, location preference updates, online status updates, etc.) from the distributed real-time status update server 107 via the messaging server system 108. In some implementations, all or part of the distributed real-time status update server 107 is implemented external to the messaging server system 108. In these cases, each messaging client 104 receives status updates (e.g., location updates, location preference updates, online status updates, etc.) directly from the distributed real-time status update server 107 via the network 106.

[0026] Message transceiver client 104 can communicate and exchange data with other message transceiver clients 104 and message transceiver server system 108 via network 106. The data exchanged between message transceiver clients 104 and between message transceiver client 104 and message transceiver server system 108 includes functions (e.g., commands to activate functions) and payload data (e.g., text, audio, video, or other multimedia data).

[0027] The message transceiver server system 108 provides server-side functionality to a specific message transceiver client 104 via network 106. While some functions of the message transceiver system 100 are described herein as being performed by either the message transceiver client 104 or the message transceiver server system 108, the location of certain functions within the message transceiver client 104 or the message transceiver server system 108 can be a design choice. For example, it may be technically preferred that certain technologies and functions are initially deployed within the message transceiver server system 108, but that technology and functions are subsequently migrated to the message transceiver client 104 of the client device 102, which has sufficient processing capabilities.

[0028] The messaging server system 108 supports various services and operations provided to the messaging client 104. Such operations include sending data to and receiving data from the messaging client 104, and processing data generated by the messaging client 104. As an example, this data may include message content, client device information, geolocation information, media enhancements and coverage, message content persistence conditions, social network information, and live event information. Data exchange within the messaging system 100 is activated and controlled through functions available via the user interface (UI) of the messaging client 104.

[0029] Specifically, turning to message transceiver server system 108, application programming interface (API) server 110 is coupled to application server 112 and provides a programming interface to application server 112. Application server 112 is communicatively coupled to database server 118, which provides access to database 120, which stores data associated with messages processed by application server 112. Similarly, web server 124 is coupled to application server 112 and provides a web-based interface to application server 112. To this end, web server 124 processes incoming network requests via Hypertext Transfer Protocol (HTTP) and several other related protocols.

[0030] Application Programming Interface (API) server 110 receives and sends message data (e.g., commands and message payloads) between client device 102 and application server 112. Specifically, API server 110 provides a set of interfaces (e.g., routines and protocols) that message sending and receiving client 104 can invoke or query to activate the functionality of application server 112. Application Programming Interface (API) server 110 exposes various functionalities supported by application server 112, including: account registration; login functionality; sending messages from one messaging client 104 to another messaging client 104 via application server 112; sending media files (e.g., images or videos) from messaging client 104 to messaging server 114 and providing possible access for another messaging client 104; setting up media data collections (e.g., stories); retrieving a user's friend list for client device 102; retrieving such collections; retrieving messages and content; adding and deleting entities (e.g., friends) in an entity graph (e.g., a social graph); locating friends in a social graph; and opening application events (e.g., related to messaging client 104).

[0031] Application server 112 hosts several server applications and subsystems, including, for example, messaging server 114, image processing server 116, and social networking server 122. Messaging server 114 implements several messaging technologies and functions, particularly those related to the aggregation and other processing of content (e.g., text and multimedia content) included in messages received from multiple instances of messaging client 104. As will be described in further detail, text and media content from multiple sources can be aggregated into collections of content (e.g., referred to as stories or galleries). These collections are then made available to messaging client 104. Given the hardware requirements for such processing, additional processor- and memory-intensive data processing can also be performed by messaging server 114 on the server side.

[0032] Application server 112 also includes image processing server 116, which is dedicated to performing various image processing operations, typically relative to the images or videos within the payload of messages sent from or received at message transceiver server 114.

[0033] Social networking server 122 supports various social networking functions and services, and makes these functions and services available to messaging server 114. To this end, social networking server 122 maintains and accesses entity graph 306 (such as...) within database 120. Figure 3(As shown). Examples of functions and services supported by the social network server 122 include identifying other users of the messaging system 100 who have a relationship with or “follow” a particular user, as well as identifying the interests and other entities of a particular user.

[0034] The distributed real-time state update server 107 stores instances or nodes of a real-time graph (RTG). These nodes maintain various information about different users of the message transceiver server 114. Client device 102 receives updates (e.g., location updates) from friends in real time from the distributed real-time state update server 107. The distributed real-time state update server 107 includes one or more front-end (FE) instances and one or more real-time graph (RTG) instances. When a given client device 102 initially connects to the distributed real-time state update server 107, or when a message is directed to a user of the given client device 102, an FE instance is created and stored on the distributed real-time state update server 107 for the client device 102. In some cases, an existing FE instance is accessed, in which case it is not necessary to create an FE instance when the client device 102 connects. This occurs if the client device 102 has previously established a streaming connection to an FE instance or another FE instance. FE instances are created on demand based on the load on server 107. This may include storing the user of the client device or a unique device identifier of the client device in the FE instance. The FE instance establishes a real-time link to a given client device 102 for exchanging information with the client device 102. The FE instance also establishes a bidirectional streaming real-time gRPC (Remote Procedure Call) connection with each of the multiple RTG instances.

[0035] In some examples, the FE instance receives updates (e.g., location updates) from client device 102. In response, the FE instance identifies the device object corresponding to client device 102. Specifically, each RTG instance stores one or more device objects corresponding to each client device 102 (e.g., physical device). The FE instance accesses routing information that identifies which of the multiple RTG instances stores the device object of client device 102. The FE instance then sends state updates to the RTG instance storing the device object of client device 102 via a previously established gRPC connection.

[0036] The RTG instance receives status updates (e.g., location updates or updates to preference information such as location sharing preferences) and identifies device objects to be updated for client device 102. The RTG instance uses the received updates to update the corresponding status updates stored in the device objects. The device objects process the updates and identify multiple friends associated with the user of client device 102 on messaging system 100. The device objects generate multiple messages directed to the device objects of the friends associated with the user, for example, based on the current state of the respective device objects (e.g., the device object indicating whether the friend is active or inactive). The messages include updates to the status (e.g., location updates). In some cases, the device object first determines whether the status update meets certain criteria. For example, the device object determines whether the location included in the update differs from a previously stored location by more than a threshold amount. As another example, the device object determines whether the location included in the update was last updated before exceeding a threshold amount of time (e.g., the timestamp of the previously stored location exceeds the current timestamp of the location in the update by more than a specified amount). As another example, a device object determines whether to share the location included in an update with the user based on the user's current state (e.g., whether the user is currently active or inactive, currently reading messages or accessing an interactive map displaying the real-time locations of friends, the user's last connection time, etc.). If the state update meets a criterion or guideline, the device object sends a message to the device objects of the friends. In some cases, the criterion might be met for the first group of friends but not for the second group. In this case, the device object sends a state update to the device objects of the first group of friends and delays or completely blocks sending updates to the device objects of the second group of friends.

[0037] In some examples, a given friend's device object resides on or is stored on a different RTG instance (e.g., a second RTG instance) than the one storing the user's device object. In this case, the user's device object will be directed to the friend's device object with an updated message sent to a randomly or pseudo-randomly selected FE instance. In some cases, FE instances are selected in a round-robin fashion, where FE instances are stored in a list, and the next FE instance adjacent to the FE instance to which the message was previously sent is selected. Once the last FE instance in the list is reached, the first FE instance in the list is selected to send the message to the device object. The FE instance receives the message and determines which of the multiple RTG instances stores the given friend's device object. The FE instance uses routing information stored in the FE instance to identify the second RTG instance storing the device object. The FE instance then sends the message to the RTG instance storing the device object. The RTG instance receives the message and updates the user's state stored in the friend's device object.

[0038] After a threshold time interval following a disconnection of client device 102 from server 107, the device object stored on the RTG instance is automatically deleted from the distributed real-time state update server 107. Once the threshold time interval is reached, the information stored in the device object is moved to a different persistent storage device, and the real-time connection with client device 102 and the gRPC connection to the RTG instance are terminated. In this way, whenever a given friend has an update to their state, that update is propagated to the device objects of the users associated with that friend. When such a user eventually connects to the system (e.g., opens messaging client 104), the state information stored in such a user's device object becomes seamlessly and quickly available to the user. This avoids the need for users to poll or wait to receive state updates directly from their friends, since such information is updated in the user's device object when the user is offline. In some cases, FE instances are created and deleted based on the load on server 107. A gRPC proxy object is generated and stored on the FE instance to communicate with client device 102 via a gRPC connection. Such a proxy object provides information such as status updates or news from client device 102 to the corresponding device object stored on the RTG instance. Once the connection between the gRPC proxy object and client device 102 is terminated, the gRPC proxy object is deleted, and the FE instance remains stored and can be used to handle further connections.

[0039] System Architecture

[0040] Figure 2 This is a block diagram illustrating further details of a messaging system 100 according to some examples. Specifically, the messaging system 100 is shown as including a messaging client 104 and an application server 112. The messaging system 100 includes several subsystems supported on the client side by the messaging client 104 and on the server side by the application server 112. These subsystems include, for example, a short-run timer system 202, a collection management system 204, an enhancement system 206, a map system 208, and a game system 210.

[0041] The short-lived timer system 202 is responsible for enabling temporary or time-limited access to content by the message sending client 104 and the message sending server 114. The short-lived timer system 202 includes several timers that selectively enable access (e.g., for rendering and displaying) of messages and associated content via the message sending client 104 based on the duration and display parameters associated with the message or message set (e.g., a story). Further details regarding the operation of the short-lived timer system 202 are provided below.

[0042] The collection management system 204 is responsible for managing groups or collections of media (e.g., collections of text, images, video, and audio data). Collections of content (e.g., messages, including images, videos, text, and audio) can be organized into "event libraries" or "event stories." Such collections can be made available for a specified time period (e.g., the duration of an event related to the content). For example, content related to a concert can be made available as a "story" for the duration of a concert. The collection management system 204 can also be responsible for publishing icons that notify the user interface of the messaging client 104 of the existence of a specific collection.

[0043] Furthermore, the collection management system 204 includes a curation interface 212 that enables collection managers to manage and curate specific content collections. For example, the curation interface 212 allows event organizers to curate content collections related to a specific event (e.g., removing inappropriate content or redundant messages). Additionally, the collection management system 204 employs machine vision (or image recognition technology) and content rules to automatically curate content collections. In some examples, users may be compensated for including user-generated content in the collection. In such cases, the collection management system 204 operates to automatically pay such users for using their content.

[0044] Enhancement system 206 provides various functionalities that enable users to enhance (e.g., annotate or otherwise modify or edit) media content associated with a message. For example, enhancement system 206 provides functionalities related to generating and publishing media overlays for messages processed by messaging system 100. Enhancement system 206 can operable to provide media overlays or enhancements (e.g., image filters) to messaging client 104 based on the geographic location of client device 102. In another example, enhancement system 206 can operable to supply media overlays to messaging client 104 based on other information such as the social network information of the user of client device 102. Media overlays can include audio and visual content as well as visual effects. Examples of audio and visual content include pictures, text, logos, animations, and sound effects. Examples of visual effects include color overlays. Audio and visual content or visual effects can be applied to media content items (e.g., photographs) at client device 102. For example, media overlays can include text or images that can be overlaid on a photograph taken by client device 102. In another example, media overlays include location identifier overlays (e.g., Venice Beach), names of live events, or merchant name overlays (e.g., Beach Cafe). In yet another example, enhancement system 206 uses the geographic location of client device 102 to identify media overlays that include the name of a merchant at the geographic location of client device 102. Media overlays may include other tags associated with the merchant. Media overlays may be stored in database 120 and accessed through database server 118.

[0045] In some examples, Enhancement System 206 provides a user-based publishing platform that allows users to select geographic locations on a map and upload content associated with those locations. Users can also specify which media coverage should be provided to other users. Enhancement System 206 generates media coverage that includes the uploaded content and associates it with the selected geographic locations.

[0046] In other examples, Enhancement System 206 provides a merchant-based publishing platform that enables merchants to select specific media coverage associated with geographic locations via a bidding process. For example, Enhancement System 206 associates the media coverage of the highest-bidding merchant with a corresponding geographic location for a predefined amount of time.

[0047] Map system 208 provides various geolocation functions and supports the presentation of map-based media content and messages by messaging client 104. For example, map system 208 enables the display (e.g., stored in configuration data 308) of user icons or avatars on a map to indicate the current or past locations of a user's "friends" within the context of the map, as well as media content generated by these friends (e.g., a collection of messages including photos and videos). For example, a message posted by a user from a specific geolocation to messaging system 100 can be displayed to a specific user's "friends" at that specific location within the context of the map on the map interface of messaging client 104. A user can also share his or her location and status information with other users of messaging system 100 (e.g., using appropriate status avatars) via messaging client 104, where the location and status information is similarly displayed to the selected user within the context of the map interface of messaging client 104.

[0048] The gaming system 210 provides various gaming functions within the context of the messaging client 104. The messaging client 104 provides a game interface that offers a list of available games (e.g., web-based games or web-based applications), which can be initiated by a user within the context of the messaging client 104 and played with other users of the messaging system 100. The messaging system 100 also enables specific users to invite other users to play a specific game by sending invitations from the messaging client 104 to such other users. The messaging client 104 also supports both voice messaging and text messaging (e.g., chat) within the context of playing the game, provides game leaderboards, and also supports providing in-game rewards (e.g., coins and items).

[0049] Data Architecture

[0050] Figure 3 This is a schematic diagram illustrating a data structure 300 that can be stored in a database 120 of a message transceiver server system 108, according to certain examples. Although the contents of the database 120 are shown as including several tables, it should be understood that the data can be stored in other types of data structures (e.g., as an object-oriented database).

[0051] Database 120 includes message data stored in message table 302. For any given message, this message data includes at least message sender data, message receiver (or recipient) data, and a payload. See below for reference. Figure 4 Further details are provided regarding information that can be included in the message and in the message data stored in message table 302.

[0052] Entity table 304 stores entity data and (for example, reference) links to entity diagram 306 and configuration file data 308. Entities for which records are maintained within entity table 304 may include individuals, company entities, organizations, objects, locations, events, etc. Regardless of entity type, any entity whose data is stored in message transceiver server system 108 can be an identifiable entity. Each entity is provided with a unique identifier and an entity type identifier (not shown).

[0053] Entity graph 306 stores information about the relationships and associations between entities. As an example only, such relationships can be social relationships based on interests or activities, or professional relationships (e.g., working in a common company or organization).

[0054] Profile data 308 stores various types of profile data about a specific entity. Based on privacy settings specified by the specific entity, profile data 308 can be selectively used and presented to other users of messaging system 100. In the case of an individual, profile data 308 includes, for example, a username, phone number, address, settings (e.g., notification and privacy settings), and an avatar representation (or a set of such avatar representations) selected by the user. A specific user can then selectively include one or more of these avatar representations in the content of messages transmitted via messaging system 100 and in a map interface displayed to other users by messaging client 104. The set of avatar representations may include “state avatars,” which present a graphical representation of a user’s chosen state or activity at a specific time.

[0055] In the case that the entity is a group, in addition to the group name, members and various settings of the associated group (e.g., notifications), the group’s profile data 308 may similarly include one or more avatars associated with the group.

[0056] Database 120 also stores enhancement data, such as overlays or filters, in enhancement table 310. The enhancement data is associated with and applied to videos (video data is stored in video table 314) and images (image data is stored in image table 316).

[0057] In one example, a filter is an overlay displayed as an image or video during presentation to the receiving user. Filters can be of various types, including filters selected by the user from a set of filters presented to the sending user by the messaging client 104 when the sending user is composing a message. Other types of filters include geolocation filters (also known as geographic filters), which can be presented to the sending user based on geographic location. For example, a geolocation filter specific to a nearby or particular location can be presented by the messaging client 104 within the user interface based on geographic location information determined by the Global Positioning System (GPS) unit of the client device 102.

[0058] Another type of filter is a data filter, which can be selectively presented to the sending user by the messaging client 104 based on other inputs or information collected by the client device 102 during the message creation process. Examples of data filters include the current temperature at a specific location, the current speed of the sending user, the battery life of the client device 102, or the current time.

[0059] Other augmented data that can be stored in image table 316 includes augmented reality content items (e.g., corresponding to an applied lens or augmented reality experience). Augmented reality content items can be real-time special effects and sounds that can be added to images or videos.

[0060] As described above, augmented data includes augmented reality content items, overlays, image transformations, AR images, and similar terms referring to modifications that can be applied to image data (e.g., video or images). This includes real-time modifications, which modify images as they are captured using the device sensors (e.g., one or more cameras) of client device 102 and then display the modified images on the screen of client device 102. This also includes modifications to stored content, such as modifications to video clips in a library that can be modified. For example, in client device 102, which has access to multiple augmented reality content items, a user can use a single video clip with multiple augmented reality content items to see how different augmented reality content items will modify the stored clip. For example, by selecting different augmented reality content items for the content, multiple augmented reality content items with different pseudo-random motion models can be applied to the same content. Similarly, real-time video capture can be used with the illustrated modifications to show how the video image currently captured by the sensors of client device 102 will modify the captured data. Such data can be simply displayed on the screen without being stored in memory, or content captured by the device's sensors can be recorded and stored in memory with or without modification (or both). In some systems, preview functionality can show how different augmented reality content items will be displayed simultaneously in different windows of the display. For example, this allows viewing multiple windows with different pseudo-random animations on the display at the same time.

[0061] Therefore, various systems using augmented reality content items, or other such transformation systems that use the data to modify content, and the data itself, can involve the detection of objects (e.g., faces, hands, bodies, cats, dogs, surfaces, objects, etc.) in video frames, the tracking of these objects as they leave, enter, and move around within the field of view, and the modification or transformation of these objects while tracking them. In various examples, different methods can be used to implement such transformations. Some examples may involve generating 3D mesh models of one or more objects, and using transformations of the models and animated textures within the video to implement the transformations. In other examples, tracking points on objects can be used to place images or textures (which can be two-dimensional or three-dimensional) at the tracked locations. In further examples, neural network analysis of video frames can be used to place images, models, or textures within content (e.g., images or video frames). Therefore, augmented reality content items refer both to the images, models, and textures used to create transformations within content, and to the additional modeling and analysis information required to achieve such transformations through object detection, tracking, and placement.

[0062] Real-time video processing can be performed using any type of video data (e.g., video streams, video files, etc.) stored in the memory of any type of computerized system. For example, a user can load a video file and store it in the device's memory, or a video stream can be generated using the device's sensors. Furthermore, computer-animated models can be used to process any object, such as a human face and parts of the human body, animals, or inanimate objects (such as chairs, cars, or other objects).

[0063] In some examples, when a specific modification is selected along with the content to be transformed, the element to be transformed is identified by the computing device and then detected and tracked if the element to be transformed exists in a frame of the video. The elements of the object are modified according to the modification request, thereby transforming the frames of the video stream. For different types of transformations, the transformation of the frames of the video stream can be performed using different methods. For example, for a transformation of frames that primarily refers to changing the form of elements of an object, feature points of each element of the object (e.g., using an Active Shape Model (ASM) or other known methods) are calculated. Then, a feature point-based mesh is generated for each of at least one element of the object. This mesh is used for subsequent stages of tracking the elements of the object in the video stream. During tracking, the mesh mentioned for each element is aligned with the position of each element. Then, additional points are generated on the mesh. A first set of points is generated for each element based on the modification request, and a second set of points is generated for each element based on the first set of points and the modification request. The frames of the video stream can then be transformed by modifying the elements of the object based on the first and second set of points and the mesh. In this method, the background of the object being modified can also be changed or distorted by tracking and modifying the background.

[0064] In some examples, transformations that alter some regions of an object using its elements can be performed by calculating feature points for each element and generating a mesh based on those calculated feature points. Points are generated on the mesh, and various regions are then generated based on these points. The elements of the object are then tracked by aligning the region of each element with the position of at least one of the elements, and the properties of the regions can be modified based on modification requests, thereby transforming frames of the video stream. Depending on the specific modification request, the properties of the mentioned regions can be transformed in different ways. Such modifications can involve: changing the color of the region; removing at least some portions of the region from the frames of the video stream; including one or more new objects in the region based on the modification request; and modifying or deforming the elements of the region or object. In various examples, any combination of such modifications or other similar modifications can be used. For certain models to be animated, some feature points can be selected as control points to determine the entire state space for options used in model animation.

[0065] In some examples of computer animation models that use face detection to transform image data, a specific face detection algorithm (e.g., Viola-Jones) is used to detect faces in the image. The Active Shape Model (ASM) algorithm is then applied to the facial regions of the image to detect facial feature reference points.

[0066] In other examples, other methods and algorithms suitable for face detection can be used. For instance, in some examples, landmarks are used to locate features that represent distinguishable points present in most of the images considered. For example, for a face landmark, the location of the left pupil could be used. If the initial landmark is not recognizable (e.g., if the person is wearing an eye patch), secondary landmarks can be used. Such a landmark recognition process can be used for any such object. In some examples, a set of landmarks forms a shape. The shape can be represented as a vector using the coordinates of points within it. One shape is aligned with another shape through a similarity transformation (allowing translation, scaling, and rotation) that minimizes the average Euclidean distance between the points of the shapes. The average shape is the average of the aligned training shapes.

[0067] In some examples, the search begins by finding landmarks from an average shape aligned with the position and size of a face determined by a global face detector. This search then repeats the following steps: proposing provisional shapes by adjusting the positions of shape points through template matching of the image texture around each point, and then conforming the provisional shapes to a global shape model until convergence occurs. In some systems, individual template matching is unreliable, and the shape model pools the results of weak template matching to form a stronger overall classifier. The entire search is repeated at each level of the image pyramid, from coarse to fine resolution.

[0068] The transformation system can capture image or video streams on a client device (e.g., client device 102) and perform complex image manipulations locally on client device 102 while maintaining an appropriate user experience, computation time, and power consumption. Complex image manipulations can include size and shape changes, emotion shifts (e.g., changing a face from frowning to smiling), state shifts (e.g., aging an object, reducing its apparent age, or changing its gender), style shifts, application of graphical elements, and any other suitable image or video manipulations implemented by a convolutional neural network that has been configured to execute efficiently on client device 102.

[0069] In some examples, a computer animation model for transforming image data can be used by a system in which a user can use a client device 102 with a neural network to capture an image or video stream of the user (e.g., a selfie), the neural network operating as part of a messaging client 104 operating on the client device 102. A transformation system operating within the messaging client 104 determines the presence of a face in the image or video stream and provides a modification icon associated with the computer animation model to transform the image data, or the computer animation model can be presented as associated with the interface described herein. The modification icon includes changes that can be based on modifying the user's face in the image or video stream as part of a modification operation. Once a modification icon is selected, the transformation system initiates a process of transforming the user's image to reflect the selected modification icon (e.g., generating a smiley face on the user). Once the image or video stream is captured and the specified modification is selected, the modified image or video stream can be presented in a graphical user interface displayed on the client device 102. The transformation system can implement a complex convolutional neural network on a portion of the image or video stream to generate and apply the selected modification. In other words, users can capture image or video streams and, once an edit icon is selected, the changes are presented in real-time or near real-time. Furthermore, while a video stream is being captured, the changes can be persistent, and the selected edit icon continues to be toggled. Machine-trained neural networks can be used to achieve such modifications.

[0070] A graphical user interface (GUI) presenting modifications performed by the transformation system can provide users with additional interactive options. Such options can be based on the interface used to initiate content capture and select a specific computer animation model (e.g., initiated from a content creator GUI). In various examples, modifications can be persistent after an initial selection of the modification icon. Users can turn modifications on or off by tapping or otherwise selecting a face modified by the transformation system and save them for later viewing or browsing to other areas of the imaging application. In cases where multiple faces are modified by the transformation system, users can globally turn modifications on or off by tapping or selecting a single face modified and displayed within the GUI. In some examples, individual faces within a group of multiple faces can be modified separately, or such modifications can be toggled individually by tapping or selecting an individual face or a series of individual faces displayed within the GUI.

[0071] Story table 312 stores data about collections of messages and associated image, video, or audio data, compiled into collections (e.g., stories or galleries). The creation of a specific collection can be initiated by a specific user (e.g., each user for whom a record is maintained in entity table 304). A user can create a "personal story" in the form of a collection of content that has already been created and sent / broadcast by that user. For this purpose, the user interface of messaging client 104 may include user-selectable icons that allow the sending user to add specific content to his or her personal story.

[0072] The collection can also constitute a "live story" as a collection of content from multiple users, created manually, automatically, or using a combination of manual and automatic techniques. For example, a "live story" can constitute a curated stream of user-submitted content from different locations and events. Users whose client devices have location services enabled and are at a common location event at a specific time can be presented with the option to contribute content to a specific live story, for example, through the user interface of messaging client 104. The messaging client 104 can identify live stories to users based on their location. The end result is a "live story" told from a collective perspective.

[0073] Another type of content collection is called a "location story," which allows users whose client devices 102 are located in a specific geographic location (e.g., on a college or university campus) to contribute to a specific collection. In some examples, contributing to a location story may require secondary authentication to verify that the end user belongs to a specific organization or other entity (e.g., a student on a university campus).

[0074] As mentioned above, video table 314 stores video data, which in one example is associated with messages for which records are maintained within message table 302. Similarly, image table 316 stores image data, which is associated with messages whose message data is stored in entity table 304. Entity table 304 allows various enhancements from enhancement table 310 to be associated with various images and videos stored in image table 316 and video table 314.

[0075] The distributed real-time status update server data 318 stores instances, nodes, and routing tables or information used by the distributed real-time status update server 107. For example, the distributed real-time status update server data 318 stores FE instances, RTG instances, routing tables, proxy objects or nodes, device objects, and inter-region proxy instances or nodes.

[0076] Data communication architecture

[0077] Figure 4This is a schematic diagram illustrating the structure of message 400 according to some examples. Message 400 is generated by message transceiver client 104 for transmission to another message transceiver client 104 or message transceiver server 114. The content of a particular message 400 is used to populate message table 302 stored in database 120, which is accessible by message transceiver server 114. Similarly, the content of message 400 is stored in memory as "in transit" or "in flight" data of client device 102 or application server 112. Message 400 is shown to include the following example components.

[0078] • Message Identifier 402: A unique identifier that identifies message 400.

[0079] • Message text payload 404: The text to be generated by the user via the user interface of the client device 102 and included in message 400.

[0080] • Message image payload 406: Image data captured by the camera component of the client device 102 or retrieved from the memory component of the client device 102 and included in the message 400. The image data for the sent or received message 400 can be stored in the image table 316.

[0081] • Message video payload 408: Video data captured by the camera device component or retrieved from the memory component of the client device 102 and included in the message 400. The video data for the sent or received message 400 may be stored in the video table 314.

[0082] • Message audio payload 410: Audio data captured by the microphone or retrieved from the memory component of the client device 102 and included in message 400.

[0083] • Message enhancement data 412: Enhancement data (e.g., filters, labels, or other annotations or enhancements) representing enhancements to be applied to the message image payload 406, message video payload 408, or message audio payload 410 of message 400. Enhancement data for the sent or received message 400 can be stored in enhancement table 310.

[0084] • Message duration parameter 414: A parameter value that indicates the amount of time, in seconds, during which the content of the message (e.g., message image payload 406, message video payload 408, message audio payload 410) will be presented to the user or made accessible to the user via the message sending and receiving client 104.

[0085] • Message geolocation parameter 416: Geographic location data (e.g., latitude and longitude coordinates) associated with the message's content payload. Multiple message geolocation parameter 416 values ​​may be included in the payload, each of which is associated with a content item included in the content (e.g., a specific image within the message image payload 406 or a specific video within the message video payload 408).

[0086] • Message Story Identifier 418: An identifier value that identifies one or more content sets (e.g., “Stories” identified in Story Table 312), wherein a specific content item in the message image payload 406 of message 400 is associated with said one or more content sets. For example, the identifier value can be used to associate multiple images within the message image payload 406 with multiple content sets, respectively.

[0087] • Message Tag 420: Each message 400 can be labeled with multiple tags, each tag indicating the subject of the content included in the message payload. For example, if a specific image in the message image payload 406 depicts an animal (e.g., a lion), a tag value indicating the relevant animal can be included in the message tag 420. The tag values ​​can be generated manually based on user input or automatically using, for example, image recognition.

[0088] • Message sender identifier 422: An identifier (e.g., message sending system identifier, email address, or device identifier) ​​indicating the user of the client device 102 on which message 400 is generated and from which message 400 is sent.

[0089] • Message receiver identifier 424: An identifier (e.g., message sending and receiving system identifier, email address, or device identifier) ​​indicating the user of the client device 102 to which message 400 is addressed.

[0090] The content (e.g., values) of each component of message 400 can be pointers to locations within tables that store content data values. For example, an image value in message image payload 406 can be a pointer (or an address of a location within image table 316). Similarly, a value in message video payload 408 can point to data stored in video table 314, a value in message enhancement data 412 can point to data stored in enhancement table 310, a value in message story identifier 418 can point to data stored in story table 312, and values ​​in message sender identifier 422 and message receiver identifier 424 can point to user records stored in entity table 304.

[0091] Figure 5This is a diagrammatic representation of a distributed real-time state update server 107 based on some examples. The distributed real-time state update server 107 includes one or more FE instances 510, one or more RTG instances 520, and an RTG configuration graph 530. A given client device 102 establishes a gRPC connection with the first FE instance 510. In one example, the given client device 102 establishes a gRPC connection with the first FE instance 510 when it opens a chat interface or map interface of a messaging client 104. If the given client device 102 has not previously connected to the distributed real-time state update server 107, or has been connected for more than a threshold time prior to the current time, a new FE instance 510 is created. The first FE instance 510 generates a proxy object 512 for communicating with the given client device 102. The proxy object 512 sends messages from the given client device 102 to the corresponding device object stored on the first RTG instance 520.

[0092] FE instance 510 periodically obtains routing information from RTG configuration diagram 530, and obtains routing information from RTG configuration diagram 530 when FE instance 510 is generated. The routing information identifies the storage locations of multiple device objects on multiple RTG instances 520. FE instance 510 determines whether the identifier of client device 102 is included in the obtained routing information. If so, FE instance 510 receives updates from client device 102 via proxy object 512 and sends the updates to the device objects associated with client device 102 stored on the RTG instance. For example, FE instance 510 determines that first device object 522 corresponds to the identifier of client device 102, and determines that first device object 522 is maintained or stored on first RTG instance 520. In this case, proxy object 512 on FE instance 510 sends updates to first device object 522 by sending a message directed to first device object 522 to first RTG instance 520. The first RTG instance 520 also sends the information stored in the first device object 522 back to the FE instance 510 connected to the client device 102 associated with the first device object 522. To this end, the first RTG instance 520 determines a unique random identifier for the proxy object 512 from which it receives messages and stores this identifier in the routing information 529. The first RTG instance 520 uses the identifier stored in the routing information 529 to identify the proxy object 512 and the FE instance 510 currently connected to the client device 102. The FE instance 510 provides the client device 102 with the information received from the RTG instance 520 (the contents of the device object 522) via the proxy object 512, and the client device 102 then updates the graphical user interface (e.g., updating the location of friends on a map in real time).

[0093] FE instance 510 can determine that the identifier of client device 102 is missing or not included in the obtained routing information. In this case, FE instance 510 instructs one of RTG instances 520 to generate a new device object for client device 102. Then, FE instance 510 provides data from client device 102 to the device object, or from the device object to client device 102, via proxy object 512.

[0094] Each RTG instance 520 stores one or more device objects. For example, a first RTG instance 520 stores a first device object 522 and a second device object 524. A second RTG instance stores a third device object 526. Each RTG instance 520 periodically obtains routing information 529, which identifies which device objects are stored in the corresponding RTG instance 520. The routing information 529 indicates the range of device identifiers processed by each corresponding RTG instance 520. The first device object 522 can process updates received from the client device 102 and identify one or more friends stored on the first device object 522. The first device object 522 generates a message including updates for transmission to the friend device objects. The first message can be sent directly to the second device object 524 within the first RTG instance 520. A second message that needs to be delivered to the third device object 526 can be sent to the third device object 526 via one or more FE instances 510. That is, the third device object 526 can be on an RTG instance outside the RTG instance 520 that stores the first device object. In this scenario, RTG instance 520 selects a proxy object on a given FE instance 510 or one of the FE instances in a random, round-robin, or polling manner. RTG instance 520 sends a message with an identifier for third device object 526 to the selected FE instance 510 or the proxy object. The selected FE instance 510 receives the message and determines which RTG instance to store the third device object 526 based on the routing information 514 stored on the selected FE instance 510. The selected FE instance 510 or the proxy object then sends the message to the identified or determined RTG instance that stores the third device object 526 to update the user information associated with the first device object 522.

[0095] As an example, a first device object 522 can update the location of client device 102. This location update can be shared with other friends of the user of client device 102. A third device object 526 can store a list of friends and their corresponding locations. When the third device object 526 receives a location update from the first device object 522, the third device object 526 identifies the user associated with the first device object 522 and updates the current location stored for the user. FE instance 510 can use another proxy object stored in FE instance 510 corresponding to the third device object 526 to establish a connection with the friend's client device 102. After the connection is established, the friend's location stored in the third device object 526 is provided to the friend's client device 102 to update the graphical user interface presented on client device 102. In this way, the user can receive near-instant updates on the location of their friends on the map and see their friends moving actively on the map.

[0096] In some examples, when FE instance 510 is initially created and stored, a random identifier is assigned to FE instance 510 (e.g., a proxy object stored on FE instance 510). Each device object stored in the RTG instance is assigned an identifier corresponding to the user identifier associated with that device object. For example, first device object 522 is associated with a user of client device 102 and is assigned an identifier that matches the user identifier (e.g., username) of the user of client device 102. In some cases, FE instances only communicate with RTG instances and do not communicate directly with each other or exchange messages. In some implementations, first RTG instance 520 stores a random identifier for proxy object 512 stored on FE instance 510, which sends messages to first RTG instance 520. When any device object in first RTG instance 520 needs to send a message back to proxy object 512, first RTG instance 520 uses the stored random identifier to find the appropriate proxy object and routes the message to that appropriate proxy object, and then to the corresponding client device 102.

[0097] The arrangement and interaction between FE instance 510 and RTG instance 520 enable the storage of thousands of device objects without complex synchronization operations. This also makes the system scalable and allows objects to reside in a distributed manner across geographically dispersed locations and on a variety of storage devices.

[0098] In some examples, the grouped FE instances 510 and RTG instances 520 are divided into different geographical regions. For example, the first group of FE instances 510 and RTG instances 520 are stored in a first geographical region (e.g., the United States), while the second group of FE instances 510 and RTG instances 520 are stored in a second geographical region (e.g., Australia). Messages exchanged between FE instances 510 and RTG instances 520 in the first group within the same geographical region are sent in real time. Messages exchanged between FE instances 510 in the first group and FE instances 510 in the second group are grouped and sent in batches periodically. In this way, the number of times messages are sent between different geographical regions is reduced, which better utilizes network resources and bandwidth.

[0099] Figure 6 This is a diagrammatic representation of a distributed real-time state update server 107 across different geographic regions, based on some examples. Specifically, a user is associated with the geographic region they are located in. For example, a first user in a first geographic region is associated with a device object in the first geographic region. A second user in a second geographic region is associated with a device object in the second geographic region. The mapping between a user and their geographic region, and therefore between a user and the region where their corresponding device object is located, is stored in a globally replicated database table. This table is shared and replicated across the geographic regions. In some cases, the mapping is updated periodically or in real-time when a user moves to a different geographic region. In response to determining that a user has changed geographic regions, the device object stored for the user in the first geographic region is moved or copied to an RTG instance in the geographic region corresponding to the new user's location. In some implementations, the device object is moved or copied, and the geographic region assigned to the user is updated immediately, or after the user has remained in the new geographic region for a threshold number of days.

[0100] In some examples, a first device object 522 in a first geographic region can generate a message directed to a second device object in a second geographic region. Specifically, the first device object 522 looks up the user identifier associated with the second device object in a globally replicated database to determine if the second device object is in the first geographic region. If the second device object is determined to be in the first geographic region, the first device object 522 sends a message to the RTG instance where the second device object is stored. If the second device object is determined to be in the second geographic region, the first device object 522 identifies a first inter-regional proxy node corresponding to the second region. The first inter-regional proxy node can be located in the first geographic region or any other suitable location. The first device object 522 sends a message containing the identifiers of the second user and the second device object to the identified inter-regional proxy node via the FE instance 510.

[0101] The first inter-regional proxy node collects and bundles multiple messages directed from a first geographic region and other geographic regions. Once the first inter-regional proxy node determines that a threshold time period has elapsed since it last sent a message to the second inter-regional proxy node located in the second geographic region, it sends the collected and bundled messages to the second inter-regional proxy node. In some implementations, once the first inter-regional proxy node determines that a threshold number of collected messages has been reached, it sends the collected and bundled messages to the second inter-regional proxy node. The second inter-regional proxy node located in the second geographic region receives the bundled messages from the first inter-regional proxy node and distributes the messages (e.g., randomly) to FE instances in the second geographic region. Specifically, the FE instances in the second geographic region receive messages directed to a second device object from the second inter-regional proxy node and identify RTG instances in the second geographic region that include the second device object. The FE instances provide messages to the second device object via the identified RTG instances.

[0102] Figure 7 This is a diagrammatic representation of RTG instance 520 based on some examples. RTG instance 520 is a combination of... Figure 5 and Figure 6 This is one of many RTG instances discussed. As an example, RTG instance 520 includes a router 529, a device object 522, an input channel 730, a goroutine 720 (or coroutine), and can communicate with a remote database 710. In one example, device object 522 stores various information for a given user, such as the user's last known location, the user's list of friends, the user's group of friends, the last update time of device object 522, and the status and location information of each friend in the friend list or group of friends.

[0103] Device object 522 receives messages via input channel 730. For example, device object 522 receives location updates for the user associated with it or location updates for the user's friends stored in a friend list. Device object 522 receives online status updates for one or more friends of the user listed in device object 522. A goroutine 720 (or coroutine) can manipulate device data stored in device object 522. It does this by repeatedly accessing messages received via input channel 730 and taking actions based on message type. At some point, goroutine 720 may decide that the device object is no longer needed. When this happens, the device object is removed from the graph, and goroutine 720 terminates. Goroutine 720 copies any relevant information stored in device object 522 to a remote database 710. This information may be associated with a user identifier corresponding to device object 522, and when a new device object 522 is created for the same user at a later time, this information is retrieved and copied to the new device object 522.

[0104] Whenever a streaming gRPC connection is established between client device 102 and the distributed real-time state update server, for example, using a proxy object in FE instance 510, a device object 522 for a given user is generated. In some cases, a device object 522 for a given user is generated when a friend of the user sends a message directed to the given user. At startup, when device object 522 is initially created, it retrieves an initial friend list from message server 114. Device object 522 then sends a message to each device object corresponding to a friend in the initial friend list. That is, device object 522 identifies the user identifier of each friend in the list and sends a message to each device object associated with the corresponding one of the identified user identifiers. In some cases, device object 522 only sends messages to these friends who are determined to be active (e.g., currently online users). This message announces that device object 522 has just become online.

[0105] After sending a message announcing that device object 522 has become online, goroutine 720 begins processing messages received on input channel 730 in a specific loop. This loop includes processing input messages based on their type (if any). That is, different functions can be performed for different types of messages. Goroutine 720 then checks for expired friend locations and deletes any expired locations. Goroutine 720 checks whether a state needs to be persisted. If the state is dirty and has not yet persisted for a threshold time period, the state is persisted. Next, goroutine 720 checks preferences that need to be refreshed periodically. Optionally, goroutine 720 then accesses a second remote source (e.g., a third-party source) of the user's location to fetch or determine the user's current location associated with device object 522. If goroutine 720 determines that the location fetched from the second remote source differs by a certain factor (e.g., more than a certain distance relative to the current location stored for the user in device object 522), goroutine 720 updates the current location based on the location retrieved from the second remote source. Finally, goroutine 720 checks for inactivity of client device 102 or the user associated with device object 522. If the device or user is inactive for a threshold period (e.g., 8 hours), for example if no message is received on input channel 730 of device object 522, information from device object 522 is moved to remote database 710 and associated with the identifier of the user corresponding to device object 522. Then, device object 522 is deleted and goroutine 720 is terminated. If the device or user is not inactive for the threshold period, goroutine 720 restarts the loop that includes processing input messages on input channel 730.

[0106] Figure 8A This is a graphical representation of message exchange between device objects in a distributed real-time state update server, based on some examples. For example... Figure 8A As shown, a first user 810 (e.g., a first client device 102 of the first user 810) sends an update (e.g., a status update or a location update) to a first device object 830 associated with the first user 810 via a streaming gRPC connection. Figure 8A The links between the nodes shown indicate the direction of the data flow, and the thickness of the links indicates the type of connection (e.g., real-time data exchange or rate-limited data exchange).

[0107] In one example, a first device object 830 receives a location update from a first user 810. In response, the first device object 830 pushes the location update to a second device object 832 corresponding to a second user 820. The second user 820 also provides location updates to the second device object 832 associated with the second user 820. The second device object 832 also pushes location updates from the second user 820 to the first device object 830 via a streaming gRPC connection 840. Once the first device object 830 receives a location update from the second device object 832, the first device object 830 identifies the entry in the first device object 830 corresponding to the second user 820 and updates the location stored in the entry with the updated location received from the second device object 832.

[0108] The first device object 830 also pushes location updates to the third device object 834 corresponding to the third user. The third user may choose not to send location updates back to the first user, and in this case, the third device object 834 only receives location updates from the first device object 830 without sending location information back to the first device object 830.

[0109] In some implementations, location updates are exchanged in real time between the first device object 830 and the second device object 832. That is, when the first device object 830 receives a location update from the first user 810, it immediately sends the update to the second device object 832. This can be performed in response to the first device object 830 determining that the second user 820 associated with the second device object 832 has a state indicating that the second user 820 needs real-time location information. For example, if the second user 820 is currently viewing an interactive map displaying the location of the second user 820's friend, this state is sent and stored in the friend's entry in the first device object 830. Based on the determination that the second user 820's state is viewing an interactive map displaying a friend's location, the first device object 830 sends the location update received from the first user 810 to the second device object 832 in real time upon receiving an update. Furthermore, the second device object 832 determines that the first user 810 is also viewing an interactive map displaying a friend's location, and therefore can share the location update received from the second user 820 with the first device object 830 in real time.

[0110] First device object 830 may store the state of a third user associated with third device object 834, indicating that the third user currently has messaging client 104 open but is not viewing an interactive map displaying the location of a friend. In this case, first device object 830 may periodically send or share location updates received from first user 810 with third device object 834 via rate-limited link 841. That is, first device object 830 may send updates on the location of first user 810 to third device object 834 only if the location of first user 810 meets a first condition (e.g., changes exceed a first threshold amount, or if the location was last sent to third device object 834 before exceeding a first threshold time amount (e.g., the time elapsed since the last location update was sent to third device object 834 exceeds a first threshold)). In this way, location updates of first user 810 may be sent to some users in real time, but periodically or not at all to other users.

[0111] First device object 830 may store the state of a fourth user associated with fourth device object 836, indicating that the fourth user is currently inactive. In this case, first device object 830 may periodically, rather than in real-time, send or share location updates received from first user 810 with fourth device object 836 via further rate-limited link 842, or not share location at all. Further rate-limited link 842 is more rate-limited than rate-limited link 841. Rate-limited link 841 may allow location swapping or location transmission to third device object 834 when a first condition is met. Further rate-limited link 842 may allow location swapping or location transmission to fourth device object 836 when a second condition is met but the first condition is not met. That is, the first device object 830 may send an update on the location of the first user 810 to the fourth device object 836 only if the location of the first user 810 meets the second condition (e.g., the change exceeds a second threshold amount, or if the location was last sent to the fourth device object 836 before exceeding the second threshold time amount (e.g., the time elapsed since the last update of the location was sent to the fourth device object 836 exceeds the second threshold)). Specifically, location updates shared with the fourth device object 836 may be further restricted relative to those shared with the third device object 834, since the fourth user does not need to view the location information of the first user 810. The second threshold amount used to restrict updates sent to the fourth device object 834 is greater than the first threshold amount used to restrict updates sent to the third device object 834.

[0112] Figure 8BThis is a graphical representation of message exchange between device objects in a distributed real-time state update server, based on some examples. For example... Figure 8B As shown, an Online Update (OU) is a message sent between devices to announce that a device is online and then periodically indicates that the device object remains online. When client device 102 becomes online, an Online Update is sent from client device 102 to the device object. When client device 102 sends a Location Update, a Location Update (LU) is sent to the device object. When a user shares their location with a friend, a Friend Location Update (FLU) is sent between device objects. When a device object wants all other device objects to delete its location, such as when a given user enters ghost mode and does not want their location to be known, a Delete Location Update (DLU) is sent. When a user's preferences are updated, a Preference Update (PU) is sent, causing the device object to retrieve and update its stored preferences. A Message Receipt Update (MRU) is sent to acknowledge message reception between device objects.

[0113] Figure 8B A sample message exchange is provided when a device object initially becomes online. When a device object (e.g., device object A) becomes online and is initialized first, it sends an Online Update (OU) to all its friends (e.g., device objects B, C, and D, which are friends of device object A). Each friend device object B, C, and D responds in one of three ways. For example, the first friend object B responds with an FLU, which indicates the location of the friend stored in the first friend object B. This occurs when the device object receiving the OU shares its location with the device object of the user from whom the OU message was received. Device object A then stores the location received in the FLU message from the first friend object B in the entry for the first friend in device object A.

[0114] The second friend object C responds to an OU message received from device object A with an Online Update (OU). This occurs when the device object receiving the OU does not share a location with device object A from which it receives the OU message but is online (e.g., a client device 102 physically connected to the second friend object C via a corresponding FE instance 510) and is interested in receiving location updates from users associated with device object A. That is, the second friend may expect to see or know the location of users associated with device object A, but may not be interested in sharing their location with users associated with device object A.

[0115] Third friend object D responds to an OU message received from device object A with an MRU message. This occurs when the device object receiving the OU does not share a location with device object A from which it receives the OU message and is not interested in receiving location updates from users associated with device object A, such as because third friend object D is offline (e.g., does not have a client device 102 physically connected to third friend object D via the corresponding FE instance 510). That is, the third friend may not expect to see or know the location of users associated with device object A and may not be interested in sharing their location with users associated with device object A.

[0116] Figure 8C This is a graphical representation of message exchange between device objects in a distributed real-time state update server, based on some examples. For example... Figure 8C As shown, in step 1: Device object A initially becomes online and sends OU messages to all friends listed in device object A. In step 2: To process each OU message received from device object A, a new device object (e.g., an offline device object represented by a dashed circle) (B, C, D, and E) is created for each friend. Since no friend is online or has a recently shared location, each of device objects B, C, D, and E responds to the OU message received from device object A with an MRU message.

[0117] In step 3: A given friend has a client device 102 that has established a connection to device object C via FE instance 510. This causes device object C to become online—device object C switches from an offline device object to an online device object (represented by a solid circle). In response, device object C sends OU messages to all its friends, including device object A. Device object A responds to the OU messages received from device object C with FLU messages to indicate to device object C the current location of the user stored in device object A. In step 4: Device objects A and C establish a connection based on the fact that they are both online and share a location with each other. They continue to exchange FLU messages to provide each other with location updates. Meanwhile, other device objects B, D, and E are deleted after periods of inactivity or after a threshold time period has elapsed since the event associated with the device object occurred. For example, if a threshold amount of time has elapsed since device object B was created, and the corresponding client device 102 has not established a connection with FE instance 510 to make the device object online within that threshold amount of time, then device object B is deleted. As another example, if a threshold amount of time has elapsed since device object C was created and device object C has not received any further messages (e.g., from another user or from device object A), then device object C is deleted.

[0118] In some examples, the offline device object only stores the location information or location sharing preferences of the corresponding user. The online device object includes additional information not included in the offline object, such as the first user's friend list, the connection status of the client device to the first device object, the connection status of the friend's client device to the corresponding device object, the last time of each friend's activity, and the execution thread that provides the estimated location of the first user and the estimated location of the friends.

[0119] In step 5: Device object C becomes offline (e.g., because client device 102, which was initially connected to device object C via FE instance 510, has been disconnected for a threshold time period). In response, device object C stops sending FLU messages to device object A, but device object A continues to send FLU messages to device object C for the threshold time period. In step 6: Since device object A has not received FLU messages from device object C for the threshold time period, device object A stops sending FLU messages to device object C. After device objects A and C have stopped processing messages for a period of time (e.g., device objects A and C have not received messages from other device objects or they have not received messages from client device 102 associated with the respective device object), device objects A and C are removed from the graph.

[0120] Although updates based on shared location were discussed Figure 8B and Figure 8C However, similar functionality applies to sharing any other type of update (e.g., status updates). In this case, instead of sending FLU and LU messages, devices exchange status update messages or preference update messages.

[0121] Figure 9 This is a graphical representation of sending updates based on different friend list versions, based on some examples. In some examples, for each location update (LU) message provided and sent by a given client device 102 to the corresponding device object, client device 102 also provides a friend list version number. This ensures that the friend list used by the device object of client device 102 to send location updates to other device objects reflects the most recent changes to the user's friend list. In this way, if a given user deletes a friend or temporarily wishes to prevent that friend from receiving location updates from that user, the given user's device object does not continue to share location updates based on stale copies of the friend list or preferences.

[0122] For example, as discussed above, at startup, a given user (user A)'s device object 930 retrieves its current friend list 932 from the messaging server 114. This is the friend list that device object 930 uses to send OU messages to friend device objects. At this time, the client device 102 associated with device object 930 also has the same friend list, and therefore they share the same version number (e.g., 1000). At some later point, user A updates their friend list (e.g., unfriends someone on the friend list). In response, client device 102 updates (increments) the version number of the friend list and creates a new friend list 910 with the new version number. This update is sent to messaging server 114. Shortly thereafter, client device 102 sends a location update 920 to the distributed real-time state update server 107, specifically to device object 930. This location update 920 includes the new version number of the friend list. Device object 930 compares the version number received from the location update with the current version number stored on device object 930. In response to determining that the version number stored on device object 930 is different from the version number of the friend list received in the location update, device object 930 temporarily prevents further location updates (FLU messages) from being sent to friend device objects (B, C, D, and E).

[0123] Device object 930 communicates with message transceiver server 114 or client device 102 to obtain the latest friend list corresponding to the version number received in the location update. This synchronizes the friend list stored on device object 930 with the friend list stored or recently changed by the user of client device 102 corresponding to device object 930. Once the friend list is updated, device object 930 continues to send FLU messages with location updates to friends on the updated friend list.

[0124] Figure 10A This is a flowchart illustrating example operation of a distributed real-time state update server 107 during the execution of process 1000, according to an example. Process 1000 can be implemented by computer-readable instructions for execution by one or more processors, such that the operation of process 1000 can be performed, partially or wholly, by functional components of the distributed real-time state update server 107; therefore, reference... Figure 10A Process 1000 is described as an example. However, in other examples, at least some of the operations of process 1000 may be deployed on various other hardware configurations, such as application server 112. The operations in process 1000 may be executed in any order, in parallel, or may be skipped and omitted entirely.

[0125] At operation 1001, the distributed real-time state update server 107 stores a front-end (FE) instance and multiple real-time graph (RTG) instances, each of which includes multiple device objects. The FE instance is configured to communicate with a client device associated with a first user. For example, the distributed real-time state update server 107 stores one or more FE instances 510 and one or more RTG instances 520. FE instance 510 includes a proxy object configured to communicate with client device 102, and the RTG instance includes one or more device objects (e.g., online device objects or offline device objects).

[0126] At operation 1002, the distributed real-time state update server 107 establishes bidirectional streaming remote procedure call (RPC) connections between the FE instance and multiple RTG instances. For example, FE instance 510 establishes RPC connections with one or more RTG instances 520.

[0127] At operation 1003, the distributed real-time state update server 107 receives state updates from the client device via the FE instance. For example, the proxy object 512 of the FE instance 510 receives location updates from the client device 102 via a real-time streaming connection with the client device 102.

[0128] At operation 1004, the distributed real-time state update server 107 determines, through the FE instance, that the first device object corresponding to the client device is stored on the first RTG instance among multiple RTG instances. For example, FE instance 510 identifies device object 522 and which of the RTG instances 520 stores the identified device object 522 by accessing routing information 514.

[0129] At operation 1005, the distributed real-time state update server 107 sends a first message, including a state update, from the FE instance to the first RTG instance to update the first device object. For example, FE instance 510 sends a location update received from client device 102 to device object 522 in the identified RTG instance 520 via a gRPC connection.

[0130] Figure 10B This is a flowchart illustrating example operation of a distributed real-time state update server 107 during the execution of process 1001, according to an example. Process 1001 can be implemented in computer-readable instructions for execution by one or more processors, such that the operation of process 1001 can be performed, partially or wholly, by functional components of the distributed real-time state update server 107; therefore, reference is made below. Figure 10BProcess 1001 is described as an example. However, in other examples, at least some of the operations in process 1001 may be deployed on various other hardware configurations, such as application server 112. The operations in process 1001 may be executed in any order, in parallel, or may be skipped and omitted entirely.

[0131] At operation 1011, the distributed real-time state update server 107 stores one or more front-end (FE) instances and multiple real-time graph (RTG) instances. For example, the distributed real-time state update server 107 stores one or more FE instances 510 and one or more RTG instances 520. FE instance 510 includes a proxy object configured to communicate with client device 102, and the RTG instance includes one or more device objects (e.g., online device objects or offline device objects).

[0132] At operation 1012, the distributed real-time state update server 107 receives updates from the first client device of the given user via the first online device object associated with the given user. For example, as... Figure 8C As shown in step 1, online device object A receives a location update from FE instance 510, which is coupled to the first client device of a given user.

[0133] At operation 1013, the distributed real-time state update server 107 generates, from the first online device object, an updated message to be sent to multiple friends of a given user. For example, as... Figure 8C As shown in steps 1 and 2, online device object A sends an OU message to the device objects of a given user's friends (such as device objects B, C, D, and E).

[0134] At operation 1014, the distributed real-time state update server 107 stores, on a given instance among multiple RTG instances, an offline device object for the first friend among multiple friends and a second online device object for the second friend among multiple friends. For example, as Figure 8C As shown in step 3, the distributed real-time status update server 107 stores offline device object B (shown by dashed circles) and online device object C (shown by solid circles).

[0135] At operation 1015, the distributed real-time status update server 107 sends a message including updates to the offline device object of the first friend and the second online device object of the second friend via the first online device object. For example, as... Figure 8C As shown in steps 1 to 3, online device object A sends OU messages to offline device object B (shown as a dashed circle) and online device object C (shown as a solid circle).

[0136] Figure 10CThis is a flowchart illustrating example operation of a distributed real-time state update server 107 during the execution of process 1002, according to an example. Process 1002 can be implemented by computer-readable instructions for execution by one or more processors, such that the operation of process 1002 can be performed, partially or wholly, by functional components of the distributed real-time state update server 107; therefore, reference is made below. Figure 10C Process 1002 is described as an example. However, in other examples, at least some of the operations in process 1002 may be deployed on various other hardware configurations, such as application server 112. The operations in process 1002 may be executed in any order, in parallel, or may be skipped and omitted entirely.

[0137] At operation 1021, the distributed real-time state update server 107 stores multiple real-time graph (RTG) instances comprising multiple device objects. For example, the distributed real-time state update server 107 stores one or more FE instances 510 and one or more RTG instances 520. FE instance 510 includes a proxy object configured to communicate with client device 102, and the RTG instance includes one or more device objects (e.g., online device objects or offline device objects).

[0138] At operation 1022, the distributed real-time state update server 107 receives state updates from the client device associated with the first user via a first device object among multiple device objects. For example, proxy object 512 of FE instance 510 receives location updates from client device 102 associated with the first user 810 via a real-time streaming connection to client device 102. Proxy object 512 provides location updates to the first device object 830 associated with the first user 810.

[0139] At operation 1023, the distributed real-time status update server 107 sends a first message including a status update from the first device object to a second device object associated with the second user via a real-time link. For example, the first device object 830 sends a location update to the second device object 832 associated with the second user 820 via a real-time link 840.

[0140] At operation 1024, the distributed real-time status update server 107 sends a second message, including a status update, from the first device object to a third device object associated with the third user via a first rate-limited link. For example, the first device object 830 sends a location update to the third device object 834 associated with the third user via a rate-limited link 841.

[0141] Figure 10DThis is a flowchart illustrating example operation of a distributed real-time state update server 107 during the execution of process 1003, according to an example. Process 1003 can be implemented by computer-readable instructions for execution by one or more processors, such that the operation of process 1003 can be performed, partially or wholly, by functional components of the distributed real-time state update server 107; therefore, reference is made below. Figure 10D Process 1003 is described as an example. However, in other examples, at least some of the operations in process 1003 may be deployed on various other hardware configurations, such as application server 112. The operations in process 1003 may be executed in any order, in parallel, or may be skipped and omitted entirely.

[0142] At operation 1031, the distributed real-time state update server 107 stores multiple real-time graph (RTG) instances comprising multiple device objects, including a first device object associated with a given user. For example, the distributed real-time state update server 107 stores one or more FE instances 510 and one or more RTG instances 520. FE instance 510 includes a proxy object configured to communicate with client device 102, and the RTG instance includes one or more device objects (e.g., online device objects or offline device objects).

[0143] At operation 1032, the distributed real-time state update server 107 receives a friend list of a given user with a first version identifier through a first device object. For example, device object 930 receives a friend list of user A from message transceiver server 114. The friend list has a version number of 1000.

[0144] At operation 1033, the distributed real-time status update server 107 receives an update from a client device associated with a given user via a first device object. This update includes a friend list version identifier. For example, device object 930 receives a location update from client device 102 associated with user A. The location update includes a version identifier of the friend list accessed or stored locally by client device 102. The version identifier may have a version number 1001. As an example, client device 102 may have unfriended a given friend or changed parameters to prevent sharing location with a given friend on the friend list. In response, client device 102 may update the friend list on message transceiver server 114 and increment the friend list version identifier.

[0145] At operation 1034, the distributed real-time state update server 107 determines that the first version identifier of the friend list in the first device object does not match the version identifier of the friend list in the update. For example, device object 930 compares the version identifier stored by device object 930 with the version identifier received in the update to ensure that device object 930 operates on the latest version of the friend list. Device object 930 performs this comparison before sending any further updates to any device objects of a given user's friends.

[0146] At operation 1035, the distributed real-time state update server 107 synchronizes the friend list in the first device object before sending one or more messages, including updates, to other device objects among multiple device objects. For example, in response to device object 930 determining that the current version identifier (e.g., 1000) does not match the version identifier (e.g., 1001) received in an update, device object 930 accesses the friend list from message transceiver server 114 or client device 102 before sending further updates to device objects associated with friends of a given user.

[0147] Machine architecture

[0148] Figure 11This is a schematic representation of machine 1100, within which instructions 1108 (e.g., software, program, application, app, or other executable code) can be executed to cause machine 1100 to perform any or more of the methods discussed herein. For example, instructions 1108 can cause machine 1100 to perform any or more of the methods described herein. Instructions 1108 transform the general, non-programmed machine 1100 into a specific machine 1100 programmed to perform the described and illustrated functions in the described manner. Machine 1100 can operate as a standalone device or can be coupled (e.g., networked) to other machines. In a networked deployment, machine 1100 can operate as a server machine or a client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. Machine 1100 may include, but is not limited to: server computers, client computers, personal computers (PCs), tablet computers, laptop computers, netbooks, set-top boxes (STBs), personal digital assistants (PDAs), entertainment media systems, cellular phones, smartphones, mobile devices, wearable devices (e.g., smartwatches), smart home devices (e.g., smart appliances), other smart devices, web devices, network routers, network switches, network bridges, or any machine capable of sequentially or otherwise executing instructions 1108 specifying actions to be taken by machine 1100. Furthermore, although only a single machine 1100 is shown, the term "machine" should also be considered as a collection of machines that individually or jointly execute instructions 1108 to perform any one or more of the methods discussed herein. For example, machine 1100 may include client device 102 or any of several server devices forming part of message transceiver server system 108. In some examples, machine 1100 may also include both client and server systems, wherein certain operations of a particular method or algorithm are performed on the server side and certain operations of a particular method or algorithm are performed on the client side.

[0149] Machine 1100 may include a processor 1102, a memory 1104, and an input / output (I / O) unit 1138 that can be configured to communicate with each other via a bus 1140. In the example, processor 1102 (e.g., a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a radio frequency integrated circuit (RFIC), another processor, or any suitable combination thereof) may include, for example, processor 1106 and processor 1110 that execute instruction 1108. The term "processor" is intended to include multi-core processors, which may include two or more independent processors (sometimes referred to as "cores") capable of executing instructions simultaneously. Although Figure 11 Multiprocessor 1102 is shown, but machine 1100 may include a single processor with a single core, a single processor with multiple cores (e.g., a multi-core processor), multiple processors with a single core, multiple processors with multiple cores, or any combination thereof.

[0150] Memory 1104 includes main memory 1112, static memory 1114, and memory cell 1116, all of which are accessible to processor 1102 via bus 1140. Main memory 1104, static memory 1114, and memory cell 1116 store instructions 1108 that implement any one or more of the methods or functions described herein. Instructions 1108 may also reside wholly or partially in main memory 1112, in static memory 1114, in machine-readable medium 1118 within memory cell 1116, within at least one processor of processor 1102 (e.g., within the processor's cache memory), or in any suitable combination thereof, during execution by machine 1100.

[0151] I / O component 1138 may include various components for receiving input, providing output, generating output, sending information, exchanging information, capturing measurement results, etc. The specific I / O component 1138 included in a particular machine will depend on the type of machine. For example, portable machines such as mobile phones may include touch input devices or other such input mechanisms, while headless server machines are unlikely to include such touch input devices. It will be understood that I / O component 1138 may include... Figure 11Many other components are not shown. In various examples, I / O component 1138 may include user output component 1124 and user input component 1126. User output component 1124 may include visual components (e.g., displays such as plasma display panels (PDPs), light-emitting diode (LED) displays, liquid crystal displays (LCDs), projectors, or cathode ray tube (CRT) displays), acoustic components (e.g., speakers), haptic components (e.g., vibration motors, resistance mechanisms), other signal generators, etc. User input component 1126 may include alphanumeric input components (e.g., keyboards, touchscreens configured to receive alphanumeric input, photoelectric keyboards, or other alphanumeric input components), point-based input components (e.g., mice, touchpads, trackballs, joysticks, motion sensors, or other pointing instruments), haptic input components (e.g., physical buttons, touchscreens that provide position and force for touch or touch gestures, or other haptic input components), audio input components (e.g., microphones), etc.

[0152] In other examples, I / O component 1138 may include biometric component 1128, motion component 1130, environmental component 1132, or positioning component 1134, as well as various other components. For example, biometric component 1128 includes components for detecting facial expressions (e.g., hand expressions, facial expressions, vocal expressions, body posture, or eye tracking), measuring biosignals (e.g., blood pressure, heart rate, body temperature, sweating, or brain waves), and identifying a person (e.g., voice recognition, retinal recognition, facial recognition, fingerprint recognition, or EEG-based recognition). Motion component 1130 includes accelerometer components (e.g., accelerometers), gravity sensor components, and rotation sensor components (e.g., gyroscopes).

[0153] Environmental component 1132 includes, for example: one or more camera devices (with still image / photograph and video capabilities), lighting sensor components (e.g., photometers), temperature sensor components (e.g., one or more thermometers for detecting ambient temperature), humidity sensor components, pressure sensor components (e.g., barometers), acoustic sensor components (e.g., one or more microphones for detecting background noise), proximity sensor components (e.g., infrared sensors for detecting nearby objects), gas sensors (e.g., gas detection sensors for detecting the concentration of hazardous gases or measuring pollutants in the atmosphere for safety purposes), or other components that can provide indications, measurements, or signals corresponding to the surrounding physical environment.

[0154] Regarding the camera device, client device 102 may have a camera device system including, for example, a front-facing camera on the front surface of client device 102 and a rear-facing camera on the rear surface of client device 102. The front-facing camera may be used, for example, to capture still images and videos (e.g., "selfies") of the user of client device 102, which can then be enhanced using the aforementioned enhancement data (e.g., filters). For example, the rear-facing camera may be used to capture still images and videos in a more conventional camera device mode, which are similarly enhanced using the enhancement data. In addition to the front and rear-facing cameras, client device 102 may also include a 360° camera for capturing 360° photos and videos.

[0155] Furthermore, the camera system of the client device 102 may include dual rear cameras (e.g., a main camera and a depth-sensing camera), or even include triple, quadruple, or quintuple rear camera configurations on the front and rear sides of the client device 102. For example, these multi-camera systems may include wide-angle cameras, ultra-wide-angle cameras, telephoto cameras, macro cameras, and depth sensors.

[0156] The positioning component 1134 includes a position sensor component (e.g., a GPS receiver component), an altitude sensor component (e.g., an altimeter or barometer that detects air pressure to obtain altitude), an orientation sensor component (e.g., a magnetometer), etc.

[0157] A wide variety of technologies can be used to implement communication. I / O component 1138 also includes communication component 1136, which is operable to couple machine 1100 to network 1120 or device 1122 via a suitable coupling or connection. For example, communication component 1136 may include a network interface component or another suitable device to interface with network 1120. In other examples, communication component 1136 may include wired communication components, wireless communication components, cellular communication components, near field communication (NFC) components, etc. Components (e.g.) (low power consumption) Components and other communication components that provide communication via other means. Device 1122 can be any peripheral device from other machines or various peripheral devices (e.g., a peripheral device coupled via USB).

[0158] Furthermore, communication component 1136 may detect identifiers or include components operable to detect identifiers. For example, communication component 1136 may include a radio frequency identification (RFID) tag reader component, an NFC smart tag detection component, an optical reader component (e.g., an optical sensor for detecting one-dimensional barcodes such as Universal Product Code (UPC) barcodes, multi-dimensional barcodes such as Quick Response (QR) codes, Aztec codes, Data Matrix, Dataglyph, MaxiCode, PDF417, UltraCode, UCC RSS-2D barcodes, and other optical codes) or an acoustic detection component (e.g., a microphone for identifying audio signals from tags). Additionally, various information can be derived via communication component 1136, such as location via Internet Protocol (IP) geolocation, etc. The location of signal triangulation, the location of NFC beacon signals that can be detected to indicate a specific location, etc.

[0159] Various memories (e.g., main memory 1112, static memory 1114, and the memory of processor 1102) and storage units 1116 may store one or more sets of instructions and data structures (e.g., software) implemented or used by any one or more of the methods or functions described herein. These instructions (e.g., instruction 1108) cause various operations to implement the disclosed examples when executed by processor 1102.

[0160] Instructions 1108 can be sent or received over network 1120 via a network interface device (e.g., a network interface component included in communication component 1136), using a transmission medium and employing any of several known transmission protocols (e.g., Hypertext Transfer Protocol (HTTP)). Similarly, instructions 1108 can be sent or received via a transmission medium through a coupling (e.g., peer-to-peer coupling) to device 1122.

[0161] Software Architecture

[0162] Figure 12This is a block diagram 1200 illustrating a software architecture 1204 that can be installed on any or more devices described herein. The software architecture 1204 is supported by hardware such as a machine 1202 including a processor 1220, memory 1226, and I / O components 1238. In this example, the software architecture 1204 can be conceptualized as a stack of layers, where each layer provides specific functionality. The software architecture 1204 includes layers such as an operating system 1212, libraries 1210, frameworks 1208, and applications 1206. Operationally, application 1206 activates API call 1250 via the software stack and receives message 1252 in response to API call 1250.

[0163] Operating system 1212 manages hardware resources and provides public services. Operating system 1212 includes, for example, a kernel 1214, services 1216, and drivers 1222. Kernel 1214 acts as an abstraction layer between the hardware layer and other software layers. For example, kernel 1214 provides memory management, processor management (e.g., scheduling), component management, network and security settings, and other functions. Service 1216 can provide other public services to other software layers. Driver 1222 is responsible for controlling or interfacing with the underlying hardware. For example, driver 1222 may include a display driver, a camera driver, etc. or Low-power drivers, flash drives, serial communication drivers (e.g., USB drives), Drivers, audio drivers, power management drivers, etc.

[0164] Library 1210 provides common low-level infrastructure used by application 1206. Library 1210 may include system library 1218 (e.g., the C standard library), which provides functions such as memory allocation, string manipulation, and mathematical functions. Additionally, library 1210 may include API library 1224, such as media libraries (e.g., libraries for supporting the rendering and manipulation of various media formats, such as Moving Picture Experts Group-4 (MPEG4), Advanced Video Coding (H.264 or AVC), Moving Picture Experts Group Layer-3 (MP3), Advanced Audio Coding (AAC), Adaptive Multi-Rate (AMR) audio codec, Joint Picture Experts Group (JPEG or JPG), or Portable Web Graphics (PNG)), graphics libraries (e.g., the OpenGL framework for rendering graphic content on a display in two-dimensional (2D) and three-dimensional (3D) formats), database libraries (e.g., SQLite, which provides various relational database functions), web libraries (e.g., WebKit, which provides web browsing functionality), etc. Library 1210 may also include a wide variety of other libraries 1228 to provide many other APIs to application 1206.

[0165] Framework 1208 provides common high-level infrastructure for use by application 1206. For example, framework 1208 provides various graphical user interface (GUI) functions, advanced resource management, and advanced location services. Framework 1208 can provide a wide range of other APIs that can be used by application 1206, some of which may be specific to a particular operating system or platform.

[0166] In the example, application 1206 may include home application 1236, contact application 1230, browser application 1232, book reader application 1234, location application 1242, media application 1244, messaging application 1246, game application 1248, and a wide variety of other applications such as third-party application 1240. Application 1206 is a program that performs the functions defined in the program. One or more applications 1206 can be created using various programming languages, such as object-oriented programming languages ​​(e.g., Objective-C, Java, or C++) or procedural programming languages ​​(e.g., C or assembly language). In a particular example, third-party application 1240 (e.g., using Android by an entity other than a vendor of a particular platform). TM or iOS TM Applications developed using a Software Development Kit (SDK) can be used on platforms such as iOS. TM ANDROID TM , Mobile software running on the phone's mobile operating system or another mobile operating system. In this example, a third-party application 1240 can call API calls 1250 provided by the operating system 1212 to facilitate the functions described herein.

[0167] Glossary

[0168] "Carrier signal" refers to any intangible medium capable of storing, encoding, or carrying instructions to be executed by a machine, and includes digital or analog communication signals or other intangible media to facilitate the communication of such instructions. Instructions can be sent or received over a network using a transmission medium via a network interface device.

[0169] "Client device" refers to any machine that interfaces with a communication network to obtain resources from one or more server systems or other client devices. Client devices can be, but are not limited to, mobile phones, desktop computers, laptop computers, portable digital assistants (PDAs), smartphones, tablet computers, ultrabooks, netbooks, laptop computers, multiprocessor systems, microprocessor-based or programmable consumer electronics, game consoles, set-top boxes, or any other communication device that a user can use to access the network.

[0170] "Communication network" refers to one or more parts of a network, which can be an ad hoc network, intranet, extranet, virtual private network (VPN), local area network (LAN), wireless LAN (WLAN), wide area network (WAN), wireless WAN (WWAN), metropolitan area network (MAN), the Internet, a part of the Internet, a part of the Public Switched Telephone Network (PSTN), a POTS (Plain Old-Style Telephone Service) network, a cellular telephone network, a wireless network, etc. A network, other types of networks, or a combination of two or more such networks. For example, a network or part of a network may include a wireless network or a cellular network, and the coupling may be a Code Division Multiple Access (CDMA) connection, a Global System for Mobile Communications (GSM) connection, or other types of cellular or wireless coupling. In this example, the coupling can implement any data transmission technology of various types, such as Single Carrier Radio Transmission (1xRTT), Evolved Data Optimization (EVDO), General Packet Radio Service (GPRS), Enhanced Data Rate Evolution of GSM (EDGE), the 3rd Generation Partnership Project (3GPP) including 3G, fourth-generation wireless (4G) networks, Universal Mobile Telecommunications System (UMTS), High-Speed ​​Packet Access (HSPA), Global Microwave Access Interoperability (WiMAX), Long Term Evolution (LTE) standards, other data transmission technologies defined by various standards setting organizations, other long-distance protocols, or other data transmission technologies.

[0171] A "component" is a device, physical entity, or logic having boundaries defined by functional or subroutine calls, branch points, APIs, or other technologies that partition or modularize specific processing or control functions. A component can be combined with other components via its interface to perform machine processing. A component can be an encapsulated functional hardware unit designed for use with other components, and can be part of a program that typically performs a specific function within a related function.

[0172] Components can constitute software components (e.g., code embodied on a machine-readable medium) or hardware components. A “hardware component” is a tangible unit capable of performing certain operations and can be configured or arranged in some physical manner. In various examples, one or more computer systems (e.g., standalone computer systems, client computer systems, or server computer systems) or one or more hardware components (e.g., processors or processor groups) of a computer system can be configured by software (e.g., an application or part of an application) to perform certain operations described herein.

[0173] Hardware components can also be implemented mechanically, electronically, or in any suitable combination thereof. For example, a hardware component may include a dedicated circuit system or logic permanently configured to perform certain operations. The hardware component may be a dedicated processor, such as a field-programmable gate array (FPGA) or an application-specific integrated circuit (ASIC). A hardware component may also include programmable logic or a circuit system temporarily configured by software to perform certain operations. For example, a hardware component may include software executed by a general-purpose processor or other programmable processor. Once configured by such software, the hardware component becomes a specific machine (or a specific component of a machine) uniquely tailored to perform the configured function, and no longer a general-purpose processor. It will be understood that the implementation of a hardware component may be determined, for cost and time considerations, whether mechanically implemented in a dedicated and permanently configured circuit or in a temporarily configured (e.g., software-configured) circuit. Accordingly, the phrase “hardware component” (or “hardware-implemented component”) should be understood to include tangible entities, i.e., entities physically constructed, permanently configured (e.g., hardwired), or temporarily configured (e.g., programmed) to operate or perform certain operations described herein.

[0174] Consider an example where hardware components are temporarily configured (e.g., programmed), without requiring each hardware component to be configured or instantiated at any given time. For instance, where the hardware components include a general-purpose processor configured by software to become a dedicated processor, this general-purpose processor can be configured as different dedicated processors (e.g., including different hardware components) at different times. The software accordingly configures one or more specific processors to constitute a specific hardware component, for example, at one time and as different hardware components at different times.

[0175] Hardware components can provide information to and receive information from other hardware components. Therefore, the described hardware components can be considered communicatively coupled. In the presence of multiple hardware components, communication can be achieved through signal transmission between or among two or more hardware components (e.g., via appropriate circuitry and buses). In embodiments where multiple hardware components are configured or instantiated at different times, such communication between hardware components can be achieved, for example, by storing information in a memory structure accessed by the multiple hardware components and retrieving information from that memory structure. For example, a hardware component can perform an operation and store the output of that operation in a memory device to which it is communicatively coupled. Other hardware components can then access the memory device at a subsequent time to retrieve and process the stored output. Hardware components can also initiate communication with input or output devices and can operate on resources (e.g., information collection).

[0176] Various operations of the example methods described herein can be performed, at least partially, by one or more processors that are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors can constitute components of a processor implementation that operate to perform one or more operations or functions described herein. As used herein, a “processor-implemented component” refers to a hardware component implemented using one or more processors. Similarly, the methods described herein can be implemented, at least partially, by processors, where a particular processor or one or more processors are examples of hardware. For example, at least some operations of the methods can be performed by one or more processors 1102 or processor-implemented components. Furthermore, the one or more processors can also operate to support the execution of relevant operations in a “cloud computing” environment or operate as “Software as a Service” (SaaS). For example, at least some operations can be performed by a group of computers (as an example of a machine including processors), where these operations are accessible via a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., APIs). The execution of some operations can be distributed among processors, not residing only within a single machine, but deployed across multiple machines. In some examples, the processor or processor-implemented component may be located in a single geographic location (e.g., within a home environment, an office environment, or a server cluster). In other examples, the processor or processor-implemented component may be distributed across several geographic locations.

[0177] "Computer-readable storage medium" refers to both machine-readable storage media and transmission media. Therefore, these terms encompass both storage devices / media and carrier / modulated data signals. The terms "machine-readable medium," "computer-readable medium," and "device-readable medium" refer to the same thing and may be used interchangeably in this disclosure.

[0178] A "brief message" is a message that is accessible for a limited period of time. Brief messages can be text, images, videos, etc. The access time for a brief message can be set by the message sender. Alternatively, the access time can be a default setting or a setting specified by the recipient. Regardless of the setting method, the message is temporary.

[0179] "Machine storage medium" refers to one or more storage devices and media (e.g., centralized or distributed databases, and associated caches and servers) that store executable instructions, routines, and data. Therefore, this term should be considered to include, but is not limited to, solid-state memory and optical and magnetic media, including memory internal or external to the processor. Specific examples of machine storage media, computer storage media, and / or device storage media include: non-volatile memory, including, for example, semiconductor memory devices such as erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), FPGAs, and flash memory devices; disks, such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The terms "machine storage medium," "device storage medium," and "computer storage medium" refer to the same thing and are used interchangeably in this disclosure. The terms "machine storage medium," "computer storage medium," and "device storage medium" expressly exclude carrier waves, modulated data signals, and other such media, at least some of which are covered by the term "signal medium."

[0180] "Non-transitory computer-readable storage medium" refers to a tangible medium capable of storing, encoding, or carrying instructions that can be executed by a machine.

[0181] "Signal medium" means any intangible medium capable of storing, encoding, or carrying instructions executable by a machine, and includes digital or analog communication signals or other intangible media that facilitate the communication of software or data. The term "signal medium" should be considered to include any form of modulated data signal, carrier wave, etc. The term "modulated data signal" means a signal whose characteristics are set or altered in a manner that encodes information in the signal. The terms "transmission medium" and "signal medium" refer to the same thing and may be used interchangeably in this disclosure.

[0182] Changes and modifications may be made to the disclosed examples without departing from the scope of this disclosure. Such and other changes or modifications are intended to be included within the scope of this disclosure, as set forth in the appended claims.

Claims

1. A method for state updating, comprising: A front-end FE instance and multiple real-time graph (RTG) instances are stored on a distributed storage system. Each of the multiple RTG instances includes multiple device objects. The FE instance is configured to communicate with a client device associated with a first user. Establish a bidirectional streaming remote procedure call (RPC) connection between the FE instance and the plurality of RTG instances; The FE instance receives status updates from the client device; The first device object corresponding to the client device, as determined by the FE instance, is stored on the first RTG instance among the plurality of RTG instances; A first message is sent from the FE instance to the first RTG instance to update the first device object, the first message including the state update; The first RTG instance generates a second message for sending to the second device object corresponding to the second user, the second message including the status update; as well as The choice is made between sending the second message to the second device object included in the first RTG instance and sending the second message to the FE instance, depending on whether the second device object is included in the first RTG instance.

2. The method according to claim 1, wherein, The FE instance includes a proxy object and routing information. A first part of the routing information indicates that the first RTG instance includes a first subset of the plurality of device objects, and a second RTG instance among the plurality of RTG instances includes a second subset of the plurality of device objects.

3. The method according to claim 2, wherein, The first RTG instance includes a second part of routing information, which identifies a first subset of the plurality of device objects processed by the first RTG instance.

4. The method according to claim 3, further comprising: The first and second parts of the routing information are stored on the real-time graph configuration graph; as well as The first and second portions stored on the FE instance and the first RTG instance are periodically updated.

5. The method according to claim 1, further comprising: It is determined that the second device object is included in the first RTG instance; as well as The selection causes the second message to be sent to the second device object in the first RTG instance to update the information associated with the first user included in the second device object.

6. The method according to claim 1, further comprising: It was determined that the second device object was not included in the first RTG instance; as well as The selection causes the first RTG instance to send the second message to the FE instance, and the second message is directed to the second device object.

7. The method according to claim 6, further comprising: The FE instance determines that the second device object is stored on the second RTG instance among the plurality of RTG instances; as well as The second message is sent from the FE instance to the second RTG instance to update the information associated with the first user included in the second device object.

8. The method according to claim 1, further comprising: Receive status updates from the second client device; as well as A second FE instance is generated in response to receiving the status update from the second client device. The second FE instance has a bidirectional streaming RPC connection to the plurality of RTG instances.

9. The method according to claim 8, further comprising: The second FE instance determines that the identifier of the second client device is missing from the routing information included in the second FE instance; as well as In response to the second FE instance determining that the routing information lacks the identifier of the second client device, a device object corresponding to the second client device is added to a given RTG instance among the plurality of RTG instances.

10. The method according to claim 9, wherein, The FE instance is the first FE instance, and also includes: The first RTG instance selects either the first FE instance or the second FE instance; and A third message is sent from the first device object to the second device object via the selected first FE instance or the second FE instance.

11. The method according to claim 10, wherein, The first FE instance or the second FE instance is selected randomly or in a round-robin manner, at least one of these.

12. The method according to claim 1, wherein, The first message includes the first user's location information or location sharing preferences.

13. The method according to claim 12, wherein, The first device object is an offline device object that only stores the location information or location sharing preferences of the first user.

14. The method according to claim 12, wherein, The first device object is an online device object, which includes the first user's friend list, the connection status between the client device and the first device object, the connection status between the friend's client device and the corresponding device object, the last time of each friend's activity, and an execution thread that provides an estimate of the first user's location and the estimated location of the friends.

15. The method of claim 1, further comprising moving data from the FE instance to a database storage location and deleting the FE instance after a threshold time period.

16. The method according to claim 1, wherein, The FE instance and the plurality of RTG instances are associated with the first geographic region, and also include: Establish a connection between the FE instance and the inter-regional proxy node; Determine that the second device object is associated with the second geographic region; and The second message is sent to the inter-regional proxy node.

17. The method of claim 16, further comprising: The second message is stored in multiple messages of the device object directed to the second geographic region; as well as After a threshold time interval or after the inter-regional proxy node has stored a threshold number of messages, the plurality of messages are sent to the proxy node in the second geographic region, wherein the proxy node in the second geographic region routes the messages to the corresponding device objects in the second geographic region.

18. The method according to claim 17, wherein, The threshold time interval or the threshold number of messages in the second geographic region is different from the threshold time interval or the threshold number of messages in the third geographic region.

19. A system for state updates, comprising: A processor configured to perform operations including: A front-end FE instance and multiple real-time graph (RTG) instances are stored on a distributed storage system. Each of the multiple RTG instances includes multiple device objects. The FE instance is configured to communicate with a client device associated with a first user. Establish a bidirectional streaming remote procedure call (RPC) connection between the FE instance and the plurality of RTG instances; The FE instance receives status updates from the client device; The first device object corresponding to the client device, as determined by the FE instance, is stored on the first RTG instance among the plurality of RTG instances; A first message is sent from the FE instance to the first RTG instance to update the first device object, the first message including the state update; A second message is generated by the first RTG instance for sending to a second device object corresponding to the second user, the second message including the status update; and The choice is made between sending the second message to the second device object included in the first RTG instance and sending the second message to the FE instance, depending on whether the second device object is included in the first RTG instance.

20. A non-transitory machine-readable storage medium, the non-transitory machine-readable storage medium including instructions that, when executed by one or more processors of a machine, cause the machine to perform operations, the operations including: A front-end FE instance and multiple real-time graph (RTG) instances are stored on a distributed storage system. Each of the multiple RTG instances includes multiple device objects. The FE instance is configured to communicate with a client device associated with a first user. Establish a bidirectional streaming remote procedure call (RPC) connection between the FE instance and the plurality of RTG instances; The FE instance receives status updates from the client device; The first device object corresponding to the client device, as determined by the FE instance, is stored on the first RTG instance among the plurality of RTG instances; A first message is sent from the FE instance to the first RTG instance to update the first device object, the first message including the state update; The first RTG instance generates a second message for sending to the second device object corresponding to the second user, the second message including the status update; as well as The choice is made between sending the second message to the second device object included in the first RTG instance and sending the second message to the FE instance, depending on whether the second device object is included in the first RTG instance.

Images