Patent Description:
Messaging applications can provide the ability for person-to-person communication for users of electronic devices. Texts messages and other content such as images and videos, for example, can be transmitted using messaging applications. Electronic devices such as mobile phones, laptops, computers and smartwatches may be used to participate in electronic messaging. For example, a user of a first device may send content to another user of a second device using a messaging application.

<CIT> discloses a method for suggesting a link to media content.

<CIT> discloses authorizing access to and/or sharing of email attachments.

<CIT> discloses an electronic document having associated activity data and comment data to manage messages and comments about collaboratively edited electronic documents. A type of activity data includes messages among users.

<CIT> discloses a method for selecting a file stored on a cloud server.

A user of a messaging application may wish to send a group (or collection) of files (e.g., images such as photos, videos and/or documents) to one or more recipients. For example, the one or more recipients may be relevant to the group of image and/or video files, because they all attended a particular event together and/or generally shared an experience together. The subject system facilitates, within a messaging application, the sharing of a group of files with others.

The subject system provides a user interface within a messaging application running on an electronic device, for sending a group of files to one or more recipients. In one or more implementations, the one or more recipients are determined, e.g. automatically and/or by user selection, to be relevant to the group of files. The electronic device receives user input requesting that selected files (e.g., images, videos and/or documents) be sent to the recipient(s). The electronic device transmits the request to a server, which creates a shared storage area for the group of files. In one or more implementations, if the selected files are not already stored on the server, the electronic device also provides the selected files to the server.

The server provides, to the electronic device, metadata and other information for accessing the group of files from the shared storage area. The electronic device incorporates the received information for accessing the group of files into a message, such as a text message, and transmits the generated message to respective devices of the one or more recipients. Although the message may include a thumbnail and/or other representation of the group of files, the message does not include the group of files themselves. The one or more recipient devices receive the message, and display the message within a messaging application. The messaging application on the respective recipient devices provides each recipient with the option to accept access to the group of files and display the group of files. Upon accepting access to the group of files, the respective recipient devices may access the files via the shared storage area on the server.

<FIG> illustrates an example network environment for sharing content in a messaging application in accordance with one or more implementations. Not all of the depicted components may be used in all implementations, however, and one or more implementations may include additional or different components than those shown in the figure. Variations in the arrangement and type of the components may be made without departing from the scope of the claims as set forth herein. Additional components, different components, or fewer components may be provided.

The network environment <NUM> includes electronic devices <NUM>, <NUM> and <NUM> (hereinafter <NUM>-<NUM>), a network <NUM> and a server <NUM>. The network <NUM> may communicatively (directly or indirectly) couple, for example, any two or more of the electronic devices <NUM>-<NUM> and/or the server <NUM>. In one or more implementations, the network <NUM> may be an interconnected network of devices that may include, or may be communicatively coupled to, the Internet. For explanatory purposes, the network environment <NUM> is illustrated in <FIG> as including electronic devices <NUM>-<NUM> and a single server <NUM>; however, the network environment <NUM> may include any number of electronic devices and any number of servers.

One or more of the electronic devices <NUM>-<NUM> may be, for example, a portable computing device such as a laptop computer, a smartphone, a peripheral device (e.g., a digital camera, headphones), a tablet device, a wearable device such as a smartwatch, a band, and the like, or any other appropriate device that includes, for example, one or more wireless interfaces, such as WLAN radios, cellular radios, Bluetooth radios, Zigbee radios, near field communication (NFC) radios, and/or other wireless radios. In <FIG>, by way of example, the electronic device <NUM> is depicted as a smartphone, the electronic device <NUM> is depicted as a smartwatch, and the electronic device <NUM> is depicted as a laptop computer. Each of the electronic devices <NUM>-<NUM> may be, and/or may include all or part of the device discussed below with respect to <FIG>, and/or the electronic system discussed below with respect to <FIG>.

The server <NUM> may be, and/or may include all or part of the device discussed below with respect to <FIG>, and/or the electronic system discussed below with respect to <FIG>. The server <NUM> may include one or more servers, such as a cloud of servers, that may be used to facilitate the sharing content between the electronic devices <NUM>-<NUM>. For example, the server <NUM> may receive a request from the electronic device <NUM> to create a shared storage area, for providing the electronic devices <NUM>-<NUM> with access to a group of files. The server may create a shared storage area associated with the group of files, and send information to access the shared storage area back to the electronic device <NUM>. The electronic device <NUM> may generate a message with the received information and send the message to the electronic devices <NUM>-<NUM>. For explanatory purposes, a single server <NUM> is shown and discussed with respect to various operations, such as messaging, providing a cloud-based service for maintaining user content, and/or creating shared storage areas that reference the user content. However, these and other operations discussed herein may be performed by one or more servers, e.g., at one or more different data centers, and each different operation may be performed by the same or different servers.

<FIG> illustrates an example device <NUM> that may implement a system for sharing content in a messaging application in accordance with one or more implementations. For example, the device <NUM> of <FIG> can correspond to any of the electronic devices <NUM>-<NUM>, or to the server <NUM> of <FIG>. Not all of the depicted components may be used in all implementations, however, and one or more implementations may include additional or different components than those shown in the figure. Variations in the arrangement and type of the components may be made without departing from the scope of the claims as set forth herein. Additional components, different components, or fewer components may be provided.

The device <NUM> may include a processor <NUM>, a memory <NUM>, and a communication interface <NUM>. The processor <NUM> may include suitable logic, circuitry, and/or code that enable processing data and/or controlling operations of the device <NUM>. In this regard, the processor <NUM> may be enabled to provide control signals to various other components of the device <NUM>. The processor <NUM> may also control transfers of data between various portions of the device <NUM>. Additionally, the processor <NUM> may enable implementation of an operating system or otherwise execute code to manage operations of the device <NUM>. In the subject system, the processor <NUM> may implement software architecture for sharing content in a messaging application as discussed further below with respect to <FIG> and <FIG>.

The memory <NUM> may include suitable logic, circuitry, and/or code that enable storage of various types of information such as received data, generated data, code, and/or configuration information. The memory <NUM> may include, for example, random access memory (RAM), read-only memory (ROM), flash, and/or magnetic storage.

In one or more implementations, in a case where the device <NUM> corresponds to one of the electronic devices <NUM>-<NUM>, the memory <NUM> may store a messaging application for messaging with the other electronic devices <NUM>-<NUM>, and a file management application for managing and/or editing files (e.g., images such as photos, videos and/or documents).

In one or more implementations, in a case where the device <NUM> corresponds to the server <NUM>, the memory <NUM> may store a cloud-based service for the storage of user content. The cloud-based service may also facilitate in sharing user content.

The communication interface <NUM> may include suitable logic, circuitry, and/or code that enables wired or wireless communication, such as between any of the electronic devices <NUM>-<NUM> and the server <NUM> over the network <NUM>. The communication interface <NUM> may include, for example, one or more of a Bluetooth communication interface, a cellular interface, an NFC interface, a Zigbee communication interface, a WLAN communication interface, a USB communication interface, or generally any communication interface.

In one or more implementations, one or more of the processor <NUM>, the memory <NUM>, the communication interface <NUM>, and/or one or more portions thereof, may be implemented in software (e.g., subroutines and code), may be implemented in hardware (e.g., an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), a Programmable Logic Device (PLD), a controller, a state machine, gated logic, discrete hardware components, or any other suitable devices) and/or a combination of both.

<FIG> illustrates an example of a cloud-based service of the subject system that may be implemented by the server <NUM> in accordance with one or more implementations. For example, the cloud-based service <NUM> can be implemented by one or more software modules running on the processor <NUM> of the server <NUM> and/or any other device. In another example, the cloud-based service <NUM> can be implemented by one or more software modules implemented by custom hardware (e.g., one or more coprocessors). Not all of the depicted components may be used in all implementations, however, and one or more implementations may include additional or different components than those shown in the figure. Variations in the arrangement and type of the components may be made without departing from the scope of the claims as set forth herein. Additional components, different components, or fewer components may be provided.

The cloud-based service <NUM> may include a content database <NUM> and a shared storage area database <NUM>. In one or more implementations, the cloud-based service <NUM> provides users with means to store, maintain and access user content such as images, videos, documents and/or music. For example, the cloud-based service <NUM> may store such content (e.g., images, videos) within the content database <NUM>. The cloud-based service <NUM> may provide respective users (e.g., of the electronic devices <NUM>-<NUM>) with respective user accounts, in order to store, maintain and access their respective content stored on the content database <NUM>.

The cloud-based service <NUM> may further include a shared storage area database <NUM>. The shared storage area database <NUM> may reference content in the content database <NUM>, for the creating and maintaining of shared storage areas. Each storage area may correspond to a group of files (e.g., images, videos) that has been shared by one user (e.g., an owner of the files) with other users, for example, who were determined to be relevant to the group of files. For each group of files corresponding to a shared storage area, the shared storage area database <NUM> may create and maintain references to the files stored in the content database <NUM>.

The content database <NUM> may be local to the shared storage area database <NUM>, such that content may be locally accessed by the shared storage area database <NUM>. Alternatively or in addition, the content database <NUM> may be remote from the shared storage area database <NUM> (e.g., and accessible via the network <NUM>). In one or more implementations, the files stored in the content database <NUM> may reside in a blob storage area (e.g., corresponding to a separate storage vendor), and the content database <NUM> may reference the content as stored in the blob storage area.

As shown in <FIG>, the cloud-based service <NUM> may communicate with one or more electronic devices. In the example of <FIG>, the electronic device <NUM> corresponds to a sending device (e.g., in which an owner is sharing a group of files), and the electronic device <NUM> corresponds to a recipient device (e.g., which receives access to the group of files). For example, a user of the electronic device <NUM> may request that a group of files be shared with a user of the electronic device <NUM>. The cloud-based service <NUM>, together with the content database <NUM> and shared storage area database <NUM>, may receive the request from the electronic device <NUM>, and facilitate in creating a shared storage area corresponding to the group of files for access by the electronic device <NUM>.

In one or more implementations, the cloud-based service <NUM>, the content database <NUM> and the shared storage area database <NUM> are implemented via software instructions, stored in the memory <NUM>, which when executed by the processor <NUM>, cause the processor <NUM> to perform particular function(s).

In one or more implementations, one or more of the cloud-based service <NUM>, the content database <NUM> and the shared storage area database <NUM> may be implemented in software (e.g., subroutines and code) and/or hardware (e.g., an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), a Programmable Logic Device (PLD), a controller, a state machine, gated logic, discrete hardware components, or any other suitable devices) and/or a combination of both. In one or more implementations, some or all of the depicted components may share hardware and/or circuitry, and/or one or more of the depicted components may utilize dedicated hardware and/or circuitry. Additional features and functions of these modules according to various aspects of the subject technology are further described in the present disclosure.

<FIG> illustrates an example process for sharing content in a messaging application in accordance with one or more implementations. For explanatory purposes, the process <NUM> is primarily described herein with reference to the electronic devices <NUM> and <NUM>, and the server <NUM> of <FIG>. However, the process <NUM> is not limited to the electronic devices <NUM> and <NUM>, and the server <NUM> of <FIG>. For example, the process <NUM> may apply to communication between any combination of two or more of the electronic devices <NUM>-<NUM> and the server <NUM>. Moreover, one or more blocks (or operations) of the process <NUM> may be performed by one or more other components of the electronic devices <NUM>-<NUM>, and the server <NUM>, and/or by other suitable devices. Further for explanatory purposes, the blocks of the process <NUM> are described herein as occurring in serial, or linearly. However, multiple blocks of the process <NUM> may occur in parallel. In addition, the blocks of the process <NUM> need not be performed in the order shown and/or one or more blocks of the process <NUM> need not be performed and/or can be replaced by other operations.

As noted above, the server <NUM> may implement a cloud-based service <NUM> for maintaining user content in the content database <NUM>, and for maintaining shared storage areas that access the user content in the shared storage area database <NUM>. In one or more implementations, users of the electronic devices <NUM> and <NUM> may have respective user accounts and be logged into the cloud-based service <NUM>. Alternatively, one user (e.g., of the electronic device <NUM>) may have a user account and be logged into the cloud-based service <NUM>, while the other user (e.g., of the electronic device <NUM>) may not have a registered user account, or may otherwise not be logged into the cloud-based service. In this regard, the electronic devices <NUM> and <NUM> may be from different device manufacturers, and/or be running different operating systems or different versions of operating systems.

In one or more implementations, the electronic devices <NUM> and <NUM> may communicate within an active message thread which includes at least the electronic devices <NUM> and <NUM>. The active message thread is associated with a respective messaging application running on each of the electronic devices <NUM> and <NUM>.

For example, the messaging application may be one or more of an instant messaging application, an email application, a text message application, or another type of application which provides for electronic messaging between the electronic devices <NUM> and <NUM>. The messaging application (e.g., instant messaging, email, text message) may be the same, or may be different, for the electronic devices <NUM> and <NUM>.

The electronic device <NUM> provides a user interface element for sending a group of files to a participant (e.g., the user of the electronic device <NUM>) in the active message thread of the messaging application (<NUM>). As noted above, the memory <NUM> of the electronic device <NUM> may store a file management application for managing and/or editing user files such as images, videos, documents, music or the like.

The file management application on the electronic device <NUM> may work in conjunction with the cloud-based service <NUM>, to store and manage user files (e.g., images, videos and/or documents) in the content database <NUM>, for example, in association with a cloud-based library. Moreover, the cloud-based service <NUM> may automatically identify groups of files (e.g., for potentially sharing with others) based on matching metadata of a user's files. For example, a group of image and/or video files may be identified based on one or more of matching time, location, tagged information (e.g., of the user or contacts of the user), prior user activity, and the like, which is stored in file metadata. In one or more implementations, the server <NUM> may store the information for the identified groups of files in memory <NUM>.

Moreover, the cloud-based service <NUM> in conjunction with the electronic device <NUM> may determine that a group of files is relevant to a user contact (e.g., a participant in an active message thread or other contact). Based on this determination, the electronic device <NUM> may provide for associating the group of files with the user contact. For example, the electronic device <NUM> may store a profile picture in association with the user contact. The electronic device <NUM>, in conjunction with the server <NUM>, may associate the user contact with the group of files, for example, based on facial recognition matching of the contact in the profile picture with a appearing within the group of files. Based on the match, the electronic device <NUM> may consider the contact as being relevant to the group of files.

Additional techniques may be used to identify user contacts that may be relevant to a group of files. For example, such users can be identified based on tagging of the contact in an image or video, determining that prior correspondence between the user and the contact relates to the group of files, and/or other analysis techniques in which information related to the contact (e.g., contact preferences, hobbies, associations) meets a predefined similarity threshold with metadata from the file (e.g., time, place, and/or category).

The user interface element for sharing a group of files within an active message thread on the electronic device <NUM> may be invoked in different ways. For example, the user interface element may be provided as part of an extension application interface within the messaging application. The extension application interface may be a user-selectable interface for invoking extension applications within the messaging application.

In this regard, extension applications provide for performing functions within the messaging application without requiring the user to switch to a standalone version of the application. Example extension applications may provide for sharing content, and/or adding graphics/animations such as stickers to content within the messaging application (e.g., within a message bubble in an active message thread). One example of an extension application is an extension file management application. An extension file management application may be an extension of a standalone version of the file management application, for performing file management (e.g., managing and/or editing photos and/or videos) within the messaging application.

The extension application interface for launching respective extension applications may be provided within the interface of the messaging application. Thus, the electronic device <NUM> may receive user input selecting an icon representing the extension file management application from the extension application interface. In response to the user input, the messaging application may display the user interface element for selecting and sending a group of files to others.

Alternatively or in addition, the user interface element for sending the group of files may be provided in response to user selection of highlighted or otherwise differentiated text presented within the messaging application. For example, text within the active message thread and/or a text within a message input interface (e.g., a message compose box) may match with a predefined category (e.g., place, event) associated with the group of files. In one or more implementations, the matching of such text may be based on tokenized terms of the text meeting a threshold similarity value with respect to the predefined categories. In response to a match, the messaging application may highlight or otherwise differentiate display of the matching text within the active message thread and/or the message input interface. In response to user input selecting the matching text, the messaging application may present the user interface element for selecting and sending the group of files to others.

In this regard, <FIG> illustrates an example user interface <NUM>, provided by the messaging application, for selecting a group of files to share with one or more recipients in accordance with one or more implementations. As mentioned above, the cloud-based service <NUM> may identify groups of files (e.g., for potentially sharing with others) based on metadata associated with the files. In the example user interface <NUM>, a group of files is presented with representations (e.g., thumbnails of image, video or document files) of each file in the group. A user may select one or more of the presented files via an file selection element <NUM> (e.g., in a full screen mode without exiting the messaging application). After selecting the files, the user may confirm selection of the files for sending via a confirm selection element <NUM>.

<FIG> illustrates that user interface <NUM> may further provide for selecting the messaging platform by which one or more recipients are to receive selected files in accordance with one or more implementations. In the example of <FIG>, a share element <NUM> provides for the electronic device <NUM> to email the selected files to participant(s), or to copy a link (e.g., with URL data, described further below) for accessing the files. However, the share element <NUM> may provide other messaging platforms as options, such as but not limited to, an instant messaging application (e.g., standalone, or as part of a social networking application), an email application, a text message application, and the like. The user interface <NUM> further includes a cancel element <NUM> which provides for returning to selection of files as shown in <FIG>.

Referring to <FIG>, the electronic device <NUM> receives user input to send the group of files (<NUM>) based on the user selection of the share element <NUM>. In response, the electronic device <NUM> transmits the request to the server <NUM> (<NUM>), and the server <NUM> receives the request from the electronic device <NUM> (<NUM>).

In response to the server <NUM> receiving the request, the cloud-based service <NUM> of the server <NUM> creates a shared storage area in the shared storage area database <NUM> (<NUM>). The shared storage area corresponds to the group of files for sharing with the participants in the active message thread. In one or more implementations, the shared storage area is provisioned separately from other shared storage areas (e.g., corresponding to other respective shared groups of files) stored within the shared storage area database <NUM>. The cloud-based service <NUM> may create the shared storage area in association with the user account of the user of the electronic device <NUM>, so that the user has ownership rights to the shared storage area.

In one or more implementations, if the group of files being shared are not already stored on the server, the electronic device <NUM> may provide the group of files to the server <NUM> for storage. The server <NUM> may prioritize such storage of the group of files. Otherwise, if the files are already stored on the server <NUM>, the cloud-based service <NUM> may store references to the stored group of files in the shared storage area database <NUM>.

In this regard, as the user who selected the files and initiated creating the group of files (e.g., the owning user), he/she may have ownership rights to not only access, but to also modify or delete files within the shared storage area. On the other hand, the receiving participants may access a shared group of files, but may not have the rights to modify or delete files within the shared storage area.

In one or more implementations, in a case where the owning user deletes a file (e.g., an image), the cloud-based service <NUM> may set a flag which marks the file as deleted, rather than deleting the file as stored in the content database <NUM>. In this manner, references to the stored file may be maintained, but access to the file (e.g., by the shared storage area database <NUM>) may be prohibited based on the set flag.

Based on the newly-created shared storage area, the cloud-based service <NUM> transmits information for accessing the shared storage area to the electronic device <NUM> (<NUM>), and the electronic device <NUM> receives the information (<NUM>). In one or more implementations, the information for accessing the at least one file associated with the shared storage area comprises a network identifier such as a Uniform Resource Locator (URL). Although the following description refers to using a URL, a different network identifier such as a Uniform Resource Identifier (URI), may also be used.

As noted above, the files stored in the content database <NUM> may be individually referenced. As such, the URL may reference the shared storage area, which in turn references the individual files as stored in the content database <NUM>. In this manner, duplicate copies of the files are not required.

The URL may be transmitted with a hash string which can be decrypted to provide information (e.g., contextual information) for the group of files stored in the content database <NUM>. For each shared storage area, the shared storage area database <NUM> may store contextual information such as a main file, a title, a number of files, a timeframe, and/or location data for the group of files. This contextual data may be obtained from metadata of one or more files in the group, and may be stored in the respective shared storage area for the group of files.

In one or more implementations, the main file is a file (e.g., an image) within the group of files that is selected (e.g., by the cloud-based service <NUM>) to represent the group of files. Selection of the main file may be based on one or more of file metadata (e.g., time, place, tagging of people, places or things) and analysis techniques for recognizing people, places or things appearing in an image, and automatically selecting a representative file that matches a category (e.g., time, place, people) relevant to the group of files. In one or more implementations, a thumbnail of the main file may be provided instead of the entire main file.

In addition, the contextual information may indicate a current availability for accessing the files. For example, the availability may indicate when all files have not yet been uploaded from local memory <NUM> of the electronic device <NUM> to the content database <NUM> (e.g., in association with a cloud-based library).

Thus, following receipt of the information for accessing the shared storage area (<NUM>), the electronic device <NUM> generates a message to access the group of files, for sending to the electronic device <NUM> (<NUM>). In one or more implementations, the electronic device <NUM> may present a preview of the generated message for sending to the electronic device <NUM>. For example, the preview may be represented as a single message bubble which includes the above-described contextual information representing the group of files. In one or more implementations, the preview may be displayed as part of a message compose box, with a user-selectable interface for sending the message. In one or more implementations, the message may be automatically transmitted without providing a message preview.

Upon user selection of the interface for sending the message, the electronic device <NUM> transmits the message to the electronic device <NUM> (<NUM>), and the electronic device <NUM> receives the message (<NUM>). The electronic device <NUM> displays the message, which may include an interface option to accept access to the group of files (<NUM>), such as by clicking on the message bubble.

The processing of the message by the electronic device <NUM> may vary depending on whether or not the electronic device <NUM> is associated with a registered user account that is logged in. As noted above, the URL may be transmitted with a hash string which can be decrypted to provide contextual information (e.g., an enriched user interface) for the logged-in electronic device <NUM>. In one or more implementations, the hash string comprises a routing key and a byte array (e.g., a <NUM>-byte array). In a case where the electronic device <NUM> is associated with a user account that is logged in, the electronic device <NUM> decrypts the byte array of the hash string with the routing key, in order to generate a protected full token. The cloud-based service <NUM> decrypts the protected full token to obtain a public sharing key, which is returned to the electronic device <NUM>. The public sharing key may be used by the logged-in electronic device <NUM> as a key to access the respective shared storage area (e.g., as stored in the shared storage area database <NUM>). As noted above, the shared storage area may reference file content from the content database <NUM>. For example, the shared storage area may access a root record and the children of the root record corresponding to the group of files as stored on the content database <NUM>.

In addition, the logged-in electronic device <NUM> is able to access the above-mentioned contextual information for the respective shared storage area, as provided by the shared storage area database <NUM>. As noted above, the contextual information may include a main file, a title, a number of files, a timeframe and/or location data, and file availability for the group of files. Thus, the electronic device <NUM> may query the cloud-based service <NUM> with the public sharing key, to obtain the contextual information from the shared storage area database <NUM>. The electronic device <NUM> may display the contextual information within a single message element within the active message thread. In one or more implementations, the contextual information is presented within the active message thread, without requiring the user of the electronic device <NUM> to accept access to the group of files.

Upon receipt of the user input accepting access to the group of files (<NUM>), the electronic device <NUM> accesses the group of files (<NUM>). For example, the electronic device may query the server <NUM> for the files based on the information (e.g., the URL) provided with the message received from the first electronic device <NUM>. In one or more implementations access to the group of files may be provided with a message bubble. As noted above, the message bubble may correspond to an extension file management application. Thus, for the logged-in electronic device <NUM>, the message bubble may provide for accessing the files within the messaging application (e.g., in a full screen mode, or a partial screen mode). Sample user interfaces for accessing the group file content are described further below with respect to <FIG>.

In response to receiving the single message element representing the group of files, the logged-in electronic device <NUM> may provide for the user to reply, select and send additional files for sharing with the participant(s) in the active message thread. In one or more implementations, the extension file management application within the messaging application may provide suggestions, from the respective cloud-based library of the recipient user of the electronic device <NUM>. For example, the suggested files may be determined from matching metadata associated with the shared storage area with metadata of the recipient user's own files (e.g., by time, place, tagging, and the like), for example, as stored in the recipient user's cloud-based library (e.g., for storing images, videos and/or documents) in association with the content database <NUM>. In response, the user of the electronic device <NUM> may proceed with the process of selecting and sending a group of files to others (e.g., similar to the steps <NUM>, <NUM> and <NUM> performed by the electronic device <NUM>).

If the user of the electronic device <NUM> proceeds with selecting additional files and transmits a corresponding request to the server <NUM>, the cloud-based service <NUM> may create a new and separate shared storage area in the shared storage area database <NUM>, for accessing both the original group of files (e.g., from the original shared storage area) and the added files. The cloud-based service <NUM> may provide new information, corresponding to the new shared storage area, for accessing the aggregated group of files. As noted above, the shared storage area database <NUM> maintains references to individual files and/or groups of files stored within the content database <NUM>. As such, the cloud-based service <NUM> may configure the new and separate storage area to re-reference the original files, and newly reference the added files as stored in the content database <NUM> (e.g., in association with the recipient user's cloud-based library). In this manner, creating duplicate copies of the original files either remotely or locally may be avoided or reduced.

In one or more implementations, the logged-in electronic device <NUM> may provide for the recipient user to forward the single message element representing the group of files in a separate message thread. In this regard, the electronic device receiving the forwarded message (e.g., the electronic device <NUM> receives the message from the electronic device <NUM>) may access the corresponding shared storage area. In addition, the logged-in electronic device <NUM> may provide the user to select and send additional files for forwarding along with the original files. In this regard, the new separate storage area may re-reference the original files, and/or newly reference the added files as stored in the content database <NUM>.

In a case where the electronic device <NUM> is not associated with a registered user account or is not logged-in to a registered user account, a URL with the hash string is still provided to the electronic device <NUM> (hereinafter the "anonymous" electronic device <NUM>). In one or more implementations, the URL and the hash string for the anonymous electronic device <NUM> and the logged-in electronic device <NUM> are the same. However, the URL and the hash string may be different for the anonymous electronic device <NUM> and the logged-in electronic device <NUM>.

In the case of the anonymous electronic device <NUM>, the user of the anonymous electronic device <NUM> may not able to access the contextual information from the shared storage area as provided by the shared storage area database <NUM>. In addition, the anonymous electronic device <NUM> may not access the group of files within an extension application of the messaging application. Further, the anonymous electronic device <NUM> may not be provided with the ability to reply and select additional files for sharing in association with the shared storage area, or the ability to provide automatic suggestion for such additional files.

In one or more implementations, the anonymous electronic device <NUM> presents a message element within the active message thread, where the message element includes a clickable URL for accessing the group of files. The user of the electronic device <NUM> may click on the URL within the message thread to accept access to the group of files (<NUM>), thereby launching a browser application on the electronic device <NUM> to access the website specified by the URL. The group of files may be displayed as individual thumbnails, provided by the website, within the web browser (<NUM>).

To view the files, the website specified by the URL is configured to access a predefined web service corresponding to the cloud-based service <NUM>. The predefined web service resolves the hash string (e.g., by decrypting the byte array of the hash string with the routing key) in order to generate a server-encrypted blob. The blob contains key information for accessing the data (e.g., files) in the shared storage area. As such, the blob may function as a token for accessing the shared storage area from the shared storage area database <NUM>. The blob is also provided with a time-to-live (TTL) value.

The web server sends the blob, together with the TTL value, to the cloud-based service <NUM>. In one or more implementations, the cloud-based service <NUM> may store a flag value for permitting access by anonymous electronic devices, where the flag must be set in order to provide such access. Thus, upon determining that the flag for anonymous access is set and the TTL value has not expired, the cloud-based service <NUM> facilitates the electronic device <NUM> in accessing the shared storage area, based on the key information of the blob. The electronic device <NUM> may therefore access the shared storage area, without requiring the user to be logged into the cloud-based service <NUM>. In a case where the anonymous access flag is set but the TTL value has expired, the web browser on electronic device <NUM> is required to resend the URL to the predefined web server, to again generate the blob with a new TTL value.

In one or more implementations, the web server and/or the cloud-based service <NUM> may maintain a count of the number of times that the shared storage area has been accessed (e.g., by counting the number of times that the hash string has been resolved). In addition to maintaining this count, the cloud-based service <NUM> may store timestamp information for each access.

With the count and timestamp information, it is possible for the cloud-based service <NUM> to throttle subsequent access to the respective shared storage area stored in the shared storage area database <NUM>. For example, if a threshold number of accesses is met based on the count and timestamps over a certain time period, the cloud-based service <NUM> may reduce or otherwise prohibit subsequent access to the shared storage area database <NUM>, until a predefined time has passed. In one or more implementations, the throttling may be based on additional or alternative parameters including, but not limited to: the number of prior URLs provided by a particular user (e.g., where throttling is performed based on meeting a threshold number of URLs) and/or a known popularity of a particular group of files or user associated with a group of files (e.g., where throttling is performed based on meeting a threshold number of anticipated or actual accesses).

As noted above, the content and/or user experience for a logged-in user may differ from that of an anonymous user. <FIG> illustrate examples of content and user interfaces that relate to the experience of a logged-in user.

<FIG> illustrates an example of a logged-in user being provided with contextual information as part of the initial message bubble, which provides the user with an option to access the group of files. The user interface <NUM> for a group of files is represented as a single messaging element <NUM>. In the example of <FIG>, the single messaging element <NUM> includes contextual information of the time (e.g., December <NUM>), place (Santa Rita Elementary), number of image files (e.g., <NUM>) and a main file representative of the group of files. The user interface <NUM> further includes a URL element <NUM>. User selection of the single messaging element <NUM> or the URL element <NUM> may provide the user with access to the shared storage area, as described above.

<FIG> illustrates an example user interface <NUM>, provided by a messaging application on the electronic device <NUM>, which provides a user with different options for accessing a received group of files in accordance with one or more implementations. For example, if the group of files (e.g., images, videos and/or documents) for sharing has already been uploaded to the sending user's cloud-based library, and if the recipient user wishes to add those files to his/her cloud-based library as provided by the cloud-based service <NUM>, the user may select element <NUM>. By selecting add element <NUM>, the cloud-based service <NUM> may create references, within the user cloud-based library, to each of the files in the group of files referenced by the shared storage area database <NUM> and stored in the content database <NUM>. In this manner, it is not necessary for the cloud-based service <NUM> to generate additional copies of the files. <FIG> illustrates an example user interface <NUM> which provides for adding the files to the cloud-based library. User interface <NUM> provides an file selection element <NUM> for selecting individual files from the group of files, as well as an element <NUM> to add all files from the group of files to the recipient's cloud-based library as provided by the cloud-based service <NUM>.

On the other hand, the user may select download element <NUM> from user interface <NUM>, which provides for the group of files to be downloaded and locally stored on the memory <NUM> of the electronic device <NUM>. <FIG> illustrates an example user interface <NUM> which provides for the user to locally download and access the group of files on the electronic device <NUM>. User interface <NUM> provides an file selection element <NUM> for selecting individual files from group, as well as an element <NUM> to download all files from the group of files to the memory <NUM> of the electronic device <NUM>.

<FIG> illustrate examples of contextual information related to the availability of files, in a case where all files have not yet been uploaded from the electronic device <NUM> to the content database <NUM>. In <FIG>, example user interface <NUM> illustrates that a group of files has been shared but is not yet available for access. For example, message element <NUM> may be provided within the active message thread of the receiving electronic device <NUM>, to indicate that files have been shared but are not yet available for access (e.g., because they have not yet been uploaded to the sending user's cloud-based library).

In addition, <FIG> illustrates an example user interface <NUM> indicating that a group of files has been shared and is partially available for access. For example, user interface <NUM> may be provided within the messaging application (e.g., either in a full screen or within the active message thread), to indicate that a partial group of files that can be accessed. The files can be selected using file selection element <NUM>, and download element <NUM> (e.g., for local download to the electronic device <NUM>). Alternatively or in addition, an "add to library" option may be provided for adding the selected files to the recipient user's cloud-based library (e.g., by re-referencing the files as referenced by original shared storage area).

In one or more implementations, the electronic device <NUM> may include an interface for managing a respective user's different groups of shared storage areas. As noted above, a separate shared storage may be created with respect to different active message threads and/or with respect to a receiving user adding files to an existing shared storage area. <FIG> illustrates an example user interface <NUM> for navigating between the different shared storage areas associated with respective groups of files. In one or more implementations, the user interface <NUM> may be invoked within an file management application running on the electronic device <NUM>. The user interface <NUM> may include interface elements <NUM> and <NUM> for switching between the user's cloud-based library (e.g., corresponding to interface element <NUM>) and/or the user's shared storage areas (e.g., corresponding to interface element <NUM>). Thus, if the user selects interface element <NUM>, the user may access shared storage areas that he/she created (e.g., via share selection element <NUM>). In addition, the user may access shared storage areas that were created by others and that the user accepted access to (e.g., via share selection element <NUM>). As noted above, the user may modify his/her own shares, but not those of others.

<FIG> illustrates a flow diagram of an example process by a sending device (e.g., the electronic device <NUM>) for sharing content in a messaging application in accordance with one or more implementations. For explanatory purposes, the process <NUM> is primarily described herein with reference to the electronic devices <NUM>, <NUM> and the server <NUM> of <FIG>. However, the process <NUM> is not limited to the electronic devices <NUM>, <NUM> and the server <NUM> of <FIG>. For example, the process <NUM> may apply to communication between any combination of two or more of the electronic devices <NUM>-<NUM> via the server <NUM>. Moreover, one or more blocks (or operations) of the process <NUM> may be performed by one or more other components of the server <NUM> and/or by other suitable devices. Further for explanatory purposes, the blocks of the process <NUM> are described herein as occurring in serial, or linearly. However, multiple blocks of the process <NUM> may occur in parallel. In addition, the blocks of the process <NUM> need not be performed in the order shown and/or one or more blocks of the process <NUM> need not be performed and/or can be replaced by other operations.

The electronic device <NUM> provides, within a messaging application, a user interface element for sending at least one file to a participant (e.g., a user of electronic device <NUM>) in an active message thread of the messaging application, the at least one file having been determined to be relevant to the participant (<NUM>). For example, the at least one file may be determined to be relevant to the participant based on at least one of facial recognition, a time, or a place associated with the participant and the file, and/or based on a selection of the participant by the user of the electronic device <NUM>.

The user interface element may be provided in multiple ways. For example, the user interface element may be provided in response to user input invoking a file management application provided by the messaging application. Alternatively or in addition, the electronic device <NUM> may determine that a portion of text within the active message thread of the messaging application corresponds to the at least one file, and provide for differentiated display of the portion of text. The user interface element may be provided in response to receiving user input selecting the differentiated display of the portion of text.

Alternatively or in addition, the electronic device <NUM> may determine that a portion of text within a message input interface of the messaging application corresponds to the at least one file, and provide for differentiated display of the portion of text. The user interface element is provided in response to receiving user input selecting the differentiated display of the portion of text.

In response to receiving a selection of the user interface element, the electronic device <NUM> transmits, to the server <NUM>, a request to store the at least one file in association with a shared storage area (<NUM>). The electronic device <NUM> transmits, via the messaging application, a message to the participant (e.g., to the electronic device <NUM>) in the active message thread, the message comprising information for accessing the at least one file associated with the shared storage area (<NUM>). The at least one file may include a group of files, and the group of files may be represented as a single message element within the active message thread.

The information for accessing the at least one file associated with the shared storage area may be a Uniform Resource Locator (URL). The URL may reference the shared storage area for access of the at least one file. The URL may be transmitted with a hash string for accessing contextual information of the least one file from the shared storage area. The contextual information may be configured for display in the active message thread.

<FIG> illustrates a flow diagram of another example process by a server (e.g., the server <NUM>) for sharing content in a messaging application in accordance with one or more implementations. For explanatory purposes, the process <NUM> is primarily described herein with reference to the electronic devices <NUM>, <NUM>, and the server <NUM> of <FIG>. However, the process <NUM> is not limited to the electronic devices <NUM>, <NUM>, and the server <NUM> of <FIG>. For example, the process <NUM> may apply to communication between any combination of two or more of the electronic devices <NUM>-<NUM> via the server <NUM>. Moreover, one or more blocks (or operations) of the process <NUM> may be performed by one or more other components of the server <NUM> and/or by other suitable devices. Further for explanatory purposes, the blocks of the process <NUM> are described herein as occurring in serial, or linearly. However, multiple blocks of the process <NUM> may occur in parallel. In addition, the blocks of the process <NUM> need not be performed in the order shown and/or one or more blocks of the process <NUM> need not be performed and/or can be replaced by other operations.

The server <NUM> receives, from the electronic device <NUM>, a request for creating a shared storage area for sharing at least one file with the electronic device <NUM> (<NUM>). The at least one file is determined to be relevant to a user of the electronic device <NUM>. The electronic devices <NUM> and <NUM> are participating in an active message thread of a messaging application.

The server <NUM> creates, in response to receiving the request, the shared storage area in association with the at least one file (<NUM>). The server <NUM> transmits, to the electronic device <NUM>, information for accessing the at least one file associated with the shared storage area (<NUM>).

The electronic device <NUM> may be configured to send a message to the electronic device <NUM>, the message including the information for accessing the at least one file associated with the shared storage area. The server <NUM> may receive, from the second device, a request to access the at least one file associated with the shared storage area. The server <NUM> may provide, in response to receiving the request from the second device, the at least one file associated with the shared storage area to the second device.

The information for accessing the at least one file associated with the shared storage area may be a Uniform Resource Locator (URL). The URL may reference the shared storage area for access of the at least one file.

The URL may be transmitted with a hash string for accessing contextual information of the least one file from the shared storage area. For example, the contextual information may be configured for display in the active message thread on the electronic device <NUM>.

<FIG> illustrates a flow diagram of another example process by a receiving device (e.g., the electronic device <NUM>) for sharing content in a messaging application in accordance with one or more implementations. For explanatory purposes, the process <NUM> is primarily described herein with reference to the electronic device <NUM> and the server <NUM> of <FIG>. However, the process <NUM> is not limited to the electronic device <NUM> and the server <NUM> of <FIG>. For example, the process <NUM> may apply to communication between any combination of two or more of the electronic devices <NUM>-<NUM> via the server <NUM>. Moreover, one or more blocks (or operations) of the process <NUM> may be performed by one or more other components of the server <NUM> and/or by other suitable devices. Further for explanatory purposes, the blocks of the process <NUM> are described herein as occurring in serial, or linearly. However, multiple blocks of the process <NUM> may occur in parallel. In addition, the blocks of the process <NUM> need not be performed in the order shown and/or one or more blocks of the process <NUM> need not be performed and/or can be replaced by other operations.

The electronic device <NUM> receives (e.g., from the server <NUM>) a message comprising a network identifier (e.g., a URI or a URL) for accessing at least one file associated with a shared storage area (<NUM>). The network identifier may include a parameter (e.g., a hash string) for accessing contextual information of the least one file from the shared storage area, the at least one file having been determined to be relevant to a user of the electronic device <NUM>.

The electronic device <NUM> displays a message element within an active message thread of a messaging application (<NUM>). The message element provides an interface for the user to accept access to the at least one file. The electronic device <NUM> receives, via the interface, user input indicating that the user has accepted access to the at least one file (<NUM>). The electronic device <NUM> obtains, in response to receiving the user input and based on the network identifier, the at least one file associated with the shared storage area (<NUM>).

The electronic device <NUM> provides the at least one file for display on the device (<NUM>). The shared storage area may correspond to a cloud-based service having multiple user accounts associated therewith.

In a case where the user has a user account on the cloud-based service and is logged into the user account with the device, the electronic device <NUM> may obtain the contextual information of the least one file from the shared storage area, and display the contextual information in the message element of the active message thread. Further, the electronic device <NUM> may display the at least one file in the message element of the active message thread, by referencing the at least one file based on the network identifier. In a case where the user does not have a user account on the cloud-based service or is not logged into the user account with the device, the electronic device <NUM> may direct to a webpage corresponding to the network identifier via a web browser.

As described above, one aspect of the present technology is the gathering and use of data available from various sources to improve the delivery to users of invitational content or any other content that may be of interest to them. The present disclosure contemplates that in some instances, this gathered data may include personal information data that uniquely identifies or can be used to contact or locate a specific person. Such personal information data can include demographic data, location-based data, telephone numbers, email addresses, twitter ID's, home addresses, data or records relating to a user's health or level of fitness (e.g., vital signs measurements, medication information, exercise information), date of birth, or any other identifying or personal information.

The present disclosure recognizes that the use of such personal information data, in the present technology, can be used to the benefit of users. For example, the personal information data can be used to deliver targeted content that is of greater interest to the user. Accordingly, use of such personal information data enables users to calculated control of the delivered content. Further, other uses for personal information data that benefit the user are also contemplated by the present disclosure. For instance, health and fitness data may be used to provide insights into a user's general wellness, or may be used as positive feedback to individuals using technology to pursue wellness goals.

Despite the foregoing, the present disclosure also contemplates embodiments in which users selectively block the use of, or access to, personal information data. That is, the present disclosure contemplates that hardware and/or software elements can be provided to prevent or block access to such personal information data. For example, in the case of advertisement delivery services, the present technology can be configured to allow users to select to "opt in" or "opt out" of participation in the collection of personal information data during registration for services or anytime thereafter. In another example, users can select not to provide mood-associated data for targeted content delivery services. In yet another example, users can select to limit the length of time mood-associated data is maintained or entirely prohibit the development of a baseline mood profile. In addition to providing "opt in" and "opt out" options, the present disclosure contemplates providing notifications relating to the access or use of personal information. For instance, a user may be notified upon downloading an app that their personal information data will be accessed and then reminded again just before personal information data is accessed by the app.

For example, content can be selected and delivered to users by inferring preferences based on non-personal information data or a bare minimum amount of personal information, such as the content being requested by the device associated with a user, other non-personal information available to the content delivery services, or publicly available information.

<FIG> illustrates an electronic system <NUM> with which one or more implementations of the subject technology may be implemented. The electronic system <NUM> can be, and/or can be a part of, one or more of the electronic devices <NUM>-<NUM>, and/or one or the server <NUM> shown in <FIG>. The electronic system <NUM> may include various types of computer readable media and interfaces for various other types of computer readable media. The electronic system <NUM> includes a bus <NUM>, one or more processing unit(s) <NUM>, a system memory <NUM> (and/or buffer), a ROM <NUM>, a permanent storage device <NUM>, an input device interface <NUM>, an output device interface <NUM>, and one or more network interfaces <NUM>, or subsets and variations thereof.

The output device interface <NUM> may enable, for example, the display of files generated by electronic system <NUM>.

Finally, as shown in <FIG>, the bus <NUM> also couples the electronic system <NUM> to one or more networks and/or to one or more network nodes, such as the server <NUM> shown in <FIG>, through the one or more network interface(s) <NUM>. In this manner, the electronic system <NUM> can be a part of a network of computers (such as a LAN, a wide area network ("WAN"), or an Intranet, or a network of networks, such as the Internet. Any or all components of the electronic system <NUM> can be used in conjunction with the subject disclosure.

It is understood that any specific order or hierarchy of blocks in the processes disclosed is an illustration of example approaches. Based upon design preferences, it is understood that the specific order or hierarchy of blocks in the processes may be rearranged, or that all illustrated blocks be performed. Any of the blocks may be performed simultaneously. In one or more implementations, multitasking and parallel processing may be advantageous.

Claim 1:
A method (<NUM>), comprising:
receiving (<NUM>), by a device (<NUM>) of a user, a message comprising a network identifier for accessing at least one file associated with a shared storage area, the network identifier comprising a parameter for accessing contextual information of the least one file from the shared storage area, the at least one file having been determined to be relevant to the user;
displaying (<NUM>), by the device, a message element within an active message thread of a messaging application, the message element providing an interface for the user to accept access to the at least one file;
receiving (<NUM>), via the interface, user input indicating that the user has accepted access to the at least one file;
obtaining (<NUM>), in response to receiving the user input and based on the network identifier, the at least one file associated with the shared storage area; and
providing (<NUM>) the at least one file for display on the device (<NUM>),
wherein the at least one file comprises a group of files, the group of files is represented as the message element within the active message thread, the message element comprises a single message bubble that includes the contextual information, the contextual information comprises a representation of a main file of the group of files, and the contextual information indicates a current availability for accessing the group of files from the shared storage area.