Social account recovery
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- SNAP INC
- Filing Date
- 2020-12-15
- Publication Date
- 2026-05-29
Smart Images

Figure CN114830109B_ABST
Abstract
Description
[0001] Priority requirements
[0002] This patent application claims the benefit of priority to U.S. Application Serial No. 16 / 721,368, filed December 19, 2019, which is incorporated herein by reference in its entirety. Technical Field
[0003] This disclosure generally pertains to providing an account recovery system. Background Technology
[0004] Modern user equipment uses login credentials to give users access to their accounts. Users enter their username and password and can then access their accounts. Sometimes users forget their username and / or password and then need to verify their identity in some way to reset their login credentials. Attached Figure Description
[0005] In drawings that are not necessarily drawn to scale, the same reference numerals may describe the same parts in different views. For ease of identification of any particular element or action being discussed, one or more of the highest-order digits in the reference numerals indicate the drawing number in which the element was first introduced. Some embodiments are shown in the accompanying drawings by way of example rather than limitation, in which:
[0006] Figure 1 This is a block diagram illustrating an example messaging system for exchanging data (e.g., messages and associated content) over a network, according to an example implementation.
[0007] Figure 2 This is a schematic diagram illustrating data that can be stored in a database of a message transceiver server system according to an example implementation.
[0008] Figure 3 This is a schematic diagram illustrating the structure of a message for communication generated by a messaging client application according to an example implementation.
[0009] Figure 4 This is a block diagram illustrating an example account recovery system according to an example implementation.
[0010] Figure 5 This is a flowchart illustrating an example operation of an account recovery system according to an example implementation.
[0011] Figures 6 to 8 These are illustrative inputs and outputs of the account recovery system according to the example implementation.
[0012] Figure 9 This is a block diagram illustrating a representative software architecture that can be used in conjunction with various hardware architectures described herein, according to an example implementation.
[0013] Figure 10 This is a block diagram illustrating components of a machine according to an example embodiment, capable of reading instructions from a machine-readable medium (e.g., a machine-readable storage medium) and performing any or more of the methods discussed herein. Detailed Implementation
[0014] The following description includes systems, methods, techniques, instruction sequences, and computer program products for implementing illustrative embodiments of the present disclosure. In the following description, numerous specific details are set forth for illustrative purposes to provide an understanding of various embodiments. However, it will be apparent to those skilled in the art that embodiments can be practiced without these specific details. Generally, well-known examples of instructions, protocols, structures, and techniques are not necessarily shown in detail.
[0015] Typically, users log in to their accounts by providing login credentials such as a username and / or password. Sometimes users forget their credentials and then go through a password recovery process to reset them. To reset login credentials, a typical system sends users a link via email that allows them to reset their password after verifying their identity. For example, a user can answer one or more personal questions, and then the system allows them to reset their username and / or password. While such systems work well in terms of account recovery, the account recovery process can be multi-step and time-consuming, reducing the overall efficiency of the system. Furthermore, some users forget the answers to their personal questions, resulting in their accounts being completely locked out or requiring them to undergo even more complex account recovery processes. Moreover, such systems cannot be proven secure because one cannot a priori judge the difficulty of the questions or how difficult it is to find the identity (hat) information for a given user.
[0016] Some social networks allow users to select a group of friends who can help them regain access to their accounts. Users can request any of their chosen friends to reset their account or provide their login credentials. While this method of social networking works well for restoring account access if a user forgets their credentials, it can easily lead to account compromise. For example, any of the selected friends could decide to access the user's account independently without the user's permission. Furthermore, if the selected friends' accounts are compromised, the user's account could also be compromised.
[0017] Other social networks use a user's friends to perform two-factor authentication and do not provide additional mechanisms to restore access to a user's account. That is, other social networks determine that the user has successfully logged into the system (e.g., entered the correct login credentials), but the login meets some criteria that indicate suspicious activity. In such cases, the social network communicates with the user's friends to verify the user's identity by requesting the friends to enter some code provided by the user, but does not restore access to the account the user does not remember their login credentials.
[0018] The disclosed implementation improves the efficiency of using electronic devices by providing a system that allows users to regain access to their accounts with the help of two or more friends. The disclosed system employs a process in which a user's friends can help the user regain access to their account, but the information available to each individual friend does not itself enable access to the user's account. In this way, the user's friends can help the user regain access to their account without compromising security. That is, the security of the user's account is maintained, and access to the user's account is not disclosed by a single friend or more than one friend.
[0019] Specifically, according to the disclosed implementation, a messaging application implemented by one or more processors of a user device receives a request to restore access to a user's account. In response, the messaging application accesses a first object corresponding to a first key and receives second and third objects corresponding to corresponding portions of a second key from the user's first and second friends. After deriving a second key based on the second and third objects, access to the user's account is restored based on the first and second keys.
[0020] For example, a first secret and a second secret are generated for a user, and these two secrets can be used together to restore access to the user's account. The first secret can be maintained locally on the user's device. The second secret can be a polynomial (e.g., a line), which can be generated when two points of the line are received. The server enables a first friend to obtain the first of the two points and enables a second friend to obtain the second of the two points. After the two friends provide these two points to the user, the user's device can recreate the second secret. Because either the first or second friend only knows one of the two points needed to generate the line used to determine the second secret, neither friend can individually derive the second secret to attempt to access the user's account. Furthermore, the first secret is unavailable to any of the user's friends, which further prevents unauthorized account restoration from being performed.
[0021] In this way, the disclosed implementation improves the efficiency of using electronic devices by reducing the number of screens and interfaces a user must navigate to regain access to their account when they forget their login credentials. This is accomplished by storing a first key on the user's account and communicating with two or more friends to retrieve a second key required to regain access to the user's account. This reduces the device resources (e.g., processor cycles, memory, and power usage) required to complete tasks using the device.
[0022] Figure 1 This is a block diagram illustrating an example messaging system 100 for exchanging data (e.g., messages and associated content) over network 106. The messaging system 100 includes multiple client devices 102, each hosting several applications including a messaging client application 104 and a third-party application 105. Each messaging client application 104 is communicatively coupled to other instances of the messaging client application 104, the third-party application 105, and the messaging server system 108 via network 106 (e.g., the Internet).
[0023] Therefore, each messaging client application 104 and third-party application 105 can communicate and exchange data with another messaging client application 104 and third-party application 105, as well as with the messaging server system 108, via network 106. The data exchanged between messaging client application 104 and third-party application 105, and between messaging client application 104 and messaging server system 108, includes functionality (e.g., commands to activate functionality) and payload data (e.g., text, audio, video, or other multimedia data). Any public communication between messaging client application 104 and third-party application 105 can be transmitted directly from messaging client application 104 to third-party application 105, and / or indirectly (e.g., via one or more servers) from messaging client application 104 to third-party application 105.
[0024] Third-party application 105 and messaging client application 104 are applications that include a set of functions that allow client device 102 to access account recovery system 124. Third-party application 105 is a separate and distinct application from messaging client application 104. Third-party application 105 is downloaded and installed by client device 102 in a separate manner from messaging client application 104. In some implementations, third-party application 105 is downloaded and installed by client device 102 before or after messaging client application 104 is downloaded and installed. Third-party application 105 is provided by a different entity or organization than the entity or organization that provides messaging client application 104. Third-party application 105 is an application that can be accessed by client device 102 using different login credentials than messaging client application 104. That is, third-party application 105 can maintain a first user account, while messaging client application 104 can maintain a second user account. In this implementation, the client device 102 can access the third-party application 105 to perform various activities and interactions, such as listening to music, watching videos, tracking workouts, viewing graphic elements (e.g., stickers), purchasing tangible items or goods, and communicating with other users.
[0025] For example, third-party application 105 can be a social networking application, dating application, ride-hailing or car-sharing application, shopping application, transaction application, game application, imaging application, music application, video browsing application, exercise tracking application, health monitoring application, second messaging application, or any other suitable application.
[0026] In some implementations, the messaging client application 104 allows a user to regain access to their account if they forget their login credentials. For example, a user can select a "Forgot Password" option to socially regain access to their account by communicating with two or more friends. To achieve this, the messaging client application 104 provides the user with a social account recovery settings option. In response to the user's selection of this social account recovery settings option, the messaging client application 104 generates two secrets required to regain access to the user's account. The first secret can be an integer value and is maintained locally by the user. For example, the first secret can be encoded as a graphical element (e.g., a barcode or visual code), and the user can capture a screenshot of the graphical element. This graphical element can be decoded by the messaging client application 104 to recover the first secret. The first secret will be referred to as secret P. The messaging client application 104 generates a hash of secret P and the user's user identifier (user ID). This hash, referred to as HMAC(P, user ID), is stored on a server in association with the user account.
[0027] The second secret within the secret can be generated as a k-th degree polynomial by the messaging client application 104. This second secret will be referred to as secret Q. For illustrative purposes, this disclosure refers to a first-degree polynomial or a second secret as a line, but any degree is applicable. As the degree increases, the number of friends the user needs to contact and receive portions of the second secret also increases. For example, when the second secret is a first-degree polynomial or a line, the polynomial or second secret can be recovered using any two points along the line. Thus, one of the two points can be provided by the first friend, and the second point can be provided by the second friend. For a second-degree polynomial, more than two points (e.g., four points) may be needed to recover the second secret or polynomial, and therefore, more than two friends (such as four friends) may be needed to provide points along the polynomial so that the user device can recover the polynomial (e.g., the second secret). The messaging client application 104 generates a hash of secret Q and the user's user identifier (user ID). This hash, referred to as HMAC(Q, user ID), is stored on a server in association with the user account.
[0028] The messaging client application 104 can upload and store a hash (e.g., HMAC(P+Q, User ID)) of a first secret, a second secret, and a user identifier on the server. In some cases, the messaging client application 104 sends P+Q and the user ID to the server, and the server calculates the hash function HMAC(P+Q, User ID) based on the first secret, the second secret, and the user identifier provided by the messaging client application 104. In this way, when the messaging client application 104 possesses the first secret and the second secret, during the account recovery process, the messaging client application 104 can hash the first secret, the second secret, and the user identifier to recover the account. For example, the server can receive the value of HMAC(P+Q, User ID) and compare it with a previously stored hash used for account recovery to authorize the user to change their password and / or username if a match is found. That is, the messaging client application 104 provides the server with a hashed value, and if the hashed value matches a previously stored hashed value, the server authorizes the user to regain access to the account. For example, the server may allow users to change their account's username and / or password.
[0029] In some cases, the messaging client application 104 generates another secret (key) P' based on a first secret P. The messaging client application 104 generates a hash of secret P' and the user's user identifier (user ID). This hash, known as HMAC(P', user ID), is stored on the server in association with the user account. In some cases, to trigger user account recovery, the messaging client application 104 uses the secret (key) P' based on the first secret P along with the user identifier. That is, the messaging client application 104 sends secret P' and the hash of the user identifier to the server, instead of the first secret P itself. If the server verifies that the received hash matches the hash of the previously stored P', the server initiates and enables the social account recovery process. This avoids prematurely exposing the first secret P when triggering the account recovery process.
[0030] For example, after a user sets up a social account recovery process, messaging client application 104 requests a first secret from the user. The user can provide the first secret by uploading or capturing an image of a graphical element encoding the first secret P (e.g., an integer value). Next, messaging client application 104 derives P' from P and calculates a hash of the user identifier and P'. Messaging client application 104 then sends this hash to the server. The server verifies that the calculated hash matches a previously stored hash associated with triggering social account recovery. In such cases, the server enables the social account recovery process for the account.
[0031] A user communicates with a first friend via a third-party application 105, with whom they have a bidirectional connection on a messaging client application 104. For example, the user calls their first friend via the third-party application 105 and requests authorization for the recovery of their social media account. Alternatively, the user sends a text or audio message to their first friend via the third-party application 105, requesting authorization for the recovery of their social media account. The first friend logs into their messaging client application 104 and identifies the user in their friend's friend list. The first friend selects the social media account recovery option for the identified user and sends a message to the server requesting the server to recover the user's account. In response, the server verifies that the social media account recovery process has been enabled for the account (e.g., previous communications have been received from the user including a hash of a derived first secret P' and a user identifier). If the social media account recovery process has been enabled, the server computes a value specific to the first friend based on a second secret (e.g., a second key). That is, the server retrieves the second secret Q associated with the user's account and randomly selects a first point along a polynomial corresponding to the second secret Q. This selection can be deterministic for the first friend, such that the first friend always receives the same point during the recovery of a particular user's account. The server sends the first point to the first friend by encoding it as a graphic element. The first friend then sends the graphic element encoded as the first point to the user via a third-party application 105.
[0032] The user also communicates with a second friend via a third-party application 105, with whom they have a bidirectional connection on a messaging client application 104. For example, the user calls the second friend via the third-party application 105 and requests authorization for the recovery of their social media account. Alternatively, the user sends a text or audio message to the second friend via the third-party application 105 and requests authorization for the recovery of their social media account. The second friend logs into their messaging client application 104 and identifies the user in their friend's friend list. The second friend selects the social media account recovery option for the identified user and sends a message to the server requesting the server to recover the user's account. In response, the server verifies that the social media account recovery process has been enabled for the account (e.g., previous communications have been received from the user including a hash of a derived first secret P' and a user identifier). If the social media account recovery process has been enabled, the server computes a value specific to the second friend based on a second secret (e.g., a second key). That is, the server retrieves the second secret Q associated with the user's account and randomly selects a second point along a polynomial corresponding to the second secret Q. This second point differs from the first point selected for the first friend. This selection can be deterministic for the second friend, ensuring that the second friend always receives the same point during a specific user's account recovery. The server sends the second point to the second friend by encoding it as a graphical element. The second friend then sends the encoded graphical element of the second point to the user via a third-party application 105.
[0033] After receiving a graphic element or object from a first friend and a second friend, the user inputs the graphic element or object received from the first friend and the second friend into the messaging client application 104. For example, the user can upload a graphic element or object and / or use a camera to capture an image of the graphic element or object. The messaging client application 104 decodes the first and second points based on the graphic elements or objects received from the first and second friends. The messaging client application 104 calculates a polynomial based on the first and second points corresponding to the second secret. At this point, the messaging client application 104 possesses the first and second secrets and can combine the first and second secrets with a user identifier to recover the user's account. That is, the messaging client application 104 calculates a hash of the first secret, the second secret, and the user identifier and sends the hash to the server. In response to determining that the hash matches a hash previously stored on the server for recovering the user's account, the server navigates the user to a screen that allows the user to log in and / or change the username and / or password of their account.
[0034] In some implementations, after restoring a user's account, the server may instruct the messaging client application 104 to generate a new set of first and second secrets. The messaging client application 104 may generate the new set of first and second secrets in the same manner as before, and may store the hash value associated with the new set of first and second secrets on the server. The server may replace the previously stored hash value with the newly calculated hash value.
[0035] In some implementations, hash values of a first secret and / or a second secret previously stored on the server can be used to perform two-factor authentication. For example, a user can successfully log in to a messaging client application 104. The server can determine that the login activity meets a suspicious activity criterion requiring second-factor authentication. This criterion can be set by the user to always require second-factor authentication, and / or can be set based on rules associated with unauthorized computers or IP addresses. In such a case, the server can request the messaging client application 104 to provide second-factor authentication using the first secret and / or the second secret. To do this, the user can provide the first secret to the messaging client application 104 by capturing an image of a graphic element or object encoded with the first secret, or by uploading an image or graphic element and / or entering the value of the first secret. In response, the messaging client application 104 calculates a hash of the first secret decoded from the graphic element and the user's identifier. The messaging client application 104 sends this hash to the server. In response to determining that the hash matches a hash of the first secret and the user's identifier previously stored on the server, the server can determine that second-factor authentication has been satisfied. In some cases, instead of sending hashes to be stored on the server, the message sending client application 104 sends plaintext P, Q, P+Q and / or P' along with a user identifier to the server. The server then calculates and stores the relevant hash function of the plaintext information received by the server (e.g., the server may calculate HMAC(P, user ID), HMAC(Q, user ID), HMAC(P+Q, user ID) and / or HMAC(P', user ID) based on the plaintext P, Q, P' and / or P+Q provided by the client device).
[0036] In some implementations, a user can communicate with two or more friends to obtain graphical elements or objects associated with a second secret. For example, a user can communicate with a first friend and a second friend via a third-party application 105, who are bidirectionally connected on a messaging client application 104. The first and second friends then each log into their messaging client application 104 and identify the user from their friend's friend list. The first and second friends select a two-factor authentication option for the identified user and send a message to the server requesting a portion of the second secret. In response, the server verifies that two-factor authentication is enabled for the user and calculates a first and a second value specific to the first and second friends based on the second secret (e.g., a second key). That is, the server retrieves the second secret Q associated with the user's account and randomly selects a first and a second point along a polynomial corresponding to the second secret Q. The server sends the first and second points to the first and second friends respectively by encoding the points as graphical elements or objects. The first and second friends then send the graphical elements encoded with the first and second points to the user via the third-party application 105. The user can then provide the messaging client application 104 with graphical elements encoding the first and second points to recover the second secret. The messaging client application 104 calculates a hash of the second secret and the user's identifier. The messaging client application 104 sends this hash to the server. In response to determining that the hash matches a previously stored hash of the second secret and the user identifier on the server, the server can determine that the second-factor authentication has been satisfied.
[0037] The messaging server system 108 provides server-side functionality to a specific messaging client application 104 via network 106. While some functions of the messaging system 100 are described herein as being performed by either the messaging client application 104 or the messaging server system 108, it should be understood that the location of certain functions within either the messaging client application 104 or the messaging server system 108 is a design choice. For example, it is technically preferred that certain technologies and functions be initially deployed within the messaging server system 108, but later migrated to the messaging client application 104 on the client device 102 with sufficient processing power.
[0038] The messaging server system 108 supports various services and operations provided to the messaging client application 104. Such operations include sending data to and receiving data from the messaging client application 104, and processing data generated by the messaging client application 104. This data may include, for example, message content, client device information, graphical elements, geolocation information, media annotations and overlays, virtual objects, message content persistence conditions, social network information, and life event information. Data exchange within the messaging system 100 is activated and controlled through functions available via the user interface (UI) (e.g., a graphical user interface) of the messaging client application 104.
[0039] Now, specifically to message transceiver server system 108, 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 easy access to database 120, in which data associated with messages processed by application server 112 is stored.
[0040] Specifically, API server 110 handles the receiving and sending of 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 can be invoked or queried by message sending / receiving client application 104 and third-party application 105 to activate the functionality of application server 112. API server 110 displays various functions supported by application server 112, including: account registration; login functionality; sending messages from a specific messaging client application 104 to another messaging client application 104 or a third-party application 105 via application server 112; sending media files (e.g., graphic elements, images, or videos) from messaging client application 104 to messaging server application 114, and making them potentially accessible to another messaging client application 104 or a third-party application 105; a list of graphic elements; setting up media data sets (e.g., stories); retrieving such sets; retrieving the friend list of the user of client device 102; maintaining augmented reality items; retrieving messages and content; adding and deleting friends in the social graph; the position of friends in the social graph; accessing user conversation data; accessing avatar information stored on messaging server system 108; and opening application events (e.g., related to messaging client application 104).
[0041] Application server 112 hosts several applications and subsystems, including message transceiver server application 114, image processing system 116, social networking system 122, and account recovery system 124. Message transceiver server application 114 implements several message processing 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 message transceiver client application 104. As will be described in further detail, text and media content from multiple sources can be aggregated into content collections (e.g., referred to as stories or galleries). These collections are then made available to message transceiver client application 104 by message transceiver server application 114. Given the hardware requirements for such processing, additional processor- and memory-intensive data processing can also be performed on the server side by message transceiver server application 114.
[0042] Application server 112 also includes an image processing system 116, which is typically dedicated to performing various image processing operations on images or videos received within the payload of messages at message transceiver server application 114. A portion of the image processing system 116 may also be implemented by account recovery system 124.
[0043] Social networking system 122 supports various social networking functions and services and makes these functions and services available to messaging server application 114. To this end, social networking system 122 maintains and accesses an entity graph within database 120. Examples of functions and services supported by social networking system 122 include identifying other users of messaging system 100 with whom a particular user has a relationship or who is “following,” as well as identifying other entities and interests of a particular user. Such other users can be referred to as the user’s friends. Social networking system 122 can access location information associated with each of the user’s friends to determine where they live or are currently geographically located. Social networking system 122 can maintain a location profile for each of the user’s friends, indicating the geographical location where the user’s friends reside.
[0044] Account Recovery System 124 allows users to set up social account recovery and perform social two-factor authentication.
[0045] Application server 112 is communicatively coupled to database server 118, which provides access to database 120, where data associated with messages processed by message server application 114 is stored. Database 120 may be a third-party database. For example, application server 112 may be associated with a first entity, and database 120, or a portion thereof, may be associated with and hosted by a second, different entity. In some implementations, database 120 stores user data collected by the first entity regarding each user among the various users of the services provided by the first entity. For example, user data may include username, phone number, password, address, friends, activity information, preferences, videos or content consumed by the user, etc.
[0046] Figure 2 This is a schematic diagram 200 illustrating data that can be stored in a database 120 of a message transceiver server system 108 according to some example implementations. Although the contents of the database 120 are shown to include 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).
[0047] Database 120 includes message data stored in message table 214. Entity table 202 stores entity data, including entity diagram 204. Entities maintaining records in entity table 202 can include individuals, company entities, organizations, objects, locations, events, etc. Regardless of 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).
[0048] Entity Graph 204 stores information about the relationships and associations between entities. For example, such relationships can be social, professional (e.g., working in the same company or organization), interest-based, or activity-based.
[0049] Message table 214 may store a collection of conversations between a user and one or more friends or entities. Message table 214 may include various attributes for each conversation, such as a list of participants, the size of the conversation (e.g., the number of users and / or the number of messages), the chat color of the conversation, a unique identifier for the conversation, and any other conversation-related characteristics.
[0050] Database 120 also stores annotation data in annotation table 212 as an example of filters. Database 120 also stores the annotation content received in annotation table 212. The filters storing data in annotation table 212 are associated with and applied to videos (whose data is stored in video table 210) and / or images (whose data is stored in image table 208). In one example, a filter is an overlay displayed as an overlay on an image or video during presentation to the receiving user. Filters can be of various types, including filters selected by the user from a filter gallery presented to the sending user by the messaging client application 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 application 104 within the UI based on geographic location information determined by the Global Positioning System (GPS) unit of the client device 102. Another type of filter is a data filter, which can be selectively presented to the sending user by the messaging client application 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.
[0051] Other annotation data that can be stored within image table 208 is so-called "lens" data. A "lens" can be a real-time specific effect or sound that can be added to an image or video. Lenses are also known as augmented reality items.
[0052] As described above, video table 210 stores video data, which in one embodiment is associated with messages for which records are maintained in message table 214. Similarly, image table 208 stores image data associated with messages whose message data is stored in entity table 202. Entity table 202 can associate various annotations from annotation table 212 with various images and videos stored in image table 208 and video table 210.
[0053] Account recovery value 207 stores various hash values for each user account. For example, a given user identifier can be associated in account recovery value 207 with a first hash HMAC(P, user ID), a second hash HMAC(P', user ID), a third hash HMAC(Q, user ID), and a fourth hash HMAC(P+Q, user ID). The first and third hashes can be associated with and specifically used to perform two-factor authentication for a given user. The second hash can be associated with the account recovery process and used to trigger the account recovery process. The fourth hash can be associated with the account's username and / or password and used to enable the user to log in and / or change the account's username and / or password. Account recovery value 207 can store the value Q in plaintext and / or encrypted form. Any hash value can be stored in plaintext and / or encrypted form.
[0054] Story table 206 stores data related to messages and collections of 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 records are maintained in entity table 202). A user can create a "personal story" in the form of a collection of content that has been created and sent / broadcast by that user. For this purpose, the UI of the messaging client application 104 can include user-selectable icons that allow the sending user to add specific content to his or her personal story.
[0055] Collections can also constitute "life stories," which are collections of content from multiple users, created manually, automatically, or using a combination of manual and automatic technologies. For example, a "life story" can form a curated flow of user-submitted content from various 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 options, for example, via the UI of messaging client application 104, to contribute content to a specific life story. The messaging client application 104 can identify life stories to a user based on their location. The end result is a "life story" told from a community perspective.
[0056] 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 implementations, 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).
[0057] Figure 3This is a schematic diagram illustrating the structure of a message 300 according to some embodiments. The message 300 is generated by a message transceiver client application 104 for transmission to another message transceiver client application 104 or a message transceiver server application 114. The content of a particular message 300 is used to populate a message table 214 stored in a database 120, which is accessible by the message transceiver server application 114. Similarly, the content of the message 300 is stored in memory as “in transit” or “in flight” data for the client device 102 or application server 112. The message 300 is shown to include the following components:
[0058] • Message Identifier 302: A unique identifier that identifies message 300.
[0059] • Message text payload 304: The text to be generated by the user via the UI of the client device 102 and included in message 300.
[0060] • Message image payload 306: Image data captured by the camera device component of the client device 102 or retrieved from the memory of the client device 102 and included in the message 300.
[0061] • Message video payload 308: Video data captured by the camera device component or retrieved from the memory component of the client device 102 and included in the message 300.
[0062] • Message audio payload 310: Audio data captured by the microphone or retrieved from the memory component of the client device 102 and included in the message 300.
[0063] • Message annotation 312: Annotation data (e.g., filters, stickers, or other enhancements) representing annotations to be applied to message image payload 306, message video payload 308, or message audio payload 310 of message 300.
[0064] • Message duration parameter 314: A parameter value that indicates the amount of time, in seconds, during which the content of the message (e.g., message image payload 306, message video payload 308, message audio payload 310) will be presented to the user or made accessible to the user via the message sending and receiving client application 104.
[0065] • Message geolocation parameter 316: Geographic location data (e.g., latitude and longitude coordinates) associated with the content payload of the message. The payload may include multiple message geolocation parameter 316 values, each of which is associated with a content item included in the content (e.g., a specific image within the message image payload 306, or a specific video within the message video payload 308).
[0066] • Message Story Identifier 318: An identifier value that identifies one or more content sets (e.g., "story") to which a specific content item in the message image payload 306 of message 300 is associated. For example, multiple images within the message image payload 306 may each be associated with multiple content sets using identifier values.
[0067] ● Message Label 320: Each message 300 can be labeled with multiple labels, each label indicating the subject of the content included in the message payload. For example, if a specific image in the message image payload 306 depicts an animal (e.g., a lion), a label value indicating the relevant animal can be included in the message label 320. The label values can be generated manually based on user input, or automatically using, for example, image recognition.
[0068] ●Message sender identifier 322: An identifier (e.g., message sending system identifier, email address, or device identifier) indicating the user of the client device 102 on which message 300 is generated and from which message 300 is sent.
[0069] • Message receiver identifier 324: An identifier (e.g., a messaging system identifier, email address, or device identifier) indicating the user of the client device 102 to which the message 300 is addressed. In the case of a conversation between multiple users, the identifier can indicate each user involved in the conversation.
[0070] The content (e.g., values) of various components of message 300 can be pointers to locations of stored content data values in tables. For example, image values in message image payload 306 can be pointers to locations (or addresses) within image table 208. Similarly, values in message video payload 308 can point to data stored in video table 210, values stored in message annotation 312 can point to data stored in annotation table 212, values stored in message story identifier 318 can point to data stored in story table 206, and values stored in message sender identifier 322 and message receiver identifier 324 can point to user records stored in entity table 202.
[0071] Figure 4This is a block diagram illustrating an example account recovery system 124 according to an exemplary implementation. The account recovery system 124 includes an account recovery setting module 414, an account recovery request module 416, and an account recovery key module 418.
[0072] Account recovery settings module 414 enables the user to activate the social account recovery process for their account. Account recovery settings module 414 generates a first secret (key), which can be a random integer value. Account recovery settings module 414 generates a second secret (key), which can be a k-th degree polynomial or function. Account recovery settings module 414 encodes the first secret as an object or graphical element and instructs the user to securely save the object or graphical element. In some cases, account recovery settings module 414 displays the graphical element and instructs the user to capture a screenshot of the graphical element. The screenshot can be stored locally on client device 102 and / or on another storage device associated with the user. Account recovery settings module 414 generates a derivative of the first secret (e.g., P').
[0073] In its implementation, the account recovery setting module 414 generates a first hash by applying a hash function HMAC to a first secret (P) and the user ID. The account recovery setting module 414 generates a second hash by applying the hash function HMAC to a secret P' derived from the first secret and the user ID. The account recovery setting module 414 generates a third hash by applying the hash function HMAC to a second secret (Q) and the user ID. The account recovery setting module 414 generates a fourth hash by combining (summing) the first and second secrets and applying the hash function HMAC to the combined first and second secrets (P+Q) and the user ID. The account recovery setting module 414 sends the first, second, third, and fourth hash values to the server to be stored in the account recovery value 207 in association with the user's account. After generating the second secret and sending the hash value to the server, the account recovery setting module 414 can delete the second secret from local storage.
[0074] Account recovery request module 416 allows a user to regain access to their account socially. Specifically, account recovery request module 416 receives a user selection of an option to regain access to their account socially (e.g., by selecting the "forgot password" option). In response, account recovery request module 416 requests the user to provide a first secret (key). The user can provide the first secret by uploading or capturing an image of a graphical element that encodes the first secret P (e.g., an integer value). Next, account recovery request module 416 derives P' from P and calculates a hash of the user identifier and P'. Account recovery request module 416 transmits this hash to the server. The server verifies that the calculated hash matches a second hash value stored in association with the user's account. In response to the determination that the values match, the server initiates the social account recovery process for the account.
[0075] A user communicates with a first friend via a third-party application 105, with whom they have a bidirectional connection on a messaging client application 104. For example, the user calls their first friend via the third-party application 105 and requests authorization for the recovery of their social media account. The first friend logs into their messaging client application 104 on their own device and identifies the user in their friend's friend list. The first friend selects the social media account recovery option for the identified user and sends a message to the server requesting the recovery of the user's account. In response, the server verifies that the social media account recovery process has been enabled for the account. If the social media account recovery process has been enabled, the server calculates a value specific to the first friend based on a second secret (e.g., a second key). That is, the server retrieves the second secret Q associated with the user's account from the account recovery value 207 and randomly selects a first point along a polynomial corresponding to the second secret Q. The server encodes the first point as a graphical element or object and sends the graphical element or object to the first friend. The first friend then sends the graphical element or object encoded with the first point back to the user via the third-party application 105.
[0076] The user also communicates with a second friend via a third-party application 105, with whom they have a bidirectional connection on a messaging client application 104. For example, the user sends a message to the second friend via the third-party application 105, requesting authorization for the recovery of the user's social account. The second friend logs into their messaging client application 104 on their own device and identifies the user in their friend's friend list. The second friend selects the social account recovery option for the identified user and sends a message to the server requesting the server to recover the user's account. In response, the server verifies that the social account recovery process has been enabled for the account. If the social account recovery process has been enabled, the server calculates a value specific to the second friend based on a second secret (e.g., a second key). That is, the server retrieves the second secret Q associated with the user's account from the account recovery value 207 and randomly selects a second point (different from the first point) along a polynomial corresponding to the second secret Q. The server encodes the second point as a graphical element or object and sends the graphical element or object to the second friend. The second friend then sends the graphical element or object encoded with the second point to the user via the third-party application 105.
[0077] After receiving graphical elements or objects from a first friend and a second friend via a third-party application 105, the user inputs these graphical elements or objects into the account recovery request module 416. The account recovery request module 416 provides the graphical elements or objects received from the first friend and the second friend to the account recovery key module 418. The account recovery key module 418 decodes the first and second points based on the graphical elements or objects received from the first and second friends. The account recovery key module 418 calculates a polynomial based on the first and second points corresponding to the second secret. The account recovery key module 418 then calculates a hash of the first secret, the second secret, and the user identifier, and sends this hash to the server. The server compares the received hash with a fourth hash value stored for the user in the account recovery value 207. In response to determining a hash value match, the server enables or instructs the account recovery request module 416 to allow the user to log in and / or change the user's account username and / or password. After successfully changing the username and / or password, the first secret and the second secret are rotated and / or replaced with new values.
[0078] In some implementations, when the server requests the account recovery system to perform second-factor authentication, the account recovery system performs a similar hash function and / or a first key and second key retrieval function. In such a case, the account recovery request module 416 can be used to receive a first secret from the user after the user successfully logs into the messaging client application 104. The account recovery request module 416 can hash the first secret and the user identifier based on the hash function and send the hash value to the server. The server can compare the hash value with the first hash value stored in the account recovery value 207. In response to determining that the hash value matches, the server can allow the user to continue accessing the messaging client application and determine that the second-factor authentication is satisfied.
[0079] In some cases, the account recovery request module 416 may request the user to obtain a first graphic element and a second graphic element from the user's friends, wherein the first and second graphic elements encode a first corresponding portion and a second corresponding portion of a second secret. The user may provide the first and second graphic elements to the account recovery request module 416. The account recovery request module 416 may calculate the second secret after decoding the first and second portions based on the first and second graphic elements. The account recovery request module 416 may calculate a hash based on a hash function of the second secret and the user identifier. The account recovery request module 416 may provide this hash to the server. The server may determine that the hash value matches a third hash in the account recovery value 207. In response to determining that the hash value matches, the server may allow the user to continue accessing the messaging client application and determine that the second factor authentication is satisfied.
[0080] Figure 5 This is a flowchart illustrating example operations of the account recovery system 124 during the execution of process 500 according to an exemplary implementation. Process 500 can be implemented with computer-readable instructions executable by one or more processors, such that the operation of process 500 can be performed partially or entirely by functional components of the message transceiver server system 108 and / or third-party application 105; therefore, process 500 is described below by way of example with reference to it. However, in other implementations, at least some operations of process 500 can be deployed on various other hardware configurations. Therefore, process 500 is not intended to be limited to message transceiver server system 108 and can be implemented wholly or partially by any other component. Some or all operations of process 500 can be performed in parallel, out of order, or completely omitted.
[0081] At operation 501, the account recovery system 124 receives a request via the user device's messaging application to restore access to the user's account on the messaging application.
[0082] At operation 502, the account recovery system 124 accesses the first object corresponding to the first key (secret).
[0083] At operation 503, the account recovery system 124 receives a second object from the user's first friend on the messaging application, corresponding to the first part of the second key (secret).
[0084] At operation 504, the account recovery system 124 receives a third object from the user's second friend on the messaging application, corresponding to the second part of the second key (secret).
[0085] At operation 505, account recovery system 124 derives a second key (secret) based on the second and third objects.
[0086] At operation 506, account recovery system 124 restores access to the user's account based on the first key and the second key.
[0087] Figures 6 to 8 These are illustrative inputs and outputs of the account recovery system 124 according to an example implementation. Figure 6 Screen 610 is shown, presented to the user in response to a user selection by the messaging client application 104 of an option to set up social account recovery. In response to the user selection of the confirmation option received on screen 610, the messaging client application 104 generates a first secret (key) and a second secret (key). The messaging client application 104 encodes the first secret as a graphical element 622 and displays the graphical element 622 on screen 620. The user can press a suitable button on the client device 102 to capture a screenshot of the graphical element 622 encoding the first key.
[0088] Later, the user can access the login screen 710 of the messaging client application 104. Specifically, Figure 7A login screen 710 is shown, which allows the user to enter credentials for accessing features of the messaging client application 104. The user may forget their credentials and select the "Forgot Credentials" option on screen 710. The messaging client application 104 can determine if the user has previously set up social account recovery. In response to determining that the user has previously set up social account recovery, the messaging client application 104 can request the user to upload a first secret (e.g., an integer value). The messaging client application 104 can present a screen 720 that requests the user to provide a graphical element or object encoded with the first secret. The user can retrieve a previously captured screenshot of the graphical element encoded with the first secret. The user can upload a file including the graphical element encoded with the first secret. Alternatively, the user can activate the camera function and display the graphical element encoded with the first secret on the display of another device. The camera can be pointed at the other device and automatically capture an image of the graphical element encoded with the first secret, providing that graphical element as the first key to the messaging client application 104. The message sending and receiving client application 104 generates a hash of the derived key P' and user identifier, and sends the hash to the server to enable social account recovery for the user.
[0089] A user (e.g., Mary) contacts a first friend (e.g., Rhoda Bowen) by calling or messaging them on another platform, such as a third-party application 105. The user requests a portion of a second secret from the first friend to help the user recover their account. In response, the first friend logs into their messaging client application 104 implemented on their device. After logging in, the first friend accesses a profile page 730 and identifies the user in the first friend's friend list. The user can be a two-way friend of the first friend, meaning the user previously sent a request to become friends with the first friend, and the first friend accepted the request. The first friend can select the "Recover Mary's Account" option 732. In response to selecting option 732, the first friend can receive a first graphical element encoded with the first point or first portion of the user's second secret (key) from the server. The first friend can send the first graphical element to the user via the third-party application 105. For example, the user can... Figure 8 The message shown receives the first graphic element 812. The user can save the first graphic element 812 by capturing a screenshot of the first graphic element.
[0090] The user (e.g., Mary) also contacts the second friend (e.g., Roger) by calling or messaging on another platform, such as a third-party application 105. The user requests that the second friend also obtain a portion of a second secret used to help the user recover their account. In response, the second friend logs into their messaging client application 104 implemented on their device. After logging in, the second friend accesses a profile page 730 and identifies the user in the second friend's friend list. The user can be a two-way friend of the second friend, meaning that the user previously sent a request to become friends with the second friend, and the second friend accepted the request. The second friend can choose option 732 to recover Mary's account. In response to selecting option 732, the second friend can receive a second graphic element encoded from the server, representing a second point or a second portion of the user's second secret (key). The second friend can send the second graphic element to the user via the third-party application 105. The user can store the second graphic element by capturing a screenshot of it.
[0091] The messaging client application 104 can present a screen to the user, allowing the user to input a first graphical element and a second graphical element that encodes a corresponding portion of the second secret. For example, the user can select the "Upload First Object" option 814. In response, the user can upload a file (a screenshot of the previously captured first graphical element) or activate the camera to capture an image of the first graphical element displayed on another monitor (e.g., on the monitor of a first friend's device). The user can select the "Upload Second Object" option 816. In response, the user can upload a file (a screenshot of the previously captured second graphical element) or activate the camera to capture an image of the second graphical element displayed on another monitor (e.g., on the monitor of a second friend's device). The user has now provided the messaging client application 104 with the following: the graphical element that the messaging client application 104 decodes to obtain the first secret; and two or more graphical elements that the messaging client application 104 decodes to obtain the second secret. In response to the user selecting the "Restore Account" option 818, the messaging client application 104 generates a hash by applying a hash function to the first secret, the second secret, and the user identifier. The messaging client application 104 sends the hash value to the server. The server verifies that the hash value matches the hash value stored for the user. In response to the hash value match, the server allows the user to recover their account by logging the user into the messaging client application 104 and / or changing the user's username and / or password.
[0092] Figure 9 This is a block diagram illustrating example software architecture 906, which can be used in conjunction with various hardware architectures described herein. Figure 9This is a non-limiting example of software architecture, and it should be understood that many other architectures can be implemented to facilitate the functionality described herein. Software Architecture 906 can be applied to, for example... Figure 10 The execution is performed on the hardware of machine 1000, which includes processor 1004, memory 1014, and input / output (I / O) components 1018, etc. A representative hardware layer 952 is shown and can represent, for example... Figure 10 The machine 1000. A representative hardware layer 952 includes a processing unit 954 having associated executable instructions 904. The executable instructions 904 represent executable instructions of the software architecture 906, including implementations of the methods, components, etc., described herein. Hardware layer 952 also includes a memory and / or storage module memory / storage device 956, which also has executable instructions 904. Hardware layer 952 may also include other hardware 958.
[0093] exist Figure 9 In the example architecture, software architecture 906 can be conceptualized as a stack of layers, where each layer provides specific functionality. For example, software architecture 906 may include layers such as operating system 902, libraries 920, framework / middleware 918, applications 916, and presentation layer 914. Operationally, applications 916 and / or other components within a layer can activate API calls 908 through the software stack and receive messages 912 in response to API calls 908. The layers shown are representative in nature, and not all software architectures have all layers. For example, some mobile operating systems or dedicated operating systems may not provide a framework / middleware 918, while other operating systems may provide such a layer. Other software architectures may include additional or different layers.
[0094] Operating system 902 can manage hardware resources and provide public services. Operating system 902 may include, for example, a kernel 922, services 924, and drivers 926. Kernel 922 can serve as an abstraction layer between hardware and other software layers. For example, kernel 922 may be responsible for memory management, processor management (e.g., scheduling), component management, networking, security settings, etc. Services 924 can provide other public services to other software layers. Drivers 926 are responsible for controlling or interfacing with the underlying hardware. For example, depending on the hardware configuration, drivers 926 may include display drivers, camera device drivers, Bluetooth drivers, etc. Drivers, flash memory drivers, serial communication drivers (e.g., Universal Serial Bus (USB) drivers), Drivers, audio drivers, power management drivers, etc.
[0095] Library 920 provides common infrastructure used by application 916 and / or other components and / or layers. Library 920 provides functionality that allows other software components to perform tasks more easily than by directly interfacing with the functions of the underlying operating system 902 (e.g., kernel 922, services 924, and / or drivers 926). Library 920 may include system libraries 944 (e.g., the C standard library), which provide functions such as memory allocation functions, string manipulation functions, mathematical functions, etc. Furthermore, Library 920 may include API libraries 946, such as media libraries (e.g., libraries supporting the rendering and manipulation of various media formats such as MPREG4, H.264, MP3, AAC, AMR, JPG, and PNG), graphics libraries (e.g., OpenGL frameworks for rendering 2D and 3D graphical content on a display), database libraries (e.g., SQLite providing various relational database functionalities), web libraries (e.g., WebKit providing web browsing functionality), etc. Library 920 may also include a wide variety of other libraries 948 to provide many other APIs to application 916 and other software components / modules.
[0096] The framework / middleware 918 (sometimes also called middleware) provides a higher level of common infrastructure that can be used by applications 916 and / or other software components / modules. For example, the framework / middleware 918 can provide a variety of graphical user interface functions, advanced resource management, advanced location services, etc. The framework / middleware 918 can provide a wide range of other APIs that can be utilized by applications 916 and / or other software components / modules, some of which may be specific to a particular operating system 902 or platform.
[0097] Application 916 includes built-in applications 938 and / or third-party applications 940. Examples of representative built-in applications 938 may include, but are not limited to: contact applications, browser applications, book reader applications, location applications, media applications, messaging applications, and / or game applications. Third-party applications 940 may include those used by entities other than the platform-specific vendor using Android. 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 other mobile operating systems. Third-party application 940 can activate API calls 908 provided by the mobile operating system (e.g., operating system 902) to facilitate the functions described herein.
[0098] Application 916 can use built-in operating system functions (e.g., kernel 922, services 924, and / or drivers 926), libraries 920, and frameworks / middleware 918 to create a UI for interacting with the system's user. Alternatively or additionally, in some systems, interaction with the user may occur through a presentation layer, such as presentation layer 914. In these systems, the application / component "logic" can be separated from the user-interacting aspects of the application / component.
[0099] Figure 10 This is a block diagram illustrating components of a machine 1000, according to some example embodiments, capable of reading instructions from a machine-readable medium (e.g., a machine-readable storage medium) and performing any or more of the methods discussed herein. Specifically, Figure 10 A diagrammatic representation of machine 1000 is shown as an example of a computer system, in which instructions 1010 (e.g., software, programs, applications, applets, or other executable code) can be executed to cause machine 1000 to perform any or more of the methods discussed herein. Therefore, instructions 1010 can be used to implement the modules or components described herein. Instructions 1010 transform the general, non-programmable machine 1000 into a specific machine 1000 programmed to perform the described and illustrated functions in the described manner. In alternative embodiments, machine 1000 operates as a standalone device or can be coupled (e.g., networked) to other machines. In a networked deployment, machine 1000 can operate as a server machine or client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. Machine 1000 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 1010 specifying actions to be taken by machine 1000. Furthermore, although only a single machine 1000 is shown, the term "machine" should also be considered to include a collection of machines that individually or jointly execute instructions 1010 to perform any or more of the methods discussed herein.
[0100] Machine 1000 may include processor 1004, memory / storage device 1006, and I / O unit 1018, which may be configured to communicate with each other, for example, via bus 1002. In an example embodiment, processor 1004 (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 1008 and processor 1012 capable of executing instructions 1010. The term "processor" is intended to include multi-core processor 1004, which may include two or more independent processors (sometimes referred to as "cores") capable of executing instructions 1010 simultaneously. Although Figure 10 Multiprocessor 1004 is shown, but machine 1000 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.
[0101] Memory / storage device 1006 may include memory 1014, such as main memory or other memory storage devices, and storage cells 1016, both of which are accessed by processor 1004, for example, via bus 1002. Storage cells 1016 and memory 1014 store instructions 1010 that implement any one or more of the methods or functions described herein. Instructions 1010 may also reside wholly or partially in memory 1014, in storage cells 1016, in at least one of the processor 1004 (e.g., in the processor's cache memory), or in any suitable combination thereof during execution by machine 1000. Therefore, memory 1014, storage cells 1016, and the memory of processor 1004 are examples of machine-readable media.
[0102] I / O component 1018 may include various components for receiving input, providing output, generating output, sending information, exchanging information, capturing measurement results, etc. The specific I / O component 1018 included in a particular machine 1000 will depend on the type of machine. For example, a portable machine such as a mobile phone is likely to include a touch input device or other such input mechanism, while a headless server machine is likely not to include such a touch input device. It will be understood that I / O component 1018 may include... Figure 10Many other components are not shown. The grouping of I / O components 1018 according to function is only for the sake of simplifying the following discussion, and this grouping is by no means limiting. In various example embodiments, I / O components 1018 may include output components 1026 and input components 1028. Output components 1026 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), auditory components (e.g., speakers), haptic components (e.g., vibration motors, resistance mechanisms), other signal generators, etc. Input components 1028 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 or other haptic input components that provide position and / or force for touch or touch gestures), audio input components (e.g., microphones), etc.
[0103] In other example implementations, I / O component 1018 may include biometric component 1039, motion component 1034, environmental component 1036, or positioning component 1038, as well as a wide range of other components. For example, biometric component 1039 may include components for detecting expressions (e.g., hand gestures, facial expressions, voice 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 1034 may include: accelerometer component (e.g., accelerometer), gravity sensor component, rotation sensor component (e.g., gyroscope), etc. Environmental component 1036 may include, for example, a lighting sensor component (e.g., a photometer), a temperature sensor component (e.g., one or more thermometers that detect ambient temperature), a humidity sensor component, a pressure sensor component (e.g., a barometer), an hearing sensor component (e.g., one or more microphones that detect background noise), a proximity sensor component (e.g., an infrared sensor that detects nearby objects), a gas sensor (e.g., a gas detection sensor that detects the concentration of hazardous gases for safety purposes or measures pollutants in the atmosphere), or other components that can provide indications, measurements, or signals corresponding to the surrounding physical environment. Positioning component 1038 may include a position sensor component (e.g., a GPS receiver component), an altitude sensor component (e.g., an altimeter or barometer that detects air pressure from which altitude can be obtained), an orientation sensor component (e.g., a magnetometer), etc.
[0104] A variety of technologies can be used to implement communication. I / O component 1018 may include communication component 1040, which is operable to couple machine 1000 to network 1037 or device 1029 via coupling 1024 and coupling 1022, respectively. For example, communication component 1040 may include a network interface component or other suitable device to interface with network 1037. In another example, communication component 1040 may include wired communication component, wireless communication component, cellular communication component, near field communication (NFC) component, Bluetooth component, etc. Components (e.g., Bluetooth) (low power consumption) Components and other communication components that provide communication via other modes. Device 1029 can be any of other machines or various peripheral devices (e.g., a peripheral device coupled via USB).
[0105] Furthermore, the communication component 1040 can detect identifiers or include components operable to detect identifiers. For example, the communication component 1040 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 matrices, data symbols, MaxiCode, PDF417, Ultra Code, UCC RSS-2D barcodes, and other optical codes) or an auditory detection component (e.g., a microphone for identifying audio signals from tags). Additionally, various information can be obtained via the communication component 1040, such as location via Internet Protocol (IP), etc. The location of signal triangulation, the location of NFC beacon signals that can be detected to indicate a specific location, etc.
[0106] Glossary:
[0107] In this context, "carrier signal" refers to any intangible medium capable of storing, encoding, or carrying transient or non-transient instructions 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 transient or non-transient transmission media via network interface devices and using any of a number of well-known transmission protocols.
[0108] In this context, "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, PDAs, smartphones, tablet computers, ultrabooks, netbooks, laptops, 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.
[0109] In this context, "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, another type of network, 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 of a variety of data transmission technologies, 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 standards defined by various standards-setting organizations, other telematics protocols, or other data transmission technologies.
[0110] In this context, "short message" refers to a message that can be accessed for a limited time. Short messages can be text, images, videos, etc. The access time for a short 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 technique, the message is temporary.
[0111] In this context, "machine-readable medium" refers to a component, device, or other tangible medium capable of temporarily or permanently storing instructions and data, and may include, but is not limited to, random access memory (RAM), read-only memory (ROM), buffer memory, flash memory, optical media, magnetic media, cache memory, other types of storage devices (e.g., erasable programmable read-only memory (EEPROM)), and / or any suitable combination thereof. The term "machine-readable medium" should be considered to include a single medium or multiple media capable of storing instructions (e.g., a centralized or distributed database or associated cache and server). The term "machine-readable medium" will also be considered to include any medium or combination of media capable of storing machine-executable instructions (e.g., code) such that, when executed by one or more processors of the machine, the instructions cause the machine to perform any or more of the methods described herein. Therefore, "machine-readable medium" refers to a single storage device or apparatus, and a "cloud-based" storage system or storage network comprising multiple storage devices or apparatuses. The term "machine-readable medium" does not include signals themselves.
[0112] In this context, a “component” refers to a device, physical entity, or logic having boundaries defined by functional or subroutine calls, branch points, APIs, or other technologies that provide partitioning or modularity for a particular processing or control function. 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. A component can constitute a software component (e.g., code implemented on a machine-readable medium) or a hardware component. A “hardware component” is a tangible unit capable of performing certain operations and can be configured or arranged in some physical manner. In various example implementations, 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 application portion) to operate to perform certain operations described herein.
[0113] 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. A hardware component may be a dedicated processor, such as a field-programmable gate array (FPGA) or an 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 part of a machine) uniquely tailored to perform the configured function, and is no longer a general-purpose processor. It will be understood that the decision to implement a hardware component mechanically in a dedicated and permanently configured circuit system or in a temporarily configured (e.g., software-configured) circuit system may be made for cost and time considerations. 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. Consider implementations where hardware components are temporarily configured (e.g., programmed), eliminating the need to configure or instantiate each hardware component at any given time. For example, where the hardware components include a general-purpose processor configured by software as 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.
[0114] 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 (e.g., via appropriate circuitry and buses) between or among two or more hardware components. 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.
[0115] Hardware components can also initiate communication with input or output devices and can operate on resources (e.g., information collection). Various operations of the example methods described herein can be performed, at least partially, by one or more processors configured, either temporarily (e.g., by software) or permanently, to perform the relevant operations. Whether temporarily or permanently configured, such processors can constitute processor-implemented components that operate to perform one or more operations or functions described herein. As used herein, "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 or processor-implemented components. Furthermore, one or more processors can also operate to support the execution of relevant operations in a "cloud computing" environment or 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 certain operations can be distributed across processors, rather than residing within a single machine, but deployed across multiple machines. In some example implementations, the processor or processor-implemented components may reside in a single geographic location (e.g., in a home environment, office environment, or server cluster). In other example implementations, the processor or processor-implemented components may be distributed across several geographic locations.
[0116] In this context, "processor" refers to any circuit or virtual circuit (physical circuitry simulated by logic executed on an actual processor) that manipulates data values according to control signals (e.g., "commands," "opcodes," "machine codes," etc.) and generates corresponding output signals used to operate the machine. For example, a processor can be a CPU, RISC processor, CISC processor, GPU, DSP, ASIC, RFIC, or any combination thereof. A processor can also be a multi-core processor with two or more independent processors (sometimes called "cores") capable of executing instructions simultaneously.
[0117] In this context, a "timestamp" refers to a sequence of characters or encoded information that identifies when an event occurred, such as giving a date and time of day, sometimes accurate to a fraction of a second.
[0118] Changes and modifications may be made to the disclosed embodiments 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 expressed in the appended claims.
Claims
1. A method for restoring access to a social media account, comprising: A request to restore access to a user's account to the messaging application is received via a messaging application implemented by one or more processors of a user device. Access the first object corresponding to the first key; The user receives a second object corresponding to the first part of the second key from his first friend on the messaging application. The user receives a third object from a second friend on the messaging application, which corresponds to the second part of the second key. The second key is derived based on the second object and the third object; as well as Access to the user's account is restored based on the first key and the second key. The first key comprises an integer, and the second key comprises a polynomial of degree k.
2. The method according to claim 1, wherein, The request to restore access includes a request to restore the user's login credentials on the messaging application.
3. The method according to claim 1, further comprising: The user is allowed to change the login credentials of the account on the messaging application to regain access to the account.
4. The method according to claim 1, further comprising: Receive input from the user to enable social-based account access recovery features; In response to receiving the input, the first key is generated; as well as Generate the first object corresponding to the first key.
5. The method of claim 4, further comprising generating a second key representing the line.
6. The method according to claim 5, further comprising: The first value is calculated by applying a hash function to the first key, the second key, and the user's identifier; as well as Store the first value on the server.
7. The method according to claim 6, further comprising: The second value is calculated by applying the hash function to the first key and the user's identifier; The third value is calculated by applying the hash function to the second key and the user's identifier; The third key is derived from the first key; The fourth value is calculated by applying the hash function to the third key and the user's identifier; as well as The second value, the third value, and the fourth value are stored on the server.
8. The method according to claim 1, wherein, The first object, the second object, and the third object include corresponding barcodes or visual codes.
9. The method according to claim 1, wherein, Accessing the first object includes: using the user equipment to capture an image of a barcode or visual code encoded with the first key.
10. The method according to claim 1, further comprising: The user equipment calculates a first value as a hash of the first key and the user identifier; The server determines that the first value matches a previously calculated value used to request account recovery access to the user's account; as well as In response to the server determining that the first value matches a previously calculated value used to request account recovery access to the user's account, account recovery mode is enabled.
11. The method of claim 10, further comprising during the account recovery mode: The server receives a first request for a first portion of the second key from the first friend's first friend's first friend device; The server selects a first random point on the line corresponding to the second key, and the first random point is specifically associated with the first friend. The second object is generated by the server using the first random point; The server provides the second object to the first friend's device; as well as The second object is sent from the first friend's device to the user's user device.
12. The method of claim 11, further comprising during the account recovery mode: The server receives a second request for a second portion of the second key from the second friend's second friend's second friend's device; The server selects a second random point on the line corresponding to the second key, and the second random point is specifically associated with the second friend; The third object is generated by the server using the second random point; The server provides the third object to the second friend's device; as well as The third object is sent from the second friend's device to the user's user device.
13. The method according to claim 12, wherein, The second object and the third object are sent to the user equipment via different messaging applications.
14. The method according to claim 1, further comprising: The first value is generated by applying a hash function to the user identifier, the first key, and the second key; Send the first value to the server; as well as The server determines that the first value matches a previously calculated value used to restore the user's account access, wherein access to the account is restored in response to determining that the first value matches the previously calculated value.
15. The method according to claim 1, further comprising: Second-factor authentication is triggered in response to receiving the correct login credentials from the user to access the account; as well as In response to triggering the second factor authentication, the user is able to verify the account by providing a value calculated using the first key.
16. The method according to claim 1, further comprising: Second-factor authentication is triggered in response to receiving the correct login credentials from the user to access the account; as well as In response to triggering the second factor authentication, the user is able to verify the account by providing a value calculated using the second key.
17. A system for restoring access to a social media account, comprising: A processor of a computing device, the processor being configured to perform operations including the following: The user device's messaging application receives a request to restore access to the user's account for the messaging application; Access the first object corresponding to the first key; The user receives a second object corresponding to the first part of the second key from his first friend on the messaging application. The user receives a third object from a second friend on the messaging application, which corresponds to the second part of the second key. The second key is derived based on the second object and the third object; as well as Access to the user's account is restored based on the first key and the second key. The first key comprises an integer, and the second key comprises a polynomial of degree k.
18. The system according to claim 17, wherein, The request to restore access includes a request to restore the user's login credentials on the messaging application.
19. A non-transitory machine-readable storage medium comprising instructions that, when executed by one or more processors of a machine, cause the machine to perform operations including: The user device's messaging application receives a request to restore access to the user's account for the messaging application; Access the first object corresponding to the first key; The user receives a second object corresponding to the first part of the second key from his first friend on the messaging application. The user receives a third object from a second friend on the messaging application, which corresponds to the second part of the second key. The second key is derived based on the second object and the third object; as well as Access to the user's account is restored based on the first key and the second key. The first key comprises an integer, and the second key comprises a polynomial of degree k.