BR112016010634B1 - METHOD IMPLEMENTED BY COMPUTER, SERVER AND CLIENT DEVICE - Google Patents

Abstract

METHOD IMPLEMENTED BY COMPUTER, SERVER, CLIENT DEVICE AND APPLICATION. It is an enhanced social media or messaging platform that can be provided that largely retains both the immediacy and engagement of video conferencing, while not sacrificing the benefits most characteristic of email and messaging platforms. similar features such as asynchronous programming, bandwidth efficiency, and various administrative record keeping benefits. Audio data and associated gesture data (e.g., panning and zooming) are recorded by users in association with image data, and shared with other users in a conversational thread, enabling a video-like experience without additional associated bandwidth.

Description

FIELD OF INVENTION

[0001] The present invention relates to social media and messaging services, and, more broadly, to systems and methods for creating and sharing messages of semantic content on electronic networks.

BACKGROUND OF THE INVENTION

[0002] Typically, video conferencing, email or instant messaging are used as communications media for business collaboration.

[0003] Videoconferencing may be a "good enough" substitute for face-to-face meetings, but it is bandwidth intensive and relies on programming availability from all parties. Telephone conversations are also widely used, but lack the visual cues of video conferencing. Video conferencing and meetings, despite these limitations, are often favored as they offer immediacy and engagement.

[0004] Emails and instant messaging are also popular as they allow for both receiving and responding, and for this reason can be characterized as "asynchronous" in nature. A full text-based record of all communications is also available for later reference, and is typically stored, indexed in various ways, and searched when necessary.

[0005] Emails and instant messaging are attractive, on the one hand, as they avoid the scheduling problems of synchronous communications media, and also retain a convenient record of communications. A specific limitation of such forms of communication is that they lack the immediacy and engagement of video conferencing and similar forms of exchange, as noted above.

[0006] Furthermore, it can sometimes be difficult to compose emails and instant messages to a desired level of clarity. Even the most articulate individual may have difficulty presenting certain ideas, content, or messages in email and instant messaging media. A notable limitation of these forms of communication is the inability, or indeed the difficulty, of conveying "tone" - with concomitant potential for miscommunication, especially if the matter is in any way sensitive.

[0007] The limitations of email platforms and similar messages are, in this sense, a collection - situated, on the one hand, in those composing messages to carefully produce messages that adequately convey an intended meaning, and situated, on the other hand, in the audience's search to discern meaning, given the limitations of the environment.

[0008] An objective of the present invention is to provide a form of electronic communication that at least attempts to deal with these and other limitations of existing forms of communication and, in particular, to provide a means of asynchronous communications that solves, or at least alleviates, these and other difficulties experienced in communicating through existing channels.

SUMMARY OF THE INVENTION

[0009] The inventive concept arises from a recognition that existing internet media is not entirely satisfactory in certain senses for the purpose of transporting semantic content asynchronously in a bandwidth-efficient manner.

[0010] An enhanced social media or messaging platform can, for this purpose, be provided, which largely retains both the immediacy and engagement of video conferencing, while not sacrificing the benefits most characteristic of email platforms. mail and similar messages, such as asynchronous scheduling, bandwidth efficiency, and various administrative record keeping benefits.

[0011] The present invention relates, more broadly, to a structured file format and to systems for recording, storing and recreating such file formats as a means of communications in an electronic network of computing devices. The "Blrt" file format combines compressed audio, animated gesture data, and a variety of digital media formats in one lightweight package.

[0012] Media files are stored separately, but share a relationship with audio/gestures, which facilitates the progressive transmission of packet and media data, mostly at the time of creation, leading to a seamless and fast user experience. Separating audio/gesture media also duplicates data in a single "conversation", where responses use the same media files so they don't need to be downloaded or uploaded more than once.

[0013] A network in which messages are shared is referred to, in the present invention, as a convenience internet, as typically understood, but can be any suitable computer network, including public networks, as well as closed or private networks. Such networks may include, as an example, firewalled corporate networks or virtual private networks, regardless of whether or not they use Internet Protocols as variously implemented. The present invention is, in other words, agnostic to the specific form of hardware or network communication protocols used in any specific network.

[0014] A dedicated application, or application, that runs on a client device is preferably used by the author, to distribute and ver messages, through an interface may be provided through a general purpose web browser, or applications on various hardware devices and operating system platforms.

[0015] Although messages may be directed by a user to an individual recipient or multiple recipients, messages may also be "broadcast" to a wider audience (i.e., public), or, in fact, a selected approved audience. A system of permissions and controls can be implemented as required to regulate who is able to see and respond to messages. Furthermore, a selection of messages can be curated as a stream for general consumption or via subscription.

[0016] The present invention, in one aspect, provides a computer-implemented method of hosting a messaging service on a server for use by users via client devices in communication with the server. Client devices run an application to originate and share messages comprising image data, audio data and gesture data between users, and the server comprises hardware components adapted to perform the steps of: receiving audio data and manager data related to a message from a device originating client on the server; storing the audio data and the gesture data on the server in association with the image data to which the audio data and the gesture data are related; and distributing the stored audio data and gesture data to a recipient client device from the server; wherein the received audio data and management data are recorded on the originating client device in association with the image data, and distributed to the recipient client device for playback through the recipient client device in association with the image data.

[0017] Preferably, the method further comprises receiving image data from an originating client device on the server, and distributing the image data to a receiving client device.

[0018] Image data is received as or before audio data and gesture data are recorded, which helps network traffic and network latency.

[0019] On the server, image data is preferably stored in association with audio data and gesture data to which image data is related.

[0020] The gesture data advantageously comprises panning, zooming and rotating functionality of the image data, as well as layered visual annotations on the image data.

[0021] The present invention provides, in a further aspect, a server for hosting a messaging service for use by users via client devices in communication with the server, wherein the client devices execute an application for the origination and sharing of user messages comprising image data, data of audio and gesture data, wherein the server comprises hardware components adapted to perform steps in accordance with the first mentioned aspect of the present invention.

[0022] The present invention, in a further aspect, provides a computer-implemented method of using a client device to interact with a messaging service hosted on a server through an application running on the client device for originating and sharing user messages comprising image data, audio data and gesture data, with the application adapted to perform the steps of: uploading image data to the server using the client device; recording, with the use of the client device, audio data and gesture data that are related to the image data; and uploading the audio data and the gesture data from the client device to the server for storage and association with the image data to which the audio data and gesture data are related.

[0023] Image data is preferably uploaded before or as audio data and gesture data are recorded.

[0024] The present invention, in a further aspect, provides an application configured to run on a client device in accordance with the above-mentioned aspects of the present invention.

[0025] The present invention, as variously embodied, has many advantages, as will be evident to those skilled in the art. Advantageously, from a user perspective, the application is intended to provide a satisfactory replacement for meetings, calls and emails.

[0026] Specifically, the message format and application interface attempt to encompass the benefits of email, calls, and meetings, while substantially avoiding their inherent limitations. Furthermore, messaging provides benefits often associated with video conferencing, but without the same bandwidth overhead, and without the need for programming difficulties. Preferred embodiments of the present invention are intended for dynamic communication, and allow for more effective collaboration.

[0027] Once recordings begin, a user can begin speaking, thereby narrating their message, approaching an image and scribbling notes where required. Such gestures are captured in sync with the attached audio, for display or playback, in sync, across recipients. A user can send his message to many specified recipients. Source images can be extracted from different sources, regardless of whether they are from native storage or network storage.

[0028] Since the message format comprises images, which are displayed using source images, (instead of video formats), the required bandwidth is fractional, compared to distributing video files. Typical proposed usage suggests that the bandwidth footprint of the messaging service could be 50x lighter than a comparable service using existing video formats. Furthermore, a cloud-centric server model allows for the reuse of media on the client device once distributed across applicable devices, further reducing bandwidth traffic.

[0029] This present invention seeks to combine "reply whenever", conversation logging, and low bandwidth advantages of email and instant messaging with the superior interpersonal communication qualities of meetings and video conferencing.

[0030] This is made possible by combining compressed audio, animated gesture data (rendered client-side), and a variety of digital media attachments into a lightweight package (which is the Blrt file format).

[0031] This package, as displayed on a client device, is effectively a video-like rendering of a user tag in the media appended with a recorded audio commentary.

[0032] The Blr package is transported as three-key components: audio, gesture data, and attached media. The Blrt package is not transcoded at any point to a video file, which allows the format to remain at a significantly smaller file size, which is the total file size of the three-key components.

[0033] Consequently, this feature allows transmission and marking of attached high-resolution media without quality loss or with minimal quality loss, while allowing reasonable bandwidth performance.

[0034] The Blrt packet is not transmitted in full every time an exchange is made. Instead, attached media files (which typically comprise the bulk of the file size) are downloaded only once in a conversation.

[0035] Responses ("Blrt Responses") are performed using the same media attachments and so, in most cases, only audio and gesture data need to be uploaded for this. The exception to this is if a user adds new images/pages to the conversation, in which case the system will only apply the new media elements to the users' devices, maintaining a high level of efficiency in exchanging data between server and device.

[0036] Also, the total package is progressively uploaded when a conversation is first created; media attachments are uploaded as the user records their audio and gestures, then audio and gesture data are recorded as the user selects the recipient(s). Generally speaking, this results in a seamless upload experience with almost no perceived wait time for the user.

[0037] Several exemplary applications can be considered. First, conventional one-to-one messages can be used, as can one-to-many messages, in a manner similar to conventional email messages and a system ("to" and "cc" recipients). This aspect is primarily described here, and is preferably conducted through a dedicated native application or a mobile or web application, although access to the messaging platform can be through a variety of equipment.

[0038] The messaging service may, however, also be provided in other aspects. As an example, public accounts may be provided to enable a public broadcast feed of messages, with attached tags - such as through a browsable domain and URL (e.g., blr.com/username) in a manner similar to Twitter, Instagram or other media services Social. Users can, logically, be individuals (regardless of whether they are citizens or celebrities), or, in fact, companies or brands. Furthermore, users can be roles or offices (e.g. Telstra Helpdesk, Australian Prime Minister, etc).

[0039] Additionally, curated "channels" may also be provided, based on content genres, events, or other themes (e.g., blrt.tv/comedy/, blrt.tv/election2016, etc.). Public messages can also be browsed by channel or by tags, occurrences, relevance, upvotes or other forms of filtering.

[0040] Messages may also be distributed or disseminated as embedded content in a variety of ways to suit prevailing requirements or tastes.

[0041] As described above, the present invention relates to the use of source images (also referred to, in the present invention, as image data or a media file), instead of video. The advantages that accrue to embodiments of the present invention are contingent upon the use of image data rather than video data per se, particularly with respect to the bandwidth efficiency that can be realized with the use of image data to achieve a video-like experience, the image data being are therefore used in this document according to their understood meaning, that is, as the data is related to a single static frame, rather than the multiple frames (however, encoded) that characterize video data.

[0042] As will be understood, image data can be defined as raster data or vector data. Examples of typical raster image data formats are - by reference to their commonly used file extensions - JPG, GIF, PNG, TiFF, etc. An example of a commonly used vector file format is SVG, although several proprietary formats used in more specialized applications can also be extracted. Some file formats encompass a combination of raster image data and vector image data - such as Adobe Portable Document Format (PDF), where text can, for example, be presented in vector form along with raster images.

[0043] As will also be noted, image data may be extracted from the video data as a frame thereof, or some composite derived from the video data that constitutes frames.

DESCRIPTION OF THE DRAWINGS

[0044] Figure 1 is a use case diagram that refers to a conversation hosted on the platform, according to an embodiment of the invention.

[0045] Figure 2 is an additional use case diagram, which refers to the cloud service and the client application.

[0046] Figure 3 is a state machine diagram representing the state of the client application.

[0047] Figure 4 is a package structure diagram for the Blrt package.

[0048] Figure 5 is a class diagram for the package structure of Figure 4.

[0049] Figure 6 is a concept diagram for the Blrt file formats.

[0050] Figure 7 is a concept diagram for the Conversation Item class of the Blrt package.

[0051] Figure 8 is a flowchart representing a user updating a Blrt.

[0052] Figure 9 is a diagram of the sequence of events between a user and the server when a Blr is uploaded.

[0053] Figure 10 is a diagram of the sequence of events between a user and the server when a Blr is downloaded.

[0054] Figures 11 to 29 are exemplary user interfaces that illustrate aspects of user interaction with an application on a client device in accordance with a preferred embodiment of the present invention.

DESCRIPTION OF PREFERRED EMBODIMENTS Use case diagrams

[0055] Figures 1 and 2 are use case diagrams of how a user interacts in a conversation and how users interact with the cloud.

[0056] Referring to Figure 1, a user can create a conversation, open a conversation, or schedule a conversation. Creating a conversation involves uploading media, recording a Blrt, and adding users to the conversation. Opening a conversation involves recording a Blrt, adding users to a conversation, commenting on a conversation, renewing the conversation, or marking the conversation. These actions involve interacting with the cloud service, as depicted.

[0057] Referring to Figure 2, a user interacts with the Blrt application by uploading media, viewing a Blrt, commenting on a Blrt or adding users to the Blrt. Recording a Blrt involves using uploaded media. The Blrt application interacts with the cloud service, which hosts Media Assets, Conversations and Users, and is managed by an Administrator.

[0058] In the cloud service, Media Assets receive uploaded media and distribute media to the Blrt application when the Blrts need to be viewed. Conversation receivesBlrtrecorded in the Blrt application and distributesBlrts to the Blrt application to allow users to viewBlrts and comments. In the cloud service, a recording of users is maintained, as updated in the Blrt application by users.

State Machine

[0059] Figure 3 is a state machine diagram that represents states during use of the Blrt application.

[0060] The solid circles represent starting points - which could be when the Blrt app is open by default, when a prototype or URL is open, when a push notification from the Blrt app is open, or when external media is open (such as being stored on a hosting service, e.g. Dropbox).

[0061] As depicted, double-thick bidirectional arrows indicate standard navigation trajectories (which can be easily reversed back).

[0062] The application has no explicit terminal state due to the fact that the user can technically exit the application in or between any state.

[0063] Double circle states are those that hold and wait for user input before transitioning to other states (however, there may be exceptional cases where it will transition on its own, without the user providing input, as if a "push notification" was received to update the settings, and the app then decides to go into maintenance mode).

[0064] In each case, however, the application is opened if a user has not logged in, and the state advances to a Login Screen. Otherwise (if logged in), a user advances to a respective applicable Upload screen.

[0065] If the user opened the application by default, or if there is no conversation to open from a prototype or a URL is open, then an Inbox is presented.

[0066] From the Inbox state, a user can enter and exit the conversation state, or the MyBlrts state, or enter and exit the CreateConversation state, or enter and exit the Archive state. Additionally, when in the Inbox state, the application can enter and exit the Profile Screen state or enter and exit the Share Screen state. The application can switch between the Profile Screen state and the Share Screen state when they are either of them.

[0067] When in the Conversation state, the user can enter and exit the MyBlrts state, enter and exit the BIrtResponse state, or enter and exit the View BIrt state. The application can switch between the BIrtResponse state and the BIrtView state as needed.

[0068] When in the BIrt Response state, the application can enter and exit the Profile Screen state, enter and exit the ShareScreen state, enter and exit the Archive state, or enter and exit the CreateConversation state.

Blrt package structure

[0069] Figure 4 represents a package structure of a BIrt. A BIrt Response is structured in the same way as a BIrt and comprises a combination of Media Assets, an Audio File, Gesture Data. Media Assets comprise constituent media files.

[0070] Figure 5 represents the package structure of Figure 4 in more detail. A BlrtBase class has the following properties and associated types: • createdAt : DateTime • updatedAt : Datetime • changed At : DateType • deleteAt : DateTime

[0071] The subclasses of BlrtBase are: • Conversation • Conversationltem • MediaAsset • ConversationUserRelation

[0072] Conversation comprises the following properties and associated types: • name : column • thumbnail: MediaFile • items []: ConversationItems [] • hasConversationStarted : bool • creationType : int • statusCode : int • specialConversationSlug : column

[0073] ConversationItemcomprises the following properties and associated types: • argument: column • type: int • ConversationIndex: int • conversation: Conversation • media: MediaAsset []

[0074] Furthermore, Conversation has the following method: • translateArgument()

[0075] MediaAsset comprises the following properties and associated types: • name : column • file : MediaFile • format : int

[0076] ConversationUserRelationcomprises the following properties and associated types: • user: User • Indexes seen: int []

[0077] Conversationltem also comprises the following subclasses: • Commentltem • Blrtltem • Requestltem • EventItem

[0078] Commentltem comprises a "comment" property with "column" property, while Blrtltem comprises the following associated properties and types: • audioLength: int • audio: AudioFile • touch: TouchFile

[0079] Eventltem has subclass AddUserEventItem, which comprises an "Added Relation" property that has type ConversationUserRelation.

[0080] Figure 6 is a concept diagram of BIrt file formats and represents the following components and their properties: • BIrt - ObjectID - Conversationlndex - Argument • MediaAsset - Objectld - Name - Format • MediaFile - Size - Name - Data • BlrtAudio - Size - Name - Data • PagelndexList - TotalPageCount • PageIndex - Page - MediaObjectld - PageOnMedia

[0081] Associations between components are as follows. A BIrtusaMediaAssets, which contains a MediaFile. A BIrt can contain a BIrtAudio and a GestureData. A BIrt also has a PagelndexList, which comprises a MediaAssets indexing Pagelndex.

[0082] Figure 7 is a concept diagram for a Conversationltem. The same components as in Figure 6 are used, with the addition of: • Conversationltem - Objectld - Conversationldex - Argument • Conversation - Objectld - Name - Thumbnail - ItemCount • ConversationUserRelation - Objectld - User

[0083] Associations between components are as follows. A Conversationltempo containing BIrtAudio and GestureData. A conversationltemusaMediaAssets, each of which contains a MediaFile. A Conversation contains a Conversation, which is usable by a ConversationUserRelation.

[0084] Figure 8 is a flowchart of steps (in simplified overview) involved in using the BIrt application by a user. First, a user selects a media file and performs an action on the selected media file in a preview screen. A determination is made as to whether additional media files can be added. A user can select another media file, in which case a determination is made by the application whether the media wrapper is within its size limit. If it is, the media is not added, otherwise the media is added.

[0085] Once the media files are selected and no additional media files are added, the user clicks "next" and opens a Blrt registration screen in the application.

[0086] The use of actual screen may be separately specified, as necessary and indicated.

[0087] Once the registration screen opens, transmission of media wrapper content begins until the upload transfer is completed. Subsequently, once audio, media, and touch data have been uploaded, an object is created in the cloud linking the three: a Blrt message. An indication is provided to the user that the data has been uploaded.

[0088] As described above, the registration screen is used, however, necessary, and once completed, the user presses the save button. Typically, upon completion of using the registration screen, the media upload is complete, or has at least progressed to some extent. In either case, the ringtone and audio data need to be completed once recorded, and used to construct the Blrt message format in association with the media files.

[0089] Figures 9 and 10 are sequence diagrams representing the interaction between a User, View, Controller and Server that serve to highlight the operation of the static components described above.

[0090] Referring to Figure 9, a user engages a View layer to addMedia and subsequently to startRecording. The View layer then smoothly hooks a Controller layer to uploadNewMedia. Uploaded media passes from the Controller layer to the server through uploadMediaFiles. The server returns to the Controller layer with mediaAssetlds for uploading media files. Subsequently, the user indicates finishRecording to the View layer, and the View layer then smoothly fetches upIoadBlrtData to the Controller layer.

[0091] A series of communications occur between the Controller and Server layer. The Controller layer outputs uploadAudio, and the Server returns audioUrl. Similarly, the Controller layer emits uploadGestures, and the Server returns gestureUrl.

[0092] The Controller layer then requests that the Serve perform creatBlrtObject, and the Server obliges and returns to the Controller layer with a blrtld, which is passed back to the View layer and then to the User.

[0093] Of course, the Server does not need to return to the Controller layer before registration is completed. The createBlrtObject process will wait for it to complete before starting. Additionally, the upload transfer of media files, audio recording, and gesture data is performed asynchronously, which is favorable for service performance.

[0094] With reference to Figure 10, the steps in general use of the Blrt application are described.

[0095] First, the user requests that the View layer perform openBirtApp, and the View layer requests that the Controller layer perform startQueryEngine. The Controller layer then requests the Server to perform getSettings and the Server returns with appSettings. The Controller layer updates the updateDisplay layer. The Controller also requests getlnboxData from the Server, which duly returns the User's InboxData to the Controller layer. The View layer is updated again (updateDisplay, again).

[0096] When a User requests the View layer to perform refreshInbox, the View layer requests the Controller layer to perform runRefreshQuery. The same process follows, with a getlnboxData request made from the Server, and the Server, and the Server returning with InboxData, and then the Controller layer returning to the View layer with updateDisplay.

[0097] When a User requests the View layer to perform openConversation, the View layer requests the Controller layer to perform runConversationQuery. Similarly, the Controller layer requests that the Server perform getConversationData, and the Server duly returns to the Controller layer with ConversationData. The Controller layer seeks to updateDisplay for the View layer.

[0098] Subsequently, the Controller also requests the Server to perform getLatestBlrtContent and getConversationMedia, and the Server returns (respectively) with blrtContents and mediaFiles.

[0099] When a User requests the View layer to perform openBlrt, the View layer requests the Controller layer to perform getBlrtContents. The Controller layer passes this request to the Server, which returns with blrtContents. The Controller later returns to the View layer with openBlrtView for display to the user.

Select Media

[0100] To create a BIrt, a user selects the New BIrt button on the Inbox or My Blrts screen. They first need to select at least one media "page". Media can be: • Images stored on the device • Images taken from the device camera • Images or PDFs downloaded directly from a user's Dropbox account • A predefined image template • Images derived from websites

Media Preview

[0101] Once a media page is selected, it is displayed as a preview. The preview can be zoomed and inspected. This is the Media Preview Screen.

[0102] The user can then add additional "pages" of media. Different types of media can be used together as separate pages in a single BIrt. The user can add as many pages as the user restriction allows (defined by server cloud code based on subscription level). By default, a user can use up to 10 default pages.

[0103] The user can tap the "trash" icon to delete a page that was added to BIrt at this stage. This cannot be accomplished once a BIrt has been saved to the cloud or device.

[0104] Imported PDFs will be imported to use the actual PDF pages as BIrt pages. There is a separate user restriction set for maximum PDF pages as opposed to maximum Blrt pages.

BIrt title

[0105] When a user selects "Next" to confirm their choice(s) for media added as pages to BIrt, they are prompted to generate a title to BIrt. This is mandatory.

[0106] The BIr title will be in the main descriptor of the Blrt content, as well as the subject line of an email.

Dashboard - registration

[0107] The user now sees the "dashboard" screen. The dashboard screen has two main states - record and playback. The dashboard screen in registration status will display the first page of BIrt.

[0108] Media attachments (BIrt pages) begin uploading to the cloud in the background at this time.

[0109] There are, initially, the following interactive elements in the Ul: • Drawing toolbar (tools further described below) • "Back" button - this will return the user to the Media Preview screen • Register button - it will start registering and enable the drawing toolbar • Timeline - there cannot be interaction with it before registering, as there is no reproduction yet • Page selector - it will display the number total pages in Blrt and can be paged before and after registration, as well as during.

[0110] After touching the Register button, Blrt registration starts. Now: • The Record button becomes a Stop button • The playhead starts moving and time starts counting forward • Audio from the device's microphone is recorded • Drawing tools are enabled

[0111] As registration continues, the user can use the available drawing tools. Every action taken by the user is logged locally in a yeast "touch" data file during logging. This includes drawing lines and shapes, pointer movement, screen transformations, page turns, and undo/redo.

[0112] The available drawing tools are as follows: • Pencil Tool - it will draw a line on the screen freehand • Format Tool, which can be one of the following: - Circle Tool - draws a circle on the screen, with width and height defined by dragging - Rectangle Tool - draws a rectangle on the screen, with width and height defined by dragging - Line Tool - draws a straight line on the screen, with start and end points defined by dragging • Point Tool - it will display a "laser pointer" like a circle on the screen when the user presses the finger. When the user lifts their finger, the pointer will disappear • Transform Tool - allows the user to freely zoom in and reposition the screen (this is still possible with other tools selected by dragging or pinching the screen with two fingers) • Color Picker - pulls down to display a color picker. The selected color will be the color of anything drawn with the pencil, shape, or pointer tools • Stroke Weight Selector - Drops down to display the stroke weight selector with three options. The selected weight will be the stroke weight of anything drawn with the pencil or shape tools. • Undo/redo - undoes the previous design change, or redoes it. This does not include page turns, pointing, or transformations.

[0113] When 10 seconds of time allowed for a Blrt remain (a user restriction dependent on subscription level), a large "10" flashes on the screen to indicate that time is running out. When there are 5 seconds left, a big "5" will appear and a countdown will be performed until the remaining time reaches zero. At this point, registration will end.

[0114] A web URL can be selected instead of media in the media selection step. The application will take a scrolling screenshot of the website at that URL and import it as image media. This functionality may extend to cleaning up a web page's HTML/CSS/img package (such as the MHT files used by Internet Explorer), which will be identical or approximately the same size as the website download.

Screen - playback (after registration)

[0115] When recording is stopped, the Ul is now in the playback state (after recording). Ul now includes the following interactive elements: • "Clear" button (replaces the "Back" button) - it will delete the recently made registration and change the screen • to the pre-registration state (after the user confirms this action in an additional drop-down window). • "Register" button (replaces the "Stop" button) - it will continue recording from the current interrupted position. This • will not be visible if the record has already reached the maximum allowed time. • "Play" button - it will play the recording from the beginning. NOTE: Currently, this will mean that you cannot • continue registration again. • Timeline with playhead at stopped position. This is grayed out and not interactive at this stage. • "Save" button - will start the save/send process (detailed below)

[0116] When the "Play" button is pressed, the registered BIrt will play back in real time, with the audio and gestures exactly in sync with how they were recorded. The "Play" button changes to a "Pause" button during playback, which will pause audio and gesture playback and display a freeze frame of the record at the time of pause. In the playing state, the playhead can also be dragged to "debug" via the registered BIrt. Pressing "Play" will continue playback from the playhead position.

To save

[0117] The "Save" button appears on the Ul after recording is stopped and will also appear when the screen is in the playback state after recording. By pressing the "Save" button: • a BIrt object is created in the cloud • A relationship between the BIrt object and the media (already uploaded during the registration phase) is created • Data upload begins audio and gesture to the cloud.

[0118] Upon pressing the "Save" button, the user immediately sees the "Send" screen. This is an automatic triggering window (popup) at the top of the dashboard screen.

"Send" screen

[0119] The "Send" screen contains the following UI elements: • "To" field - this is where the user can add initial recipients for the BIrt. This can be done in one of the following ways: ¦ Enter an email address manually in the "To" field, followed by a comma character or return to confirm. ¦ Start typing an email address or name in the "To" field. An auto-trigger window will appear as the user types to automatically search for related contacts from the various sources presented below. ¦ Press the "+" button, which will bring up an automatic Contacts window. This auto-trigger window can be filtered as follows: ¦ - All contacts in alphabetical order ¦ Recent - contacts saved locally on the device based on who has recently been in contact with the user through BIrt. This includes all users or email addresses that were in the same BIrt conversation as the user at any point in time. ¦ Device Contacts (named iPad or iPhone depending on the device) - all saved locally in the iOS device's built-in Contacts app. You must authorize the Blrt application to access these contacts, which is requested from the user the first time the automatic contact activation window is opened. ¦ Facebook - list of the user's Facebook "friends" if the user has linked their Facebook account to their Blrt account ¦ Permissions need to be granted when the user first logs into Facebook to allow Blrt access to their list of friends. ¦ LinkedIn and other social media platforms - the application allows users to link their accounts to other online services in a similar way to Facebook. • Blrt Title field - it will be filled with the Blrt Title specified in the step between the Media Preview and Panel Screens. This is an opportunity for the user to edit the Blrt Title before adding users to the Blrt conversation. • Add a Note - this is an optional field. The user can enter a "note" in this field, which will be added as a Blrt Conversation Event, and will be added to the email notification sent to Blrt recipients. • Upload progress bar - this bar shows the user the progress of the upload of Blrt's media, audio and gesture components. When this progress bar shows 100%, then the Blrt three-key components have been successfully uploaded to the cloud. • Cancel • Submit

[0120] If the upload of media attachments is not completed during the registration phase, this upload is completed as part of this step before the audio and gesture data is uploaded to the cloud.

[0121] The "Cancel" and "Submit" buttons on the "Submit" screen are disabled while data is uploaded. If the upload times out, or fails (due to any reason, usually due to loss of Internet connection), the user is given the opportunity to: • Retry - the application will attempt to upload the remaining data that has not yet been uploaded. • Save - all files are cached locally on the device. Cached blrts will be documented in another section. • Cancel - all BIrt components - media, audio and gestures - will be erased and the user is taken back to the "Inbox" screen.

[0122] Once the data has been 100% uploaded, the BIrt object is created successfully and is completed in the cloud. The "Cancel" and "Submit" buttons on the "Submit" screen can now be used.

[0123] If the user taps "Cancel" at this stage, the user returns to the conversation screen for the newly created Blrt conversation (with the user being the only user in the conversation). Due to the completion of the upload transfer, the BIrt object was successfully created in the cloud.

[0124] If the user taps "Send", the application checks the recipient(s) in the "To" field: • Manually entered email addresses must adapt to the regular expression of an email address valid. If one or more does not, the user is prompted to fix the error. • It is necessary that the number of recipients does not exceed the maximum number allowed by the user restriction on the user's account type. If this is exceeded, the user is asked to remove recipients until the number of recipients is within the permitted range.

[0125] If the email addresses (or Facebook IDs) of the specified recipient(s) validate successfully, the server will check whether BIrt accounts already exist for the specified email addresses .

[0126] If an email address or Facebook ID matches a BIrt account registered in the database, a relationship is created between that BIrt conversation and the recipient's BIrt account, giving the recipient permission to access this BIrt conversation and this BIrt object. An email notification and a push notification are generated for the recipient once the relationship has been established.

[0127] If an email address or Facebook ID does not successfully match a registered BIr account in the database, a user object is still created. A relationship between this BIrt conversation and the recipient's user object is created. This can be found later at the point of registration, so that the recipient has the ability to see this BIrt conversation even if they sign up after receiving it. If a user object has already been created for that email address or Facebook ID (such as when a given email address or Facebook ID was added to multiple BIrt conversations before signing up for a BIrt account), then a relationship is created between that BIrt conversation and the existing user object.

[0128] In the case of an unregistered recipient, an email notification is generated that uses a specific template.

[0129] Once appropriate relationships have been established between the BIrt conversation and all specified recipients, a confirmation is displayed to the user. The user can then select "Ready" to be taken to the conversation screen for the recently created BIr.

BIrt Conversations Conversation screen

[0130] The conversation screen displays the following elements related to the specific BIrt conversation being viewed, in chronological order of creation date/time:

[0131] Other UI elements in the conversation screen are: • "Back" button - returns the user to the "Inbox" or "My Blrts" screen, depending on where the user is coming from • Blrt Title - displays the title of the conversion of Blrt that is seen • Renew - forces the Blrt conversation to capture any new content from the server related to this Blrt conversation and refresh the conversation screen • "Add people to Blrt" button. This will bring up the "Send" screen as an auto-trigger window. It will work in the same way as the "Submit" screen which creates an auto-trigger window on the dashboard screen after saving a Blrt, but the Blrt title cannot be changed. The user can add a note, which will be included in email notifications and will appear as a separate event in the conversation. When new users are added to the Blrt conversation, an event will be displayed in the conversation. • "Manage labels" button. This will bring up an auto-launch window identical to the "Manage Tags" auto-launch window in the "Inbox" screens, detailed in the File and Tags section. • "Filterbypeople" button. This will bring up the auto-triggered "Filter by people" window, which displays a list of users by conversation names and email addresses. These are separated into registered users who have viewed the conversation, registered users who have not yet viewed the conversation, and other users who do not have a registered Blrt account. A user's tap on this auto-trigger window will filter all elements on the conversation screen to display only those elements created by that user. Multiple users can be selected in the filter. The filter can be deleted with the "Delete" button in the automatic activation window. • "Reply Blrt" button - takes users to the dashboard registration screen to create a ReplyBlrt. • "Comment" box - when touched, the keyboard is suspended for the user to enter a comment.

Comments

[0132] When the comment at the bottom of the chat screen is tapped, the device's native on-screen keyboard will hover upward, allowing the user to enter a text comment.

[0133] After the comment text has been entered, the user can add it to the conversation by tapping the "Send" button. This will immediately save the comment locally on the device and display it as a new element at the bottom of the conversation. It will also immediately begin uploading to the cloud.

[0134] As the comment is uploaded to the cloud, a "Loading" icon is displayed along with the element. This will continue to upload in the background if the user leaves the chat screen. Once the comment has been uploaded to the cloud correctly, it will be visible to other users in the conversation. It will deliver a push notification to all users in the conversation, and an aggregated email notification generated at most once per hour.

[0135] If the comment fails to upload for any reason, a "Red Cloud" icon will be displayed along with the comment element to indicate that the comment is stored locally, but not in the cloud. This icon can be tapped to retry the upload.

Blrt's Answers

[0136] By tapping the "Reply Blrt" button at the top right of the conversation screen, a user can create a Blrt using the same media attachments as the original Blrt in the conversation, called a Reply Blrt. When the "Blrt Reply" button is tapped, the user is taken to the dashboard registration screen with the media attachments for this pre-loaded Blrt conversation. These media attachments do not need to be uploaded to the cloud again at any point during the creation of a Blrt Response.

[0137] The panel registration screen for a Blrt Response is identical to the panel registration screen under creating a New Blrt and works the same except for the "Save" Button. The saving process is different for a Blrt Reply as opposed to a Blrt. Upon tapping the "Save" button: • The user is immediately returned to the conversation screen • The BlrReply element is immediately displayed as a new item in the conversation, with a "Loading" icon next to it • Gesture and audio data begin uploading to the cloud

[0138] The user is not restricted from performing any other action during any stage of the save process.

[0139] When the gesture and audio data for the Blrt Response has been uploaded to the cloud correctly, the "Uploading" icon along with the Blrt Response element disappears.

[0140] This indicates that Blrt's Response is in the cloud and will be visible to other users in the conversation. A push notification and email notification is generated for all other users in the conversation when Blrt's Reply has been uploaded correctly.

[0141] If the Blrt Response fails to be uploaded for any reason, a "Red Cloud" icon will be displayed along with the Blrt Response element to indicate that the Blrt Response is stored locally, but not in the cloud. This icon can be tapped to retry the upload.

"Blrt Inbox" Screens Inbox

[0142] The Blrt Inbox screen displays all Blrt conversations that the current user has permission to access, ordered by when each conversation was last updated.

[0143] The "Inbox" screen (as opposed to "My Blrts" or "Archive") displays only conversations that contain at least one conversation item from a user other than the current user. The Ul for this screen contains the following items: • "File" button - takes the user to the Archive screen. • Blrt logo and "Inbox" header • "Filter by tags" button - this will bring up the "Filter by tags" auto-trigger window. The user can select from a list of all tags used by any conversation that • appears on this screen. Selecting tag(s) will filter the inbox screen to show only conversations that contain the selected tag(s). Touching the 'Delete' button in this automatic trigger window will remove the selection from all labels. If the inbox is currently being filtered by tag(s), the "Filter by tags" icon will be displayed in red. • "Filter by people" button - this will bring up the automatic "Filter by people" window. The user can select from the list of all users who have been added to any conversation that appears on the screen. Selecting one or more users will filter the inbox screen to show only conversations that the selected user(s) have added. Tapping the "Delete" button in this auto-trigger window will remove all users. If your inbox is currently being filtered by people, the "Filter by people" icon will be displayed in red. • "New Blrt" button - this will start the Blrt creation process described in "Create a Blrt".

[0144] Each Blrt conversation listed in the inbox screen has the following elements: • "Page" icon - displays the page count in the Blrt • Thumbnail - thumbnail-sized image of the first page of the Blrt (no markup) • Blrt Title - displays in red with a red circle on the left if there are unread items in conversation • Text that displays "New from <user>" if there is an unread item in the conversation, otherwise "Started by <user who created Blrt>". • Timestamp when the conversation was last updated • "Cloud" icon, in one of the following states. Tapping the icon reveals an auto-trigger window explaining the meaning of the icon. • Gray Cloud with thin dots - indicates that there are one or more items in the conversation that are uploaded to the cloud but have not been downloaded to this device • Gray Cloud with check mark - indicates that each item in the conversation is uploaded to the cloud and has also been downloaded to this device • Red cloud with exclamation mark - indicates that there are one or more items in the conversation that have been created and saved locally (cached) but have not yet been uploaded to the cloud, or that no one other than the current user has been added to the conversation • "Manage Tags" icon - tapping reveals the automatic "Manage Tags" window " • "People" icon - tapping reveals an auto-trigger window with a comma-separated list of users in the conversation • Item Count - speechbubble icon that displays the total count of items in the conversation (not including events). A small red circle with the number of unread items is also displayed above this icon if there are any unread items.

[0145] Tapping a Blrt conversation on the inbox screen, anywhere besides the cloud, the "Manage Tags" or "People" icons, will take the user to the conversation screen for that Blrt.

[0146] If there are no Blrt conversations on the inbox screen (such as if all conversations have been archived), a graphic image prompting the user to create a Blrt is displayed instead.

My Blrts

[0147] The "My Blrts" screen is accessible from the tab bar at the bottom of the application. My Blrts has identical functionality and appearance to the "Inbox" screen, with the only difference being the conversations it displays. The "My Blrts" screen only displays conversations created by the current user. Marking

[0148] Tagging functionality exists to add short text "tags" to Blrt conversations to use as a customizable filter on inbox screens. Tags are added and removed via the auto-triggered "Manage Tags" window, which can be accessed via the "Manage Tags" icon in a conversation in the conversation list in the inbox, or via the "Manage Tags" icon in the header from the conversation screen. The "Manage Tags" automatic trigger window has identical functionality regardless of which screen it is accessed from.

[0149] The "Manage Tags" auto-trigger window lists tags that are attached to the Blrt conversation. Tags are stored as an array in the Blrt object in the cloud.

[0150] A new tag can be added by tapping and then typing in the text box at the bottom of the "Manage Tags" auto-trigger window. The user can then tap the "Add Tag" button to add the tag to the list. The tag will be uploaded to the tag matrix in the cloud immediately, which is part of the relationship between the conversation object and the user object, if there is a loss of Internet connection, the change to the tag matrix will be uploaded to the cloud the next time the device regains a connection of Internet.

[0151] Tags can be removed from the Blrt conversation by tapping the tag object to remove the selection in the "Manage Tags" auto-trigger window. The user has one chance to reselect the tag before closing the "Manage tags" auto-trigger window. When the "Manage Tags" auto-trigger window is closed, any unselected tags will be removed and will no longer appear in the list.

[0152] Any tags selected or created will only be visible and will have no effect on the current user. It will have no effect on how any other user views or interacts with a Blrt conversation.

[0153] There are two special labels in the "Manage Labels" auto-trigger window - "File" and "Flagged". These tags are deselected by default and will always appear at the top of the tag list in the "Manage Tags" auto-trigger window for any Blrt conversation.

File

[0154] Although a user cannot permanently delete a Blrt conversation, if a user wishes to move away from their Inbox/My Blrts screen, they can move the conversations to the "Archive" screen. Blrts are archived by selecting the special "Archive" tag in the "Manage tags" automatic trigger window.

[0155] When the "File" tag is contained in the tag array in the relationship between the user object and the conversation object, this Blrt conversation is not displayed on the Inbox / My Blrts screens. These Blrt conversations are only visible in the "File" screen, which is accessible via the "File" button in the Inbox / My Blrts screen.

[0156] The "File" screen is the same regardless of whether it is accessed from the Inbox or My Blrts screen. All conversations marked with the "Archive" tag will be shown.

[0157] A conversation can be moved back to the Inbox/My Blrts screen by opening the "Manage Tags" auto-trigger window for that conversation and deselecting the "File" tag. The label change will take effect when the "Manage labels" auto-trigger window is closed.

Signaling

[0158] A Blrt conversation can be "Flagged" as the "Flagged" tag is selected in the "Manage Tags" auto-trigger window.

[0159] When a Blrt conversation is Flagged, it appears in another section above all unflagged Blrts on the Inbox / My Blrts / Archive screens. This section has a red bar that stretches across the screen, which is not visible if there are no flagged conversations on the screen that is viewed. Flagged conversations also have a flag icon to the left of the Blrt title, and a brighter background.

User profiles, account types and subscriptions Profile Screen

[0160] The profile screen is accessible via the tab bar at the bottom of the application, and contains the user's settings, account details and profile.

[0161] The Ul elements on this screen are as shown below, in order: • Feedback & Support Link - opens an automatic support hub window where users can search the Blrt knowledge base and send support or feedback requests to the Blrt team. • User profile section - displays all fields of a user profile, and an "Edit" button that allows the user to edit any of the following: o Email - primary email address for account o Display name - such as username is displayed to other users o First Name o Last Name o Gender o Organization o Industry o Password • Facebook Section o If the user has a Facebook account connected to their Blrt account, this section will display the Facebook user name and a "disconnect" button ". o If the user does not have a connected Facebook account, this section will display a "Sign in with Facebook" button • Blrt What's New - searches a JSON file at a specified URL in the database to render what's new items, each with a title, thumbnail, description and optional link. This is renewed every time the Profile Screen is opened. • Account section - detailed in the following section "Account Types" • Settings section o Notification settings - slides to a new screen where the user can toggle if they wish to receive email notifications for: ¦ New Blrts ¦ Blrt Requests ¦ Blrt Replies ¦ New Comments (email summary only sent a maximum of once per hour) o Device Settings o Show help overlays again - toggling this will enable the "help overlays" to be shown once again to the user o Version - displays the application version number • Exit - exits the user from the application and returns the user to the entry screen.

Account types

[0162] All Blrt user accounts have an Account Type, which determines the user's permissions and maximums for various features of the Blrt application. The features that are affected by Blrt Account Types are: • Maximum Blrt Duration - the maximum length of time for a single Blrt or Blrt Reply by the user • Maximum Conversational Users - the maximum number of users that can be added to a conversation (a given conversation will be restricted by the account maximum for the conversation creator) • Maximum Media Size - the maximum file size in MB for a single "page" of media (or an entire PDF) that can be transferred by uploaded by user. • Maximum Image Resolution - the maximum resolution in pixels that an uploaded image can have before being resized by the application • Maximum Images - the maximum number of "pages" of image media for a created Blrt (this does not include PDFs) • Maximum of PDF pages - the maximum number of pages an uploaded PDF can contain

[0163] Even if a user account type does not have a certain permission, the user can still see Blrts or conversations that were created by a user who does not have the permission, or had the permission when the conversation was created. For example, if a user account type allows Blrts to be only one minute long, it may still receive and view a Blrt sent by a user with an account type to allow three minutes to last.

[0164] Restrictions and account types are defined in the database, and thus are not hard-coded into the application. Existing account type and restrictions can be edited by Blrt Administrators and new user account types can be created by Blrt Administrators. There is a default account type that all new accounts will automatically use (on startup, "Blrtfree"). Accounts can be manually upgraded on an individual basis to other account types by Blrt Administrators, or upgraded through a subscription or free trial (detailed in the next section). Example account types and resource restrictions

Subscriptions and free trials

[0165] The default account type for all new users is the "Free" account and does not expire. If a user finds the permissions on the free account type too restrictive, they may be encouraged to upgrade their account to "Blrt Premium". The default path for a user to improve their account is through ProfileScreen.

Free trials

[0166] The Account section on the Profile screen displays a user's current account type, subscription expiration date (if applicable), and feature restrictions. If a user is on the "Free" account type, there is a button to start a free trial of Blrt Premium. When the user selects the free trial option, no purchases or subscriptions are made. The user is immediately upgraded to another account type "Blrt Premium Trial", which has the same user restrictions as Blrt Premium. The database is updated to change the account type of the user object and the "expiration date" field is set to 30 days accordingly.

[0167] As the user approaches the free trial expiration date, the user receives timed notifications (in app dialogs, push notifications, and email notifications) that remind the user to make a payment to subscribe in order to to maintain additional permissions provided by Blrt Premium.

[0168] If the user account has already used a free trial of Blrt Premium in the past, regardless of whether it has also previously subscribed to a paid subscription, it will be unable to obtain a free trial again.

Premium Subscription

[0169] The user can make a payment at any time through the profile screen to begin their paid subscription to Blrt Premium. Tapping the "Activate Subscription" or "Get Premium" button (depending on whether you are currently on the free trial) will prompt an in-app purchase dialog. The user can then choose the duration of their Subscription from in-app purchase objects defined by the Blrt Administrators (at startup there will only be the option to purchase an annual Subscription). Despite being referred to as a Subscription, the in-app purchase is implemented as a one-time non-renewable purchase made through the user's iTunes account (for iOS).

[0170] Once the payment has been confirmed, the user account type and expiration date on the user object in the database are changed accordingly. If the user still has time left in their free trial, those days are added to the subscription duration.

Account expiration

[0171] In the user object in the database, there is an expiration date field along with the user's current account type. This defines when the user's current account type will "expire." When a user's account type expires, the user is immediately downgraded to the standard account type (Free Blrt).

[0172] The account expiration date may trigger email and push notifications, and in-app dialogs at the time of expiration, or specified amounts of days in advance.

Premium Renewal

[0173] When a Premium subscription has less than 30 days remaining before the expiration date, the user is prompted at various intervals to renew the subscription. Since the in-app purchase deployment is a non-renewable product, the user needs to accept payment again. Once payment has been confirmed, the purchased subscription period is added to the expiration date field for the user.

Maintenance Mode

[0174] Blrt Administrators, through cloud code, have the ability to enable "maintenance mode" for all users or selected users of the application, based on criteria. This can be useful for server maintenance, older incompatible versions of the application, or any unforeseen circumstances that require user access to be temporarily (or permanently) disabled.

[0175] There are multiple maintenance mode modes that can be enabled:

Partial blocking

[0176] Partial lock maintenance mode allows users to browse and view Blrts, Blrt Replies, conversations, and comments that have already been downloaded, however, they are unable to create content or do anything that requires the server or database is updated or cloud code is executed. An alert message is given to the user to indicate that the user is temporarily unable to create content (Blrts, Blrt Replies, conversations and comments). Another alert is given to the user once the partial block is lifted.

[0177] Partial blocks can be applied to specific users, groups of users, or all users.

Total lock (maintenance}

[0178] Full lock maintenance mode completely disables application functionality and replaces it with a screen with a maintenance message defined in cloud code. The user is completely unable to use any functionality of the application when this mode is enabled. When the mode is disabled, a push notification is sent to all disabled devices to ask them to renew and restore the app's functionality.

[0179] Full Lock (maintenance) can be applied to specific users, groups of users, or all users.

Total blocking (invalid version)

[0180] If Blrt Administrators determine that an old version of the application is incompatible with the current database, they can define a field in the database for the limit of allowable application versions. If an application of any version below the threshold attempts to make a request to the server, full block maintenance mode is employed with a message that urges the user to update the application.

[0181] Full blocking (invalid version) is controlled by the permissible application version limit and cannot be manually enabled for specific users or groups of users.

Blrt local and cloud caching Blrt cached after failed upload

[0182] After registering a new Blrt and tapping "Save", the user sees the progress of uploading media, audio and gesture data. If this fails at any point before the full successful upload (100%) due to loss of connection or other reasons, the user can choose to save the Blrt locally on the device (a cached Blrt).

[0183] Media, audio, and gesture data are saved locally on the device and the user sees a standard Blrt conversation screen. The "red cloud" icon is displayed next to the original Blrt element to signify that it has not yet been uploaded to the cloud. Without the initial Blrt object in the cloud, the entire conversation is not effectively in the cloud, so the user is prevented from adding other users to the conversation until the Blrt has been uploaded.

Integration of Facebook and other services

[0184] Blrt uses the Facebook API to facilitate the following connectivity:

Login with Facebook

[0185] Users can use the "Sign in with Facebook" button on the application login screen to create an account and sign in. On first login, the app will authenticate with Facebook and ask the user about the following permissions: * Basic Default Permissions (includes location, gender and username) * Email address * Friends list

[0186] If a user does not grant these permissions, the user cannot create a Blrt account and will not be able to log in through Facebook.

[0187] If granted, a Blr account is created using the email address for the Facebook account as the username, with a relationship to the user's Facebook ID.

[0188] In the future, signing in with this Facebook ID will automatically log into the correct Blrt account.

[0189] A user can manually connect or disconnect a Facebook account from a particular Blrt account at any time through the Profile screen. Disconnecting your Facebook account will mean that you can no longer log in through Facebook, cannot use your Facebook contacts in the app, and therefore need to log in to Blrt using your email address and a password set upon disconnection.

Facebook Contacts

[0190] As access to the user's Facebook friends list is granted during Facebook connection, Blrt is able to cross-reference these Facebook IDs with IDs that share relationships with other users in Blrt's user database. In other words, the Blrt app can display a list of Facebook friends of a user who also has a Blrt account.

[0191] This means that Facebook can be used as a method of adding users to a conversation. On the "Send" screen, when the user defines recipients, a list of the user's Facebook friends who also have a Blrt account will be listed and Blrt will automatically add the corresponding Blrt user accounts to a conversation if Facebook users are selected. Those users will receive push notifications on their device and email notifications on their primary email address.

[0192] In the future, the Blrt application may also be able to use the Facebook API to send application-generated messages to Facebook users who do not yet have a Blrt account. In this case, all of the user's Facebook friends will be displayed in the recipient selection list, not just friends with existing Blrt accounts.

Other services

[0193] Many third-party services and social networks have APIs similar to Facebook to authenticate input and grant application permissions to user data. Examples of possible integration for entering and sending contacts are Linkedin, Google+ and Twitter. Contact list integration will be implemented in a similar way to Facebook, with the user able to connect multiple services and filter their contact list by each one.

Blrt API

[0194] Both the Blrt application and the Blrt Cloud will have their own API to enable connectivity to and from other software to create Blrts, update conversations, upload media, and more. Below are two possible examples that could utilize the Blrt API to extend functionality.

Customize Blrt Email Addresses

[0195] Each Blrt user will be granted a unique, automatically generated email address such as name_33333@Blrt.co. This email address will not be known or identifiable by anyone other than the user (except when the user deliberately shares it with others).

[0196] The user will be able to send emails to the unique email address to easily create Blrts. • Sending media files as an attachment with no subject or content in the email will allow the user to use those attachments to create a Blrt the next time they launch the Blrt application • Sending media files as an attachment with another user's email address in the subject line will create automatically sends a Blrt Request to the specified email address • Adding content to the email itself will generate a note added to the Blrt Request

Connectivity with project management software

[0197] Popular project management/Issue Tracking software, such as JIRA, allows third parties to publish plugins to extend their functionality and enable connectivity with other services. A JIRA plugin could be created that allows users to create a Blrt directly from media attached to a JIRA issue, or attach/link an existing Blrt to a JIRA issue for easy future reference.

Example user interface

[0198] Figures 11 to 29 comprise a series of screenshots illustrating an exemplary user interface (and use) of the Blrt application, running on an iPad, produced by Apple, Inc. The application may be provided for other devices hardware and operating system platforms as necessary.

Example image

[0199] Figure 11 represents a screenshot of the application, when the user is viewing "MyBlrts" • essentially their Inbox. Subsequent Figures 12 through 18 represent some screenshots associated with the construction of a new Blrt using an image.

[0200] The user in Figure 12 has clicked a "New Blrt" button to begin the process of producing a new Blrt message. As depicted, the user is given the option to create a new Blrt using a variety of sources, including: • Camera • Photo Gallery • Dropbox • Box • SkyDrive • Google Drive • Website • Templates

[0201] Figure 13 represents a screenshot, in which the user selected the photo gallery in Figure 12, resulting in the "Camera Roll" appearing in a window, to make a selection of images locally stored on the iPad.

[0202] Figure 14 represents that an image available from the Camera Roll is selected and displayed in full screen in "Preview". The user is given the option to add numerous additional images to build the BIrt, in the same way that the first image was added.

[0203] Figure 15 represents a screenshot in which the user is asked to "Add BIrt Name" in a "Name Your BIrt" window. This is essentially an individual in the direction of Blrt's message.

[0204] Figure 16 represents a screenshot in which the image is previewed, and a dot (red) is provided on the lower left of the interface to invite the user to start recording the BIrt message, after having named the prospective BIrt.

[0205] Figure 17 actually represents a screenshot once this process is underway (for 14 s) using the image of a previous bridge selected from the Camera Roll. Audio is recorded and the interface provides a palette of tools that can be used as needed by the user in conjunction with audio narration to convey the content desired by the user. The tool palette may comprise a selection of pens, shapes, icons, cursors and pointers of different thicknesses, colors, shapes and configurations as required. The image can be stretched, zoomed, and rotated as needed using touch gestures for the iPad screen. Suitable tools and options can be selected and used by touch gesture. Other client devices that lack touch gesture input may use a mouse of other means of input to construct this attached gesture annotation.

[0206] Figure 18 represents a screenshot of subsequent records, in which the user enlarged, in this case, the image to crop some peripheral material to focus on a detail of the bridge. In this Blrt, the user paid attention to a structural mast of the bridge, firstly through the zoom functionality, and secondly, by surrounding this detail and, furthermore, through the use of an attached arrow.

Website example

[0207] Figures 19 to 21 represent screenshots in which third-party websites are used in constructing Blrt messages. Figure 19 represents a screenshot in which a URL address bar (default populated by google.com) is presented for use by a user to enter or search for a website that the user wishes to display their Blrt.

[0208] Figure 20 represents a Wikipedia entry for "The Beatles", in which the user circles and notes the title of the Wikipedia entry to accompany the Blrt audio narration.

[0209] Figure 21 is a screenshot of a Blrt under construction, featuring a website that displays a map of Sydney Harbor. The user drew attention with the use of pen tools to the Sydney Opera House, as well as a road to the north of the Sydney Opera House. For greater clarity, the user scribbled "water" in the port to make it clear what is land and what is water on the map. The attached audio describes a proposed walk and subsequent destination for a group of recipients.

To address

[0210] Figures 22 to 27 represent various screenshots associated with addressing aspects of Blrts.

[0211] Figure 22 returns to the previously created Blrt (with reference to Figures 11 to 18) and, upon registration completion, presents a window titled "Add People to Blrt" inviting the user to add users who are about to receive the Blrt. The underlying image was uploaded during Blrt registration and the audio data and gesture data are in the process of being uploaded as the user embarks on selecting recipients for the newly created Blrt.

[0212] Figure 23 represents a screenshot in which the user selects, in an interface, an element that allows access to the user's "Contacts", and presents a paging list of contacts for selection, which can be filtered as: All, Recent, iPad. Facebook or Link.

[0213] Figure 24 represents a screenshot in which the user selected, in this case, to preview the named contact ("Bruce Banner") from this contact list. Figure 25 represents an additional screenshot, where a list of recipients is under preparation. Figure 26 represents the Blrt being sent, as indicated by a window titled "Send to", and an attached "hourglass" style icon. Figure 27 represents a screenshot showing a confirmation window that presents a list of Blrt recipients.

Conversations

[0214] Figures 28 and 29 represent screenshots illustrating example conversations within the Blrt application. Figure 28 represents a screenshot depicting that a source Blrt is represented from "Tracy McGrady" on the top right, followed in the response below the panel by a return comment from "Jane Hester", and a Reply of Blrt that depicts the same image. 'Brad' contributed a comment and then Tracey McGrady responded in turn with her own Blrt Reply in response to Jane and Brad.

[0215] Figure 29 depicts an additional screenshot similar to that of Figure 28, in which a user has selected an interface element to view and optionally add "tags" associated with the conversation thread of Figure 29. These are displayed in a window titled "Manage Tags".

System topology

[0216] Figure 30 depicts a topology that allows users to communicate data, while reducing the bandwidth associated with transmitting the media. Topology 100 may include a logical server 110, first client computing device 120, and second client computing device 125. The elements represented in topology 100 may be coupled to each other communicatively over network 130.

[0217] Network 130 may be a wired or wireless network, such as the Internet, an intranet, a LAN, a WAN, a cellular network, or another type of network. It will be understood that network 130 may be a combination of multiple different types of wireless or wired networks. Network 130 may also comprise telephone lines, fiber optic cables, internet cables, microwave transmission links, cellular networks, communications satellites, submarine telephone cables, which may be interconnected by switching centers.

[0218] The first client computing device 120 may be a laptop-type computer, desktop computer, smart phone, tablet-type computer, personal data assistant, or any other type of device with a hardware processor that is configured to process instructions and connect to the network 130 to communicate with the logical server 110. The first client computing device 120 may include a memory device, a graphical user interface, and a presentation device. The memory device may be a device that stores data generated or received by logical server 110, such as a data packet corresponding to a presentation. The memory device may include, but is not limited to, a hard disk drive, an optical disk drive and/or a flash memory drive. In embodiments, the memory device may be configured to store information received from the second client computing device 125 and/or logical server 110. The user interface may be a device that allows a user to interact with a first client computing device 120, with a second device client computing interface 125 or with a logical server 110 over a network 130. Although a user interface is shown, the term "user interface" may include, but is not limited to, a touch screen, a physical keyboard, a mouse, a camera, a microphone, and/or a speaker. The presentation device may be a hardware processor that may receive information configured to be displayed in the user interface of the first client computing device 120. For example, the presenting device may receive a data packet from logical server 110 and may display elements of the data packet to the user of the first client computing device 120. Using the user interface, a user may perform actions to create a presentation that includes a data package, wherein the data package may include media data, gesture data, and/or audio data. For example, the user may obtain a picture to create media data, perform actions on a screen to record gesture data, and/or speak to create audio data. In embodiments, the first client computing device 120 may be configured to generate a presentation that may be configured to be received by and played back on the second client computing device 125.

[0219] The second client computing device 125 may be a laptop-type computer, a desktop-type computer, a smart phone, a tablet-type computer, a personal data assistant, or any other type of device with a hardware processor that is configured to process instructions and connect to the network 130 to communicate with the logical server 110. The second client computing device 125 may include a memory device, a graphical user interface, and a presentation device. The memory device may be a device that stores data generated or received by logical server 110, as a data packet. The memory device may include, without limitation, a hard disk drive, an optical disk drive, and/or a flash memory drive. In embodiments, the memory device may be configured to store information received from the first client computing device 120 and/or the logical server 110. The user interface may be a device that allows a user to interact with a first client computing device 120, with a second device client computing interface 125 or with a logical server 110 over a network 130. Although a user interface is shown, the term "user interface" may include, but is not limited to, a touch screen, a physical keyboard, a mouse, a camera, a video camera, a microphone and/or a speaker. The presentation device may be a hardware processor that may receive information configured to be displayed in the user interface of the second client computing device 125. For example, the presenting device may receive a data packet from logical server 110 and may display elements of the data packet to the user of the second client computing device 125. Using the presentation device, the second client computing device 125 can be configured to receive the data packet to reconstruct the presentation locally on the second client computing device 125.

[0220] Logical server 110 may be a computing device, such as a general hardware platform server configured to support mobile applications, software, and the like running on the first client computing device 120 and/or the second client computing device 120. Logical server 110 may include physical computing devices that reside in a particular location or may be positioned in a cloud computing network environment. In this description, "cloud computing" can be defined as a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned through virtualization and released. with minimal management effort or service provider interaction and then classified accordingly. A cloud model may be comprised of several features (e.g., on-demand self-service, wide network access, resource pooling, rapid elasticity, metered service, etc.), service models (e.g., Software as a Service ("SaaS"), Platform as a Service ("PaaS"), Infrastructure as a Service ("laaS"), and placement models (e.g., private cloud, community cloud, public cloud, hybrid cloud, etc.). Logical server 110 may include any combination of or more computer-usable or computer-readable media. For example, logical server 110 may include a computer-readable medium that includes one or more of a portable computer floppy disk, a hard disk, a random access memory device (RAM), a read-only memory device (ROM), an erasable programmable read-only memory device (EPROM or Flash memory) , a portable compact disk read-only memory (CDROM), an optical storage device, and a magnetic storage device.

[0221] In embodiments, the logical server 110 may be configured to receive data from the first client computing device 120, to determine what data is stored on the second client computing device 125, and to transmit data to the second client computing device 125 that is not locally stored on the second client computing device 125. client computing device 125. The logical server 110 may be configured to receive a data packet from the first client computing device 120, wherein the data packet may include data that is stored in various formats, such as audio data, gesture data, and media data. The data formats within the packet may have different memory sizes, which require varying amounts of bandwidth to transmit to different network elements over the network 130. Therefore, the logical server 110 may reduce the amount of bandwidth required to transmit the data packet over the network 130, only by transmitting data that requires higher bandwidth (for example, media data) to the second client computing device125 once. For example, logical server 110 may be configured to determine whether media data received from the first client computing device 120 is stored locally on the second client computing device 125 and to transmit the media data to the second client computing device 125 if the media data are not stored locally on the second client computing device125.

[0222] The logical server 110 may also be configured to transmit audio data and/or gesture data as received from the first client computing device 120 to the second client computing device 125. Therefore, audio data and/or gesture data may be transmitted to the second client computing device 125 in an asynchronous manner. As a user on the first client computing device 120 creates audio data and/or gesture data, the audio data and/or gesture data may be received by the logical server 110, and relayed to the second client computing device 125.

[0223] Figure 31 depicts an embodiment of logical server 110. Logical server 110 may include a processing device 205, a communication device 210, a memory device 215, a profile module 220, a media module 225, a gesture module 230, a audio module 235 and a package module 240.

[0224] The processing device 205 may include memory, for example, read-only memory (ROM) and random access memory (RAM), storing processor-executable instructions and one or more processors that execute the processor-executable instructions. In embodiments in which the processing device 205 includes two or more processors, the processors may operate in a parallel or distributed manner.

[0225] The processing device 205 may execute an operating system of the logical server 110 or software associated with other elements of the gift card server 110.

[0226] Communication device 210 may be a device that allows logical server 110 to communicate with another device over network 130. Communication device 210 may include one or more wireless transceivers to perform wireless communication and/or one or more communication ports to perform wired communication over network 130 The communication device 210 may be configured to communicate data via a plurality of different standards and/or protocols.

[0227] Memory device 215 may be a device that stores data generated or received by logical server 110. Memory device 215 may include, without limitation, a hard disk drive, an optical disk drive, and/or a flash memory drive. In embodiments, the memory device 215 may be configured to store information received from the first client computing device 120 and/or the second client computing device 125. Information stored in memory device 215 can be accessed by processing device 205, communication device 210 and/or modules 220, 225, 230, 235, 240.

[0228] Profile module220 may be a hardware processing device configured to allow the user of client computing devices120, 125 to generate and create a user profile. The user profile may include information stored in memory device 215 and/or other storage locations. The user profile may include user information, package information, and response information. User information may include, for example, information that identifies users (e.g., a username or nickname, a number, an identifier and/or other identifying information), security logon information (e.g., a logon code or password), payment information (e.g. credit card information), etc. The packet information may include information that corresponds to data that is stored locally on a client computing device associated with the user, where the packet information may be used to locally reconstruct a presentation. For example, package information may include an identification, a label, etc. associated with a first portion of media that is stored locally on a first client computing device 120 associated with the user. Using packet information, logical server 110 may have the ability to determine which media data, gesture data and/or audio data is stored locally on client computing devices associated with the user. The response information may include data corresponding to a response from the second client computing device 125 to the first client computing device 120. The response information may include an identification that corresponds to a portion of media data, audio data and/or gesture data in a response packet. The response information may include the same media data, audio data, and/or gesture data that corresponds to the data transmission from the first client computing device 120 to the second client computing device 125. Using the profile information and response information, the packet module 240 can determine which data is not stored locally on the recipient client computing device 120, 125, and can transmit the data that is not stored locally on the recipient client computing device 120, 125.

[0229] The media module 225 may be a hardware processing device configured to receive media data from the first client computing device 120 and/or the second client computing device 125. The received media data may correspond to a data packet to be presented to a user of the first computing device 120 and/or the second computing device 125, which may be the largest file type in the data packet. Media data can be formatted into a plurality of different types, such as pdfs, jpgs, bitmaps, image files, gifs, etc., namely image files regardless of whether they are predominantly scan-based or vector-based in nature, and independent of their semantic content. In embodiments, the media data may be used as a fundamental data file of the data package, wherein the gesture data may overlay the media data and the audio data may be synchronized with the presentation of the media data to a user. The media data may be received by the media module 225 before the gesture module 230 and/or the audio module 235, and may be received in response to a user initiating the creation of a presentation on the first client computing device 120. Therefore, the media module 225 may receive the media data before the presentation is completed.

[0230] Gesture module 230 may be a hardware processing device configured to receive gesture data from the first client computing device 120 and/or the second client computing device 125. Gesture data may be received in response to a user performing actions or movements in a graphical user interface, which may correspond to media data. Gesture data can be formatted into a plurality of different types and can be synchronized with media data, whereby gesture data can overlay media data at various times. For example, in one embodiment, the gesture data may include a circle drawn by a user, which overlays the media data in a specific time range. Gesture data may correspond to a single action performed by a user and/or a plurality of actions performed by the user. The gesture data may have a file size that is smaller than the file size of the media data, and may be transmitted to the logical server 110, the first client computing device 120, and/or the second client computing device 125 independent of the media data and /or audio data.

[0231] The audio module 235 may be a hardware processing device configured to receive audio data from the first client computing device 120 and/or the second client computing device 125. The audio data may be received in response to a user performing audio production, which may correspond to the media data. The audio data may be formatted into a plurality of different types and may be synchronized with the media data and the gesture data, where segments of the audio data may correspond to actions associated with the gesture data and/or a time range while the media data are presented to a user. For example, in one embodiment, the audio data may be a record that should be presented for the first sixty seconds in which the media data is presented on the first or second client computing device 120, 125. The audio data may correspond to the entirety of a time segment in which the media data is presented to a user and/or a plurality of time segments while the media data is presented to the user. Furthermore, the audio data may have a file size that is smaller than the media data file, and may be transmitted to the logical server 110, the first client computing device 120, and/or the second client computing device 125 independent of the data. media and/or gesture data.

[0232] Packet module 240 may be a hardware processing device configured to receive media data, gesture data, and/or audio data from the first client computing device 120 and to transmit the media data, gesture data, and/or or the audio data to a second client computing device125. The package module 240 may receive the media data from the first client computing device 120 in response to the user of the first client computing device 120 by creating a presentation. In response to the packet module 240 receiving the media data, the packet module 240 may be configured to determine a recipient user to receive the media data based on metadata associated with the media data, to scan an entry in the memory device 215 associated with the recipient user, and to determine whether The media data is locally stored on the second client computing device 125 associated with the recipient user. If the media data is locally stored on the second client computing device 125, the packet module 240 may not transmit the media data to the second client computing device 125, and if the media data is not locally stored on the second client computing device 125, the packet module 240 may transmit it. media data to the second client computing device125. The packet module 240 may then update the entry on the memory device 215 associated with the recipient user to indicate that the media data is locally stored on the second client computing device 125. Therefore, one may only require media data to be transmitted to the second client computing device 125 once, which may reduce bandwidth across network 130. Furthermore, in response to receiving media data from the first client computing device 120 to be transmitted to the second device of client computing device 215, package module 240 may update an entry in memory device 215 associated with the user of the first client computing device 120 to indicate that the media data is locally stored on the first client computing device 120. Therefore, the packet module 240 may not be required to transmit the media data to the first client computing device 120.

[0233] The package module 240 may also be configured to transmit audio data and/or gesture data to the second client computing device 125 in response to receiving the audio data and/or gesture data from the first client computing device 120. In embodiments, the package module 240 may automatically transmit the audio data and/or the gesture data to the second client computing device 125, wherein the audio data and/or the gesture data are used to reproduce the original presentation on the second client computing device 125 that was created on the first device. of client computing120. Therefore, packet module 240 may be configured to transmit only a portion of a presentation created on the first client computing device 120 to the second client computing device 0, and the transmitted portion may be based on the type of data generated by an end user (e.g., media data, audio data, gesture data, etc.).

[0234] Figure 32 illustrates a method 300 for transmitting presentations created on a first client computing device to a second client computing device, while reducing the bandwidth required to transmit the presentation. The operations of method 300 presented below are intended to be illustrative only. In some embodiments, method 300 may be performed with one or more additional operations not described and/or one or more of the operations discussed. Additionally, the order in which the operations of method 300 are illustrated in Figure 32 and described below is not intended to be limiting.

[0235] In some embodiments, method 300 may be implemented in one or more processing devices (e.g., a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and/or other mechanisms for electronically processing information). One or more processing devices may include one or more devices that perform part or all of the operations of method 300 in response to instructions electronically stored on an electronic storage medium. One or more processing devices may include one or more devices configured by hardware, firmware and/or software to be specifically designed to perform one or more of the operations of method 300.

[0236] In operation 310, media data associated with a presentation may be received from a first client computing device. Media data may be received before the presentation is completed on the first client computing device, and may be received in response to creation of the presentation being initiated. The media data may include metadata that indicates a recipient user who operates a second client computing device that is to receive the presentation. The media data may be the largest file associated with the presentation whose transmission is required from the first client computing device to the second client computing device. Operation 310 may be performed by a media module that is the same or similar to media module 225, according to one or more implementations.

[0237] In operation 320, before the presentation is completed, it may be determined that the media is not locally stored on the second client computing device. The determination may be made in response to scanning an input from a memory device associated with the recipient user operating the second client computing device to determine that the second client computing device has not received a presentation that includes the media data and/or that the second client computing device has clientdid not transmit a presentation includes the media data. Operation 320 may be performed by a package module that is the same or similar to package module 235, according to one or more implementations.

[0238] In operation 330, in response to determining that the media data is not locally stored on the second client computing device, the media data may be transmitted to the second client computing device, wherein the media data may be transmitted to the second client computing device before the presentation is completed and/or before other portions of the presentation (e.g., audio data and/or presentation data) have been received by the logical server. Operation 330 may be performed by a package module that is the same or similar to package module 235, according to one or more implementations.

[0239] In operation 340, other portions of the presentation, such as audio data and/or gesture data, may be received from the first client computing device. The audio data and/or the gesture data may be received independently and/or at different time periods, which may be after the media data is transmitted to the second client computing device. Audio data and/or gesture data may be received while creating a presentation in segments and/or after a presentation is completed. Operation 340 may be performed by a gesture module and/or an audio module that are the same or similar to the gesture module 230 and/or the audio module 235, according to one or more implementations.

[0240] In operation 350, the audio data and/or the gesture data may be automatically transmitted to the second client computing device in response to receiving the audio data and/or the gesture data. Operation 350 may be performed by a package module that is the same as or similar to package module 235, according to one or more implementations.

[0241] In operation 350, the presentation may be reconstructed on the second client computing device, using different portions of the presentation, such as media data, gesture data, and/or audio data. Operation 360 may be performed by a second client computing device that is the same as or similar to the second client computing device 125, according to one or more implementations.

[0242] Although the present technology has been described in detail for the purpose of illustration based on what is currently considered to be the most practical and preferred implementations, it is necessary to understand that such detail serves only that purpose and that the technology is not limited to the disclosed implementations, but is otherwise intended to cover modifications and arrangements equivalents that are within the spirit and scope of the appended claims. For example, it is necessary to understand that the present technology contemplates that, as far as possible, one or more characteristics of any implementation that can be combined with one or more characteristics of any other implementation.

[0243] Reference throughout this specification to "one (1) embodiment", "one embodiment", "one (1) example" or "an example" means that a particular feature, structure or characteristic described in conjunction with the embodiment or example is included in at least one embodiment of the present invention. Thus, occurrences of the expressions "in one (1) modality", "in one modality", "one (1) example" or "an example" in various places throughout this descriptive report do not necessarily refer to the same modality or example. Furthermore, particular features, structures or characteristics may be combined in any suitable combinations and/or subcombinations in one or more embodiments or examples. Furthermore, it is estimated that the figures provided in this document are for explanatory purposes to individuals skilled in the art, and that the drawings are not necessarily drawn to scale.

[0244] Embodiments according to the present invention can be embodied as an apparatus, a method or a computer program product. Accordingly, the present embodiments may take the form of an all-hardware embodiment, an all-software embodiment (including firmware, resident software, microcode, etc.), or an embodiment that combines aspects of software and hardware which may all be referred to herein as a "module" or " system". Furthermore, the present invention may take the form of a computer program product embodied in any tangible medium of expression that has computer-usable program code embedded therein.

[0245] Any combination of one or more computer-readable or computer-usable media may be used. For example, a computer-readable medium may include one or more of a portable computer floppy disk, a hard disk, a random access memory device (RAM), a read-only memory device (ROM), an erasable programmable read-only memory device (EPROM or Flash memory). ), a portable compact disk read-only memory (CDROM), an optical storage device, and a magnetic storage device. Computer program code for carrying out the methods of the present invention can be written in any combination of one or more programming languages.

Claims (10)

1. A computer-implemented method of hosting an asynchronous messaging service on a server for use by users through client devices communicating with the server, wherein the client devices execute an application to asynchronously originate and share messages between users that comprise image data, audio data and gesture data, wherein the server comprises hardware components adapted to perform the steps of: receiving on the server from a source client device, a first transmission comprising recorded audio data and gesture data related to a message; storing the first transmission comprising the audio data and the gesture data on the server in association with a second transmission comprising the image data to which the first transmission refers; and distributing the first stored transmission comprising the audio data and the gesture data to a recipient client device from the server separate from the image data; wherein the first received transmission comprising the audio data and the gesture data is recorded on the originating client device in association with the second transmission comprising the image data, and distributed to the recipient client device for playback by the recipient client device in association with the second transmission, the playback comprising presenting the audio data and gesture data in association and coordination with the image data, playing back on the receiving client device the recorded audio data and gesture data in context with the image data, being recorded on the originating client device, presenting a low bandwidth video experience to the recipient. 2. The method of claim 1, further comprising receiving the second transmission from an originating client device on the server, and distributing the second transmission to a receiving client device. 3. Method according to claim 1, characterized in that the second transmission is received during or before the first transmission is recorded. 4. The method of claim 1, further comprising receiving the second transmission from a client device on the server. 5. Method according to claim 1, characterized in that the gesture data comprises panning, zooming and rotating functionality of the image data. 6. Method according to claim 1, characterized in that the gesture data comprises layered visual annotations in the image data. 7. Server characterized by being for hosting a messaging service for use by users through client devices in communication with the server, wherein the client devices execute an application to originate and share messages among users comprising image data, audio data and gesture data, wherein the server comprises components of hardware adapted to perform the steps as defined in claim 1. 8. A computer-implemented method for using a client device to interact with a messaging service hosted on a server via an application running on the client device to originate and share messages among users comprising image data, audio data, and gesture data, wherein the application is adapted to perform the steps of: uploading, to the server using the client device, a second transmission comprising image data; recording, using the client device, a first transmission comprising audio data and gesture data relating to the second transmission; and uploading the first transmission from the client device to the server, separate from the image data for storage and association with the second transmission to which the first transmission refers to facilitate playback; playback comprising presenting the audio data and gesture data in association and coordination with the image data, reproducing on the receiving client device the recorded audio data and gesture data in context with the image data, as recorded on the originating client device, presenting a reduced bandwidth video experience to the recipient. 9. Method according to claim 8, characterized by the fact that the second transmission is loaded before or when the first transmission is recorded. 10. Client device characterized by being for interacting with a messaging service hosted on a server through an application running on the client device to originate and share messages between users comprising image data, audio data, and gesture data, wherein the application is adapted to perform the steps as defined in the claim 8.