Patent Description:
Smartphones, social networks, and telecommunication systems facilitate the sharing of comments, photographs, and other data amongst mobile users. These users typically establish accounts for smartphone data storage, application downloads and social networks, create profiles containing basic biographic data, and create individual contact lists to share personal data and communicate with. The subject matter of comments posted on social networking sites oftentimes touch upon daily life experiences, including those relating to user status, commentary, and photographs. Today over <NUM>% of all social posts occur on mobile smartphone devices. Accordingly, the viewing and sharing of user-generated content on smartphones to social networking sites from smartphones provides users a valuable and entertaining experience.

Various social network systems offering mobile applications for smartphone users to post are known in the art, including Facebook, LinkedIn, Twitter, Instagram, and so forth. Unfortunately, however, the logic of these systems, in order to take action and provide user posts in the form of status, commentary, and photographs, are designed specifically for use and display within the respective social networks and do not contemplate usage for real-time native smartphone telephony interactions.

Another problem that besets social network applications in providing user posts in the form of status, commentary, and photographs is that social networks do not have the logic or know-how to mix user posts and selected user personal data with smartphone telephony interactions and match it with user selected individuals of smartphone devices and user initiated telephony interactions. As a result, extending social user post capabilities to smartphone telephony interactions has yet to be made available.

Accordingly, there is a need in the art to connect user social post capabilities in the form of status, commentary, photographs, and other directed content with smartphone user contact records and subsequent smartphone telephony interactions so that users can share various status types such as status, commentary, photographs, and other content with their contacts, affiliated groups and/or desired recipients or any combination of people at the onset of a smartphone telephony or other visual telephony interaction via a phone line, cell tower, or the internet based on system and user defined parameters.

In addition, there is a need in the art to extend current social post and profile capabilities to be more personalized/individualized and dynamic so that users can share specific content and specific profile pictures with individual contacts, groups and/or desired recipients of any combination of people within their respective social networks.

Some of these drawbacks are addressed by the system described in <CIT>, entitled "SYSTEM FOR BRIDGING, MANAGING, AND PRESENTING SMARTPHONE AND OTHER DATA FILES WITH TELEPHONY INTERACTIONS,".

However, additional functionality for enhancing social and telephony interactions is desirable, as well as functionality for enhancing non-social communications between consumers and businesses, municipalities, or other service providers. Prior art examples of this additional functionality can be found in <CIT> and in <CIT>.

The present disclosure contemplates various systems, methods, and apparatuses for overcoming the above drawbacks accompanying the related art. One aspect of the invention is a non-transitory program storage medium on which are stored instructions executable by a processor or programmable circuit to perform operations for enhancing data sharing between computing device users, such as claimed in the appended claim <NUM>.

Either one or both of the first computing device and the second computing device may be a mobile device.

Another aspect of the invention is a system including the above non-transitory program storage media, a server for executing the instructions, the first computing device, and the second computing such as claimed in appended claim <NUM>.

Further optional advantageous aspects of the invention are included in the appended dependent claims. All the embodiments included in the description below represent useful examples for highlighting specific aspects of the invention and its potential implementations.

These and other features and advantages of the various embodiments disclosed herein will be better understood with respect to the following description and drawings, in which like numbers refer to like parts throughout, and in which:.

The present disclosure encompasses various embodiments of systems, methods, and apparatuses for enhancing data sharing between mobile or other computing device users. The detailed description set forth below in connection with the appended drawings is intended as a description of several currently contemplated embodiments and is not intended to represent the only form in which the disclosed invention may be developed or utilized. The description sets forth the functions and features in connection with the illustrated embodiments. It is to be understood, however, that the same or equivalent functions may be accomplished by different embodiments that are also intended to be encompassed within the scope of the present disclosure. It is further understood that the use of relational terms such as first and second and the like are used solely to distinguish one from another entity without necessarily requiring or implying any actual such relationship or order between such entities.

With reference to the block diagram of <FIG>, there is a system <NUM> that connects and displays selected user personal smartphone data with smartphone telephony interactions. In accordance with embodiments of the present disclosure, the communications system <NUM> is contemplated to bridge smartphone or otherwise stored personal data, smartphone telephony interactions and social networks. The system <NUM> includes smartphone user access point and data proxy <NUM>, which are connected to various smartphone user interfaces and data <NUM>-<NUM>. By way of example, there is a user A interface and data <NUM> that is connected to the user access point and data proxy <NUM> over a connection <NUM>, a user B interface and data <NUM> that is connected to the user access point and data proxy <NUM> over a connection <NUM>, and a user C interface and data <NUM> that is connected to the user access point and data proxy <NUM> over a connection <NUM>. These three user interface and data are presented by way of example only, and any additional number of user interfaces and data may be connectible to the user data access point and data proxy <NUM>, e.g., user N interface and data <NUM>. The aforementioned data is understood to be that which is stored on the respective smartphones, or other stored personal data over carrier networks or social networks.

There may also be an enterprise data access point <NUM> connected to second data links <NUM>, <NUM> to access additional system users. These include a smartphone <NUM> for a user A, which includes a smartphone interface <NUM> and a smartphone data <NUM> that is accessed by the interface via a data interlink <NUM>. Furthermore, by way of example, there may be another smartphone <NUM> for a user B, which includes a smartphone interface <NUM> and a smartphone data <NUM> that is accessed via a data interlink <NUM>.

As shown in <FIG>, the system <NUM> includes an application server <NUM> that is connected to the incoming data access point, i.e., the smartphone user data access point and data proxy <NUM> as well as the enterprise data access point <NUM>. The post data and routing information requests may be segregated based at least on configurable routing and storage instructions. The system may further include a component database <NUM> that is utilized by the application server <NUM> over an interlink <NUM>. Additionally, there may be a rules-based engine <NUM>, as well as integrations to APIs from other sources for automated categorization, routing, and storage. The rules engine <NUM> may be connected to the application server over an interlink <NUM>. Additionally, the application server <NUM> is connected to the enterprise data access point <NUM> over an interlink <NUM>, and the smartphone user data access point and data proxy <NUM> is connected to the application server <NUM> over an interlink <NUM>.

The block diagram of <FIG> depicts the system <NUM> on a more generalized level. As indicated above, the system <NUM> stores the aforementioned images, videos, and other content <NUM> that is uploaded from the respective mobile devices and stored thereon for subsequent transmission. As referenced herein, content <NUM> may be the exemplary images that are depicted herein, but are not intended to be limited to multimedia and other like materials. Other data, such as scheduling requests, call requests, customer service requests, and so forth are intended to be encompassed within the term content. Those skilled in the art will recognize that the specific examples shown and described herein in connection with images, are also applicable to such other content, and the various features of the present disclosure are adaptable thereto. The mobile devices each execute a mobile application <NUM>, with a first mobile device running a mobile application 1100a and a second mobile device running a mobile application 1100b.

<FIG> shows a user interface <NUM> of a mobile application <NUM> running on one of the various mobile devices (e.g. smartphones) that connects to the system <NUM>. The example of <FIG> shows the user interface <NUM> at three consecutive stages during a user's creation of a submission request for sending data from the mobile device to another mobile device via the system <NUM>. The user's (i.e. the sender's) experience may begin at a contacts screen <NUM> of the user interface <NUM> as shown in the left-most screenshot of <FIG>. The contacts screen <NUM> shows a list of the sender's contacts (e.g. in alphabetical order), which may, for example, be imported from an address book of the mobile device. Each item <NUM> of the list of contacts may include a name <NUM> of the contact, a thumbnail image or avatar <NUM> representing the contact, a phone button <NUM> for initiating a phone call with the contact, and a flash button <NUM> for creating a submission request. The flash button <NUM> may only be available for contacts who have the mobile application <NUM> installed on their phone and are thus registered with the provider of the mobile application <NUM>. In the case of contacts who do not have the mobile application <NUM> (e.g. "Alex Fer" and "Cristo"), the flash button <NUM> may be replaced by an "Invite" button by which the user of the user interface <NUM> may autogenerate an invitation message (e.g. text message, email, etc.) addressed to the contact with a link to download the mobile application <NUM>. As shown, in the case of some contacts who have the mobile application <NUM> (e.g. "Ana Smith" and "Bean Jessi. "), the flash button <NUM> may be replaced by a thumbnail image of the most recent image sent to that contact using the mobile application <NUM>. The contacts screen <NUM> may include tabs (e.g. "ALL," "FLASH," "FAVORITES") for filtering the list of contacts, for example, to show all contacts, only those contacts who have the mobile application <NUM>, and user-designated contacts, respectively. Functionality for searching the list of contacts (e.g. magnifying glass icon) and navigating to a camera application (e.g. camera icon) may also be included on the contacts screen <NUM>, as well as navigation tools for navigating from the contacts screen <NUM> to other screens of the mobile application <NUM> (e.g. "Contacts," "Groups," "Photos").

When the sender taps the flash button <NUM> (or thumbnail image of most recent image replacing the flash button <NUM>) associated with a contact to whom the sender would like to send an image, the user interface <NUM> may navigate to an image selection screen <NUM> as shown in the center screenshot of <FIG>. Here, the sender may select an image <NUM> from a set of available images <NUM> stored locally on the mobile device. The set of images <NUM> may, for example, be imported from a photo library on the mobile device and may be displayed as a grid of thumbnail images <NUM>, as shown. As the sender taps each image <NUM>, the image <NUM> may be marked (e.g. with a colored border) to show that it is the currently selected image <NUM>. A large view 1220a of the currently selected image <NUM> may be displayed, as shown. When the sender is satisfied with the selected image <NUM>, the sender may tap the hidden flash button <NUM> to proceed with creating the submission request.

In response to the sender's tapping of the hidden flash button <NUM>, the user interface <NUM> may navigate to a time period selection screen <NUM> (e.g. a popup window) as shown in the right-most screenshot of <FIG>. The time period selection screen <NUM> may include a selection tool <NUM> (e.g. radio buttons, input field, etc.) for allowing the sender to select a period of time for the selected image <NUM> to be available for viewing by the recipient. When the sender is satisfied with the selected period of time (e.g. "<NUM>"), the submission request can be confirmed by tapping the "Yes" button or cancelled by tapping the "Cancel" button. Once confirmed, the completed submission request may be transmitted to the system <NUM> (e.g. over the Internet). The completed submission request may include the selected image <NUM> (e.g. an image file) together with associated submission data indicative of the selected recipient (i.e. the contact whose flash button <NUM> was used to initiate the submission request) and the selected period of time. As described in more detail below, the system <NUM> will then make the selected image <NUM> available for viewing by the recipient for the selected period of time, beginning from the time that the submission request was generated.

<FIG> shows the user interface <NUM> of the mobile application <NUM> running on one of the various mobile devices that connects to the system <NUM>. The example of <FIG> continues the sequence of screenshots begun in <FIG> with two further consecutive stages of the user interface <NUM> immediately following the user's creation of the submission request. In response to the user's confirmation of the time period and completion of the submission request as shown in the right-most screenshot of <FIG>, the user interface <NUM> may navigate to a confirmation screen <NUM> (e.g. a popup window) indicating that the submission request was completed successfully. For example, the confirmation screen <NUM> may confirm that the submission request was successfully uploaded to the system <NUM> (e.g. to the application server <NUM>) and may wait for the user's recognition of the confirmation, for example, by tapping an OK button <NUM> on the confirmation screen <NUM>. Thereafter, the user may be returned to the contacts screen <NUM> of the user interface <NUM>. As shown in the right-most screenshot of <FIG> (in comparison with the left-most screenshot of <FIG>), the contacts screen <NUM> may be updated to replace the flash button <NUM> associated with the recipient of the recent submission request ("Burnet Criti. ") with a thumbnail image 1218a of the image of the submission request. In this way, the thumbnail image 1218a may indicate the most recent image that was sent to that contact using the mobile application <NUM>.

<FIG> shows three consecutive screenshots of another one of the various mobile devices that connects to the system <NUM>, which in this example, is the mobile device of the recipient of the submission request. The example of <FIG> shows the mobile device at three consecutive stages during a user's receipt of a push notification <NUM> regarding the sender's submission request of <FIG> and <FIG>. The user's (i.e. the recipient's) experience may begin at a lock screen <NUM> of the mobile device as shown in the left-most screenshot of <FIG> or other screen (e.g. notification center) where push notifications <NUM> are displayed. Alternatively, the experience may begin as a popup overlaying any screen of the mobile device (e.g. the user may be in the middle of using an unrelated application). As shown, a push notification <NUM> corresponding to the sender's submission request is displayed. The push notification <NUM> may include the name ("Flash") and icon of the mobile application <NUM>, the time of day that the push notification <NUM> was received ("Now"), and the content of the push notification <NUM> ("Ana Smith Flashed a hidden image for <NUM>. Because the recipient can see that the push notification <NUM> was received "Now" (e.g. within the last minute), the recipient may know that about <NUM> minutes remain to view the hidden image that Ana Smith has sent. If the time that the push notification <NUM> was received was about <NUM> minutes ago, the recipient may know, for example, that about <NUM> minutes remain to view the hidden image. If the recipient would like to open the mobile application <NUM> and view the image, the recipient may swipe or otherwise interact with the push notification <NUM> according to the ordinary procedure for unlocking and navigating to an application on the mobile device according to the mobile device's operating system. It is contemplated that the content of the push notification <NUM> may depend on the amount of time remaining to view the hidden image. For example, when a certain amount of time or percent of the set time period remains to view the image (e.g. <NUM> minutes, <NUM>%, etc.), an additional push notification <NUM> may be sent saying, for example, "See the hidden Flashed image before it's gone. " When the time period has expired, another push notification <NUM> may be sent saying, for example, "The hidden image John Flashed expired without being viewed.

In response to the recipient's interacting with the push notification <NUM>, the mobile device may display an authentication prompt <NUM> prompting the recipient to use a fingerprint sensor of the mobile device for authentication, followed by an authentication success notification <NUM> after a successful authentication using the fingerprint sensor. In case the recipient prefers to authenticate by password, a "Use Password" button may be provided. A "Cancel" button may also be provided if the recipient no longer wishes to open the mobile application <NUM> and would rather return to the lock screen <NUM>.

<FIG> shows two further consecutive screenshots of the mobile device of the recipient of the submission request. The left-most screenshot of <FIG> is an example of a password prompt <NUM> and password entry tool <NUM> by which the recipient may enter a password for authentication following tapping of the "Use Password" button shown in <FIG>. After authentication of the recipient, either by fingerprint authentication or password authentication, the mobile application <NUM> may launch directly to a screen for viewing the image referred to in the push notification <NUM>, i.e. the "flashed" image that is available for a limited time for the recipient's viewing. An example of this is shown in the right-most screenshot of <FIG>, where the mobile application <NUM> has now been launched on the recipient's mobile device directly from the push notification <NUM>. The example shown in the right-most screen shot of <FIG> shows an image viewing screen <NUM> of the user interface <NUM>, including a view <NUM> of the flashed image and a timer <NUM> showing remaining time for viewing the flashed image. When the timer <NUM> expires, the mobile application <NUM> may automatically navigate to another screen of the user interface <NUM> (e.g. the contacts screen <NUM> of <FIG>). Alternatively, the image viewing screen <NUM> may still be displayed but with the view <NUM> of the flashed image removed so that it can no longer be viewed by the recipient. Along the same lines, while the flashed image is available for viewing, the mobile application <NUM> can make the image un-savable and screen-shot proof. For example, the mobile application <NUM> may inhibit the save or screenshot function of the mobile device's operating system or may display the image in a way that distorts still captures (e.g. by temporal dithering). It is also contemplated that the sender of the flashed image can be notified regarding the recipient's viewing, saving, or screenshotting the image. For example, the system <NUM> may send a push notification to the sender saying, for example, "John has seen the hidden image you Flashed" or "Ana Smith has screenshotted a photo you Flashed.

<FIG> shows an alternative sequence of screenshots by which the recipient of the submission request may view the flashed image. Instead of launching the mobile application <NUM> from a push notification <NUM>, the recipient may manually launch the mobile application <NUM> (e.g. by tapping on an icon for the mobile application <NUM> on a home screen of the mobile device). From within the mobile application <NUM>, the recipient may begin at a contacts screen <NUM> of the user interface <NUM> as shown in the first (upper-left) screenshot of <FIG>, which may be the same as the contacts screen <NUM> of <FIG>. By tapping a history button <NUM> associated with a particular contact ("Bean Jessi. ") listed as an item <NUM> of the list of contacts, the user may navigate to a history screen <NUM> of the user interface <NUM> as shown in the second (upper-right) screenshot of <FIG>. The history screen <NUM> may be associated with the particular contact whose history button <NUM> was tapped and may include one or more grids of thumbnail images <NUM> that the user (i.e. the recipient in this case) has sent to or received from that contact using the mobile application <NUM>. For example, a grid of thumbnail images <NUM> that the user has sent to that contact may be displayed when a "You Flashed" tab is selected, while a separate grid of thumbnail images <NUM> (not shown) that the user has received from that contact may be displayed when a "They Flashed" tab is selected.

It should be noted that the mobile application <NUM> may support two different kinds of image sharing, regular flashed images and hidden flashed images. Referring back to <FIG>, the image selection screen <NUM> of the user interface <NUM> may include, in addition to the hidden flash button <NUM>, a regular flash button <NUM> that allows the sender to send a selected image <NUM> without a time period for viewing. Referring again to <FIG>, the grids of thumbnail images <NUM> displayed under the "You Flashed" and "They Flashed" tabs of the history screen <NUM> may represent images sent as regular flashed images (e.g. using the regular flash button <NUM>). Thus, these thumbnail images <NUM> may remain available for viewing indefinitely and may be displayed without any timer <NUM>, but with time and date information indicating when the images were sent.

Wishing to view hidden flashed images, the user (i.e. recipient in this case) may tap a hidden flash history button <NUM> to navigate to a hidden flash history screen <NUM> of the user interface <NUM> as shown in the third or fifth screenshot (first or third screenshot of bottom row) of <FIG>. Just like the history screen <NUM>, the hidden flash history screen <NUM> may be associated with the particular contact whose history button <NUM> was tapped. When a "You Hidden Flashed" tab is selected as shown in the third screenshot of <FIG>, the hidden flash history screen <NUM> may display a grid of thumbnail images <NUM> that the user (i.e. the recipient in this case) has sent to the associated contact using the hidden flash functionality of the mobile application <NUM> (e.g. using the hidden flash button <NUM> shown in <FIG>). When a "They Hidden Flashed" tab is selected as shown in the fifth screenshot of <FIG>, the hidden flash history screen <NUM> may display a grid of thumbnail images <NUM> that the user has received as hidden flashed images from that contact using the hidden flash functionality of the mobile application <NUM>. As shown, each thumbnail image <NUM> under the "They Hidden Flashed" tab may include a timer <NUM> showing how much time remains to view the image before its time period for viewing expires. In contrast, each thumbnail image <NUM> under the "You Hidden Flashed" tab may remain on the hidden flash history screen <NUM> and be accessible for viewing indefinitely without expiring (though it is contemplated that such sent hidden images may also expire, depending on user preferences).

As shown in the sixth (bottom-right) screenshot of <FIG>, tapping the thumbnail image <NUM> under the "They Hidden Flashed" tab of the hidden flash history screen <NUM> may navigate the user interface <NUM> to the same image viewing screen <NUM> as shown in <FIG>, including a view <NUM> of the flashed image and a timer <NUM> showing remaining time for viewing the flashed image. When the timer <NUM> expires, the user interface <NUM> may automatically navigate to another screen (e.g. the hidden flash history screen <NUM>). Alternatively, the image viewing screen may still be displayed but with the view <NUM> of the flashed image removed. Similarly, as shown in the fourth screenshot of <FIG> (second screenshot of the bottom row), tapping the thumbnail image <NUM> under the "You Hidden Flashed" tab of the hidden flash history screen <NUM> may navigate the user interface <NUM> to a similar image viewing screen <NUM> for viewing the full-size image represented by the thumbnail <NUM>.

It is contemplated that the mobile application <NUM> may be configured to require user authentication when a user attempts to access the hidden flash history screen <NUM> by tapping the hidden flash history button <NUM>. Thus, when the user taps the hidden flash history button <NUM>, the mobile device may display an authentication prompt <NUM> and authentication success notification <NUM> as shown in <FIG> and/or a password prompt <NUM> and password entry tool <NUM> as shown in <FIG>. After authentication of the user, either by fingerprint authentication or password authentication, the mobile application <NUM> may proceed from the history screen <NUM> to the hidden flash history screen <NUM> as shown in <FIG>.

<FIG> shows an example operational flow according to an embodiment of the present disclosure in relation to the system <NUM> shown in <FIG> and <FIG> and the sequences of screenshots shown in <FIG>, <FIG>, <FIG>, <FIG>, and <FIG>. The operational flow of <FIG> may begin within the sender's mobile device, where the user selects a recipient and image (step <NUM>) as described in relation to the contacts screen <NUM> and image selection screen <NUM> of the user interface <NUM> as shown in <FIG>. The recipient may be selected, for example, by tapping the flash button <NUM> of the list item <NUM> associated with the contact who is the desired recipient, while the image may be selected by tapping the image <NUM> followed by the hidden flash button <NUM>. After selecting the recipient and image (though any order of selecting the recipient, image, and time period is contemplated), the operational flow may continue with the user's setting a time period (step <NUM>) as described in relation to the time period selection screen <NUM> of the user interface <NUM> as shown in <FIG>. The time period may be selected, for example, using radio buttons or other selection tool <NUM>. When the user is satisfied with the selected recipient, image, and time period, the user may confirm the submission request (e.g. by tapping "Yes" on the time period selection screen <NUM>), initiating the submission of a hidden flashed image (step <NUM>). The completed submission request, including the image and associated submission data indicative of the recipient and time period, is then uploaded to the system <NUM> (step <NUM>), for example, using an API such as a standard server interface that supports data transfer over the Internet (e.g. JavaScript Object Notation or JSON).

The operational flow of <FIG> continues with the receipt, by the system <NUM>, of the submission request. Upon receipt of the submission request, the system <NUM> may update the user interface <NUM> associated with the recipient indicated by the submission request to make the image of the submission request available for display for the period of time designated by the submission request. The system <NUM> may, for example, update server-side data to be interpreted by the mobile application <NUM> installed on the recipient's mobile device. The system <NUM> may then send a push notification <NUM> to the recipient's mobile device (step <NUM>), the push notification <NUM> indicating that the image is available for display for the period of time designated by the submission request. The recipient's mobile device may then display the push notification <NUM> (step <NUM>) on a lock screen <NUM> as shown in <FIG> or other screen (e.g. notification center) where push notifications <NUM> are displayed, or as a popup overlaying any screen of the mobile device. If time remains before the image expires, the recipient may view the image by launching the mobile application <NUM> directly from the push notification <NUM> or by navigating to the image from within the mobile application <NUM> as described in relation to <FIG>, <FIG>, and <FIG>.

<FIG> shows another example operational flow according to an embodiment of the present disclosure in relation to the system <NUM> shown in <FIG> and <FIG> and the sequences of screenshots shown in <FIG>, <FIG>, <FIG>, <FIG>, and <FIG>. The operational flow of <FIG> may occur within the recipient's mobile device when the recipient wishes to view the image sent by the sender in <FIG> (i.e. the hidden flashed image indicated in the push notification <NUM>). The operational flow of <FIG> may begin (step <NUM>) either with the recipient's interaction with the push notification <NUM> as shown in <FIG> (Case <NUM>) or with the recipient's interaction with the hidden flash history button <NUM> as shown in <FIG> (Case <NUM>). In either case, as described above, authentication of the user may be required (step <NUM>), for example, by fingerprint using an authentication prompt <NUM> and authentication success notification <NUM> as shown in <FIG> and/or by passcode using a password prompt <NUM> and password entry tool <NUM> as shown in <FIG>. Following the successful authentication of the recipient of the sent image, the mobile device may query the system <NUM> for the image and associated time period as set in the sender's submission request (step <NUM>), for example, using an API such as a standard server interface that supports data transfer over the Internet (e.g. JavaScript Object Notation or JSON). In the case of accessing the image directly from the push notification <NUM>, for example, the query to the system <NUM> may include an ID of the push notification <NUM> that links the push notification <NUM> with the sender's submission request. In the case of accessing the image from a history screen <NUM> of the mobile application <NUM> using the hidden flash history button <NUM>, the query to the system <NUM> may locate any submission requests that were uploaded by the user whose history screen <NUM> is being viewed and whose submission data indicates the recipient. Having located the correct submission request, the mobile application <NUM> may then display the image to the recipient (e.g. on an image viewing screen <NUM> of the user interface <NUM>), along with a timer <NUM> showing the remaining viewing time, provided the viewing time has not already expired (step <NUM>).

<FIG> shows a user interface <NUM> of the mobile application <NUM> running on sender and recipient mobile devices connected to the system <NUM> in three consecutive stages. In the example of <FIG>, for purposes of illustration, the sender is a customer of some business, municipality, or other service provider. The recipient is the service provider. The left-most screenshot represents the sender's (i.e. customer's) experience in creating a submission request for sending data to the recipient (i.e. service provider). The sender's experience with the user interface <NUM> may be the same as the sender's experience with the user interface <NUM> described in relation to <FIG>, <FIG>, and <FIG>, except as described below.

The left-most screenshot of <FIG> depicts an image selection screen <NUM> that is the same as the image selection screen <NUM> of the user interface <NUM> shown in <FIG> except that the hidden flash button <NUM> is omitted. (It is noted that the hidden flash button <NUM> need not be omitted, and that the functionality of the user interfaces <NUM> and <NUM> may be combined into a single user interface. ) Here, as in <FIG>, the sender may select an image <NUM> from a set of available images <NUM> stored locally on the mobile device. The set of images <NUM> may, for example, be imported from a photo library on the mobile device and may be displayed as a grid of thumbnail images <NUM> as shown. As the sender taps each image <NUM>, the image <NUM> may be marked (e.g. with a colored border) to show that it is the currently selected image <NUM>. A large view 1420a of the currently selected image <NUM> may be displayed as shown.

In the example of <FIG>, the sender has written the words "DON'T CROSS THE LINE" on the selected image <NUM>. Such editing of the selected image <NUM> may be done using editing tools (e.g. pencil, paintbrush, textbox, graphics, etc.) that may be revealed by tapping the edit button <NUM>. (As shown in <FIG>, an identical edit button <NUM> may be available on the image selection screen <NUM> of the user interface <NUM>. ) In the context of a customer sending an image to a service provider as described in relation to <FIG>, the edit button <NUM> may allow the sender to provide some explanation or context when sending an image to the service provider. For example, in the case of <FIG>, the customer has taken a picture of a misplaced traffic barrier that is positioned too far over the yellow center line of a road. The customer has selected the image <NUM> to send to the appropriate traffic authority and has edited the image using the edit button <NUM> to explain the customer's complaint that the traffic barrier has impermissibly crossed the line.

When the sender is satisfied with the selected image <NUM> and any editing of the selected image <NUM>, the sender may tap the flash button <NUM> to proceed with creating the submission request. At this point, the user may be prompted to select various options related to the submission request, such as whether any time period for viewing the image should be associated with the image (e.g. using the time period selection screen <NUM> of <FIG>, though this functionality may in some cases be limited to hidden flashed images as described above). For purposes of the example of <FIG>, it is assumed that the sender has opted to include a call request with the image, which may be designated after tapping the flash button <NUM> or may be designated by the sender in a settings menu to include a call request generally for all submission requests. The completed submission request may be transmitted to the system <NUM> and may include the selected image <NUM> (e.g. an image file) together with associated submission data indicative of the selected recipient (e.g. the contact whose flash button <NUM> was used to initiate the submission request as shown in <FIG>) and the designation to include a call request. As described in more detail below, the system <NUM> will then make the selected image <NUM> available for viewing by the recipient, who will then be able to call back the sender with the touch of a button.

The center and right-most screenshots in <FIG> show the recipient's (service provider's) mobile device during the recipient's receipt of a push notification <NUM> regarding the sender's (customer's) submission request. The recipient's experience may begin at a lock screen <NUM> of the mobile device as shown in the left-most screenshot of <FIG> or other screen (e.g. notification center) where push notifications <NUM> are displayed, or as a popup overlaying any screen of the mobile device. In the example of the center screenshot of <FIG>, the recipient is currently viewing a contacts screen <NUM> (with the "Favorites" tab selected), which may be the same as the contacts screen <NUM> of <FIG>, when a push notification <NUM> corresponding to the sender's submission request appears as a popup. Like the push notification <NUM> shown in <FIG>, the push notification <NUM> of <FIG> may include the name ("Flash") and icon of the mobile application <NUM>, the time of day that the push notification <NUM> was received ("Now"), and the content of the push notification <NUM> ("from Iphone <NUM>"). If the recipient would like to navigate directly to the image (including launching the mobile application <NUM> if necessary), the recipient may swipe, tap, or otherwise interact with the push notification <NUM> using the ordinary procedure for navigating to an application on the mobile device via a push notification according to the mobile device's operating system.

In response to the recipient's interacting with the push notification <NUM>, the user interface <NUM> of the mobile application <NUM> may navigate directly to a screen for viewing the image referred to in the push notification <NUM>, i.e. the selected image <NUM> sent by the customer named "Iphone <NUM>" in the recipient's contact list (also referred to as the "flashed" image). An example of this is shown in the right-most screenshot of <FIG>, where an image viewing screen <NUM> of the user interface <NUM> is shown, including a view <NUM> of the flashed image along with any writing and drawing created by the sender using the edit button <NUM>. Since the flashed image is a regular flashed image in this case, not a hidden flashed image as shown in the image viewing screen <NUM> of <FIG>, the timer <NUM> may be omitted and the flashed image may be available indefinitely. Along the same lines, saving functionality (disk button) and/or favorite functionality (star button) may be provided here to allow the recipient to find and view the image at a later time. Such functionality may be disabled in the case of a hidden flashed image. Together with the flashed image, the image viewing screen <NUM> also includes a call button <NUM> as specified by the sender's submission request. The recipient (business enterprise) can simply tap the call button <NUM> to instantly initiate a phone call with the mobile device of the sender of the flashed image. Instead of calling the mobile device of the sender of the flashed image, it is possible to send a message. In this regard, the image viewing screen <NUM> includes a message button <NUM> as specified by the sender's submission request. The message may be e-mail, an SMS text message, or any other suitable communication. Thus it will be appreciated that such phone calls and messages may be generally referred to as a communications interaction that may be initiated.

As shown on the contacts screen <NUM>, the list item <NUM> associated with the contact who sent the submission package (i.e. the customer) has been updated to change the contact's avatar <NUM> to the flashed image (including sender's edits). This may allow the recipient (i.e. service provider) to easily associate contacts and call numbers with current customer issues/requests. For example, by simply glancing at the list item <NUM> associated with the contact name "Iphone <NUM>," it can be immediately understood that this contact was the person who pointed out the problem involving the traffic barrier.

<FIG> shows an example operational flow according to an embodiment of the present disclosure in relation to the system <NUM> shown in <FIG> and <FIG> and the sequence of screenshots shown in <FIG>. The operational flow of <FIG> may begin within the sender's (customer's) mobile device, where the sender selects a recipient and image (step <NUM>) as described in relation to the image selection screen <NUM> of the user interface <NUM> as shown in <FIG>. As noted above, selecting a recipient may be the same as described in relation to the contacts screen <NUM> of <FIG> (e.g. tapping the flash button <NUM> of the list item <NUM> associated with the contact who is the desired recipient). The image may be selected, for example, by tapping the image <NUM> followed by the flash button <NUM>. After selecting the recipient and image, the operational flow may continue with the submission of a flashed image with call request (step <NUM>), though the call request itself may be a default setting for that user. The completed submission request, including the image and associated submission data indicative of the recipient, is then uploaded to the system <NUM> (step <NUM>), for example, using an API such as a standard server interface that supports data transfer over the Internet (e.g. JavaScript Object Notation or JSON).

The operational flow of <FIG> continues with the receipt, by the system <NUM>, of the submission request. Upon receipt of the submission request, the system <NUM> may update the user interface <NUM> associated with the recipient (i.e. service provider) indicated by the submission request to make the image of the submission request available for display. The system <NUM> may, for example, update server-side data to be interpreted by the mobile application <NUM> installed on the recipient's mobile device. The system <NUM> may then send a push notification <NUM> to the recipient's mobile device (step <NUM>), the push notification <NUM> indicating that the image is available for display. The recipient's mobile device may then display the push notification <NUM> (step <NUM>) as a popup as shown in <FIG> (or on a lock screen <NUM> as shown in <FIG> or other screen where push notifications <NUM> are displayed). As described above, the recipient's mobile device may also update the avatar <NUM> of the sender (i.e. customer) in the mobile device's native contacts list and/or in the contacts list of the contacts screen <NUM> of the mobile application <NUM> (which may be an import of the device's native contacts list as described above). The recipient may view the image by launching the mobile application <NUM> directly from the push notification <NUM> or by navigating to the image from within the mobile application <NUM> as described in relation to <FIG>, <FIG>, and <FIG>.

<FIG> shows another example operational flow according to an embodiment of the present disclosure in relation to the system <NUM> shown in <FIG> and <FIG> and the sequences of screenshots shown in <FIG>. The operational flow of <FIG> may occur within the recipient's (i.e. service provider's) mobile device when the recipient wishes to view the image sent by the sender (i.e. customer) in <FIG> (i.e. the flashed image indicated in the push notification <NUM>). The operational flow of <FIG> may begin (step <NUM>) either with the recipient's interaction with the push notification <NUM> (Case <NUM>) or with the recipient's interaction with the history button <NUM> (Case <NUM>) shown in <FIG> (and as described in relation to <FIG>). In either case, optionally following the successful authentication of the recipient, the mobile device may query the system <NUM> for the image and any associated time period as may have been set in the sender's submission request (step <NUM>), for example, using an API such as a standard server interface that supports data transfer over the Internet (e.g. JavaScript Object Notation or JSON). In the case of accessing the image directly from the push notification <NUM>, for example, the query to the system <NUM> may include an ID of the push notification <NUM> that links the push notification <NUM> with the sender's submission request. In the case of accessing the image using a history button <NUM> of the mobile application <NUM>, the query to the system <NUM> may locate any submission requests that were uploaded by the user whose history button <NUM> was interacted with and whose submission data indicates the recipient. Having located the correct submission request, the mobile application <NUM> may then display the image to the recipient (e.g. on an image viewing screen <NUM> of the user interface <NUM>), along with the call button <NUM> or message button <NUM> (step <NUM>). The call button <NUM> or message button <NUM> may be embedded in the image.

<FIG> shows another example operational flow according to an embodiment of the present disclosure in relation to the system <NUM> shown in <FIG> and <FIG> and the sequence of screenshots shown in <FIG>. The operational flow of <FIG> may begin within the recipient's (i.e. service provider's) mobile device immediately following the operational flow of <FIG>. While viewing the flashed image on the image viewing screen <NUM> of the user interface <NUM>, the recipient may tap the call button <NUM> to initiate a phone call with the mobile device of the sender directly from within the mobile application <NUM> (step <NUM>). The operational flow may continue with the sender's (i.e. customer's) mobile device receiving the phone call initiated by the recipient (i.e. service provider) along with a full screen view of the image that was part of the sender's (i.e. customer's) submission request (step <NUM>), e.g. the image of the misplaced traffic barrier. For example, in the case of a mobile device using an iOS® operating system, the sender's creation/upload of the submission request (e.g. step <NUM> of <FIG>) may cause the mobile application <NUM> to update the sender's native contact settings to replace the avatar of the recipient with the image of the submission request. Then, when the sender's mobile device receives the incoming call from the recipient in step <NUM> of <FIG>, the mobile device will display the image together with the incoming call.

In the case of a mobile device using an Android® operating system, the operational flow of <FIG> may be used. In this case, after the recipient (i.e. service provider) taps the call button <NUM> to initiate a phone call with the mobile device of the sender (step <NUM>), the mobile application <NUM> in the sender's (i.e. customer's) mobile device may recognize the incoming call phone number as being the phone number of the recipient associated with a flashed image (step <NUM>). The mobile application <NUM> may then retrieve the locally stored copy of the flashed image associated with that phone number (step <NUM>) and display a popup of the image while the phone call is incoming, i.e. before the sender (i.e. customer) answers the phone (step <NUM>). The popup may be set to automatically close after a period of time (e.g. five seconds) and/or in response to user interaction with a "close" button.

By displaying the sender's own flashed image on the sender's mobile device when the recipient calls back the sender, the sender can immediately be reminded of what the call is concerning. For example, the sender may see the image shown in <FIG> and recognize that the call pertains to the misplaced traffic barrier.

In the above description of <FIG>, <FIG>, <FIG>, <FIG>, an example is provided in which the sender of the flashed image is a customer and the recipient of the flashed image is a service provider. In this context, the customer may easily point out something to the service provider (e.g. the misplaced traffic barrier described above, a broken or missing part of a home/auto system or appliance, etc.). However, the disclosure is not limited to these particular roles of the sender and recipient. For example, it is also contemplated that the sender of the flashed image may be the service provider and the recipient may be the customer. For example, a service provider with which the customer has an upcoming appointment (e.g. a dentist, an auto shop, etc.) may use the mobile application <NUM> to send an appointment reminder to the customer, replacing conventional SMS notifications with visual notifications including a picture and data. The view <NUM> of the flashed image may be an image of the appointment reminder itself (e.g. an image of a calendar with a marked appointment) or an image related to the subject of the appointment (e.g. the customer's car) with overlaid text detailing the appointment reminder. In addition to the call button <NUM>, which may be used by the customer to call the service provider to reschedule the appointment, additional buttons may be provided to confirm or cancel the appointment. For example, the recipient may be given options to tap on left to confirm, tap on right to cancel, or tap the call button <NUM> to call and reschedule. It is also contemplated that the timer <NUM> described above in relation to <FIG> can be used in the customer/service provider setting, with the timer <NUM> applying to an image or other media sent in either direction. For example, a financial institution (e.g. a bank) or other service provider enterprise may use the mobile application <NUM> to send secure, time sensitive messages to a customer or simultaneously to several of their customers. Likewise, a customer can send a secure, time sensitive message to the service provider enterprise, such as a temporary authorization that expires according to the timer <NUM>.

Referring back to the diagram of <FIG>, although the foregoing embodiments contemplate an implementation with the mobile application <NUM> running on each of the mobile devices (e.g., smartphones) connecting to the system <NUM>, another embodiment of the present disclosure contemplates an implementation with a native call controller <NUM> of the mobile device. As referenced herein, the native call controller <NUM> is understood to be a software component of the mobile device operating system that initiates the placement of outgoing calls and acceptance of incoming telephone calls, text messages, and videoconferences. There may be sub-interfaces or panels for inputting the numeric digits of telephone numbers, contact lists, recently placed and received calls, favorite contacts, voicemail, and so forth. Once a call is in progress, the native call controller <NUM> may also include features for muting the audio, inputting numeric digits (in the form of touch-tone/DTMF signals), audio output and input sources, adding additional callers, and so forth. Thus, in the context of the illustrated example, the first mobile device may include a native call controller 1110a and a second mobile device may include a native call controller 1110b.

Referring now to <FIG>, the native call controller <NUM> may have a user interface <NUM>, with the leftmost screen shot thereof depicting a user's (i.e., the sender's) experience of creating a submission request for sending data from the mobile device to another mobile device via the system <NUM>. Illustrated therein is a contacts screen <NUM> showing a list of the sender's contacts (e.g., in alphabetical order). Each item <NUM> of the list of contacts may include a name <NUM>, a thumbnail image or avatar <NUM> representing the contact, and a flash button <NUM>. In the illustrated example, selecting the name <NUM> and/or the avatar <NUM> is understood to initiate a phone call with the contact.

Alternatively, selecting the name <NUM> and/or the avatar <NUM> from the contacts screen <NUM> may invoke a detailed contact screen <NUM> as shown in the leftmost screen shot of <FIG>. In addition to the name <NUM> and the avatar <NUM> that is the same as in the contacts screen <NUM> (e.g., the name <NUM> and the avatar <NUM>, respectively), a phone number <NUM> may be listed, along with a phone button <NUM> to initiate the phone call with the contact, a text message button <NUM> to initiate another interface within the mobile operating system to send and receive SMS text messages, and a flash button <NUM> for creating a submission request.

Whether invoked through the flash button <NUM> on the contacts screen <NUM> or the flash button <NUM> on the detailed contact screen, the user interface <NUM> may navigate to an image selection screen <NUM> as shown in the center screenshot of <FIG> and <FIG>. The sender may select an image <NUM> from a set of available images stored locally on the mobile device. The set of images <NUM> may, for example, be imported from a photo library on the mobile device and may be displayed as a grid of thumbnail images, as shown. When the sender taps the desired image <NUM>, it may be marked (e.g. with a colored border) to show that it is the currently selected one, and this action is understood to create the submission request that assigns the selected image <NUM> for the designated contact to receive and/or display in connection with the call that is initiated thereto by the user. The user interface <NUM> navigates back to the contacts screen <NUM> which now has a thumbnail <NUM> of the previously selected image <NUM> that is designated or assigned for the contact.

Figure 11A shows the user interface <NUM> of the native call controller <NUM>, and the left screen shot shows a contacts screen <NUM> with a specific call recipient being selected. In further detail, when an item <NUM> is selected in the contacts screen <NUM>, a call button <NUM> is presented underneath the item <NUM>, along with a text message button <NUM> and a details button <NUM> that, when invoked, presents the detailed contact screen <NUM> discussed above with reference to <FIG>. Activating the call button <NUM> then invokes a call initiation screen <NUM>. In a conventional implementation of the native call controller <NUM>, the name of the called contact is displayed, along with a progress indicator, and a buttons to terminate the call or mute the call. Any other graphical elements may be presented on the call initiation screen <NUM> in accordance with the implementation of the mobile operating system.

Referring to <FIG>, on the receiving end, e.g., the corresponding native call controller <NUM> presents in the user interface <NUM> a call receive screen <NUM>. Displayed as the background of the call receive screen <NUM> is the image <NUM> as previously selected by the initiating user via the image selection screen <NUM>. At this juncture, of the incoming phone call, the user has the option of declining or accepting the call, as well as sending a text message reply. Again, these options may depend on the specifics of the mobile operating system, so these are presented by way of example only and not of limitation. Once the call is accepted, a call progress screen <NUM> continues to display the image <NUM> as selected by the initiating user.

<FIG> shows an example operational flow according to an embodiment of the present disclosure in relation to the system <NUM> shown in <FIG> and <FIG> and the sequences of screenshots shown in <FIG>, <FIG>, <FIG>. The operational flow of <FIG> may begin within the sender's mobile device, where the user selects a recipient and image (step <NUM>) as described in relation to the contacts screen <NUM> and the detailed contact screen <NUM> on one hand, and the image selection screen <NUM> of the user interface <NUM> on the other hand, as shown in <FIG> and <FIG>. The recipient may be selected, for example, by tapping the flash button <NUM> of the list item <NUM> associated with the contact who is the desired recipient, or the flash button <NUM> in the detailed contact screen <NUM> for the specific contact. The image may be selected by tapping the image <NUM> (step <NUM>). With the recipient and the image being selected, the submission may be initiated. The completed submission request, including the image and associated submission data indicative of the recipient is then uploaded to the system <NUM> (step <NUM>), for example, using an API such as a standard server interface that supports data transfer over the Internet (e.g. JavaScript Object Notation or JSON).

The operational flow of <FIG> continues with the receipt, by the system <NUM>, of the submission request. Upon receipt of the submission request, the system <NUM> may update the user interface <NUM> associated with the recipient indicated by the submission request to make the image of the submission request. The system <NUM> may, for example, update server-side data, and then send a push notification to the recipient's mobile device (step <NUM>). On the recipient's mobile device, the operational flow may continue with first checking the setting for displaying or hiding a push notification (step <NUM>). The push notification is hidden (step <NUM>) or shown (step <NUM>) to the extent user settings so dictate either way. The native call controller <NUM> retrieves the image via an API request (step <NUM>), and the avatar <NUM> associated with the sending user may be updated in the mobile device's native contacts list (step <NUM>).

<FIG> shows an example data sharing system <NUM> according to an embodiment of the present disclosure. The data sharing system <NUM> may be an example of the system <NUM> described in relation to <FIG> and may function as a server as depicted in <FIG>, <FIG>, and <FIG> to support data sharing between a first computing device 3000a and a second computing device 3000b (e.g. mobile phones). Referring to the server-side processes described above in relation to <FIG> by way of example, a request processor <NUM> of the data sharing system <NUM> may receive the submission request uploaded in step <NUM>, data of which may be stored in a data storage <NUM>. For example, a user/request data storage <NUM> may store data indicative of the sender, recipient, and/or request parameters associated with the request while an image data storage <NUM> stores the data of the uploaded image in association therewith. An image access manager <NUM> may then provide the image to the second computing device 3000b, including any optional push notification as generated by the device notifier <NUM> and/or period of time for viewing the image as managed by a timer <NUM> and discussed above in relation to <FIG>.

In the embodiments of the present disclosure, the operational flow and the user interface features described above are contemplated to enable one user, e.g., the initiating user, to specifically define his or her persona or visual appearance to the other users, e.g., the recipient. As discussed above, the initiating user is the one selecting the visual element of a photograph, animated image, video, etc. and that is propagated to those receiving users that the initiating user selects. This is understood to represent a departure over conventional contact list modalities by which the recipient of a phone call, text message, or the like assigns a photograph to a contact, and when there is an incoming telecommunications request, the recipient-selected image is presented. Effectively, this places the control of the initiating user's persona in the hands of the initiating user, relative to one or more of the recipient users.

It should be noted that such functionality, as exemplified by <FIG>, <FIG>, <FIG> in relation to a user interface <NUM> associated with a native call controller <NUM>, may also be provided in relation to the user interfaces <NUM>, <NUM> described above in relation to the mobile application <NUM>. For example, referring to the sequence of screenshots shown in <FIG> and <FIG>, selection of an image <NUM> may be used to define a sender-selected image associated with a given contact item <NUM> that will then appear on a recipient's screen when the sender initiates a phone call, text message, etc. to the recipient.

The system <NUM> and/or application server <NUM> of <FIG> and/or the system <NUM> of <FIG> may be wholly or partly embodied in a computer including a processor (e.g. a CPU), a system memory (e.g. RAM), and a hard drive or other secondary storage device. The processor may execute one or more computer programs, which may be tangibly embodied along with an operating system in a computer-readable medium, e.g., the secondary storage device. The operating system and computer programs may be loaded from the secondary storage device into the system memory to be executed by the processor. The computer may further include a network interface for network communication between the computer and external devices (e.g. over the Internet), such as the mobile devices accessing the user interface <NUM>, <NUM> described throughout this disclosure using the mobile application <NUM>.

The computer programs may comprise program instructions which, when executed by the processor, cause the processor to perform operations in accordance with the various embodiments of the present disclosure. The computer programs may be provided to the secondary storage by or otherwise reside on an external computer-readable medium such as a DVD-ROM, an optical recording medium such as a CD or Blu-ray Disk, a magneto-optic recording medium such as an MO, a semiconductor memory such as an IC card, a tape medium, a mechanically encoded medium such as a punch card, etc. Other examples of computer-readable media that may store programs in relation to the disclosed embodiments include a RAM or hard disk in a server system connected to a communication network such as a dedicated network or the Internet, with the program being provided to the computer via the network. Such program storage media may, in some embodiments, be non-transitory, thus excluding transitory signals per se, such as radio waves or other electromagnetic waves. Examples of program instructions stored on a computer-readable medium may include, in addition to code executable by a processor, state information for execution by programmable circuitry such as a field-programmable gate arrays (FPGA) or programmable logic array (PLA).

Throughout the above description of the user interface <NUM>, <NUM> and other user interfaces of the mobile devices described herein, reference is made to various means of user interaction, including tapping on or swiping various user interface elements. The disclosure is not intended to be limited to such specific interactions and any known user-device interactions may be applicable, including but not limited to keyboard, mouse, touch, gesture, voice, eye-tracking, etc..

Although the foregoing examples variously refer to images presented to users, it is expressly contemplated that any data, including video data, audio data, text data, and any other data that may be visually represented may be substituted without departing from the scope of the present disclosure. Although the foregoing examples refer to mobile devices (e.g. smartphones, tablets, laptop computers) of the sender and receiver, it is contemplated that one or both of the mobile devices may instead be a computing device other than a mobile device, such as a desktop computer. In this case, the mobile application <NUM> be a desktop application (e.g. a web browser). As an example, a service provider may make use of an enterprise interface in the form of a desktop computer for sending out multi-media or visual notifications (e.g. appointment confirmations as described above) to consumer/customer mobile devices according to the embodiments of the disclosure. Furthermore, along these lines, the specific embodiments described above with respect to certain components performing the steps of the contemplated methods, that is, the functionalities being allocated or attributed to one mobile device or computing device or another, is likewise by way of example only and not of limitation. For instance, an administrative module may be provided to an enterprise via the aforementioned desktop application to perform one or more of the functions described above.

The above description is given by way of example, and not limitation. Given the above disclosure, one skilled in the art could devise variations that are within the scope of the attached claims.

Claim 1:
A non-transitory program storage medium on which are stored instructions executable by a processor or programmable circuit to perform operations for enhancing data sharing between computing device users, the operations comprising:
receiving a submission request generated by user interaction with a first user interface (<NUM>, <NUM>) accessible via an application installed on a first computing device, the submission request including an image (<NUM>), a video content, and a user-defined period of time for the image (<NUM>) or the video content to be available, and associated submission data indicative of a recipient of the image (<NUM>);
updating a second user interface (<NUM>, <NUM>) to make the image (<NUM>) available for display together with a call button (<NUM>) embedded therein, the second user interface (<NUM>, <NUM>) being accessible via an application installed on a second computing device associated with the recipient, and the call button (<NUM>) being operable by user interaction with the second user interface (<NUM>, <NUM>) to initiate a communication interaction from the second computing device to the first computing device; and
displaying the image (<NUM>) on the first user interface (<NUM>, <NUM>) in response to the incoming communication interaction from the second computing device originated by invoking the call button (<NUM>) embedded in the image (<NUM>) or the video content made available for display on the second user interface (<NUM>, <NUM>).