Abstract:
Remotely directed filtering and sorting of near real-time audio or video messages is accomplished by including, within a messaging device, a messaging client application capable of assigning via a user interface attributes to an outgoing message, including a filtering assertion and a sorting assertion which express efficiently a sender&#39;s judgment about the relevance and currency of past, current and future messages with common attributes. Upon receiving a plurality of near real-time audio or video messages, the messaging client application enables a user to select attributes via a user interface for grouping pending messages, which are filtered and sorted in accordance with procedures that aggregate filtering and sorting assertions associated with messages having common attributes. The messaging client application further displays filtered counts of pending messages and sorted lists of pending messages and, in accordance with such sort, plays the next message when directed by a user interface.

Description:
BACKGROUND OF THE INVENTION 
     “Instant messaging” applications attempt to deliver notifications and content as soon as possible. However, the experience is often far from near real-time, instead reminiscent of explicitly asynchronous predecessors. Network connections fail or manifest latency. Servers under heavy load queue and hold messages before redistribution. A party on one side of a conversation sends a message, but the recipient is not simultaneously available or interested, or is reviewing messages from other senders with the same application. A group chat sends messages to every participant, increasing the number received and the difficulty of keeping current. Multicasting and repeated forwarding of messages to large, overlapping social networks also increase the number received, unpredictably, and weaken the association between message and recipient so much that a reasonable prima facie assumption is that no incoming message is personal, significant or worthy of immediate review. 
     Yet the most common lower-level user interface in instant messaging is a stream view that anticipates near real-time interaction. Incoming and outgoing messages are positioned sequentially in forward or reverse chronological order. A recipient who is inattentive to actively streaming messages must scroll backward to pick up the conversation. If the stream has moved on to other topics, responses require context and repetition. The most common higher-level user interface is a list of users or chat groups, sorted alphabetically or in forward or reverse chronological order, with message counters that indicate little more than streams charging ahead unheeded. 
     Attempts to adapt message organizing methods from explicitly asynchronous predecessors have been mixed. The most common user interface for Internet email is a threaded view which groups messages by common subject and identifies which messages reply to other messages. Such subject grouping and threading, applied to instant messaging, so changes the user experience that most participants view the application as a different category of service with alternative nomenclature. For example, on Facebook, a message multicast in near real-time to a social network and rendered in a stream is a “posting” on a “Timeline”, threaded responses are “comments” or “likes”, subject headings refer to embedded content, and threads reappear with each new activity. Most users view this near real-time service as a social bulletin board, not instant messaging. On Twitter, a message multicast in near real-time to a social network and rendered in a stream is a “tweet” (or if forwarded, a “retweet”), words that proxy for subject are “hashtags”, and replies, although threaded in a lower-level interface, are filtered so that only messages from social network connected senders appear in a receiver&#39;s stream. Most users view this near real-time service as “microblogging” or broadcasting, not instant messaging. 
     Despite the proliferation of multimedia content on the Internet, instant message applications remain predominantly textual, with photographs the most typical multimedia content. Text requires more time to type than to read—particularly on a mobile device—which limits the number of messages sent and, from the standpoint of recipients, limits the number of incoming messages. Text and photographs are skimmable; without reading every word or studying every image, recipients recognize interesting content in a swiftly flowing stream. Practical limits on content production, and the possibility of selective and rapid content consumption, have been advantageous to instant messaging of text and photography. 
     Audio and video recordings can require less time to create than text messages, and offer potentially rich and personalized content; but take longer for a recipient to experience and interpret than text or photography. There is no practical way to skim audio or video recordings for interesting content. Instant messaging applications that support audio or video messages typically treat the content as supplementary; the most common lower-level user interface embeds media play buttons in a stream of skimmable text that provides context and rationale to push individual play buttons. 
     Attempts in the prior art to put audio or video recordings at the forefront of instant messaging have been problematic. Audio or video messages delivered in any significant volume, without accompanying skimmable content, quickly accumulate into unmanageable reservoirs akin to the “full voicemail box” in telephony. Users are reluctant to send audio or video recordings, not knowing whether a message will be played or left to accumulate, or whether more important or more current information will soon be available to send. The more messages sent, the harder to hold a near real-time conversation when the opportunity arises. If a recipient responds to messages played in chronological order, any backlog renders the communication asynchronous, even when both parties are simultaneously attentive and engaged. If a recipient responds to messages played in reverse chronological order, it disrupts the natural flow of conversation. Explicit threading of audio or video messages, without accompanying skimmable content, is difficult and of lesser value than in text messaging; if a newly received audio or video message relates to an older such message, the recipient often must replay it to appreciate the context. 
     BRIEF SUMMARY OF THE INVENTION 
     The following presents a simplified summary of the disclosure in order to provide a basic understanding of some aspects. It is not intended to identify key or critical elements of the disclosure or to delineate the scope of the disclosure. It merely presents some concepts of the disclosure in a simplified form as a prelude to the more detailed description provided below. 
     The present invention relates generally to the field of instant messaging, and addresses deficiencies of the prior art with a novel and non-obvious system and method for remotely directed filtering and sorting of near real-time audio or video messages. In some embodiments, the sender of an audio or video message can, via user interface elements, identify it and messages that follow as having greater importance, or “urgency”, than messages sent before; furthermore, the sender of an audio or video message can, via user interface elements, identify messages that preceded it as having such lesser relevance and currency that they are obsolete, or “flushed”. Data comprising the audio or video instant message include corresponding “urgency” and “flush” indicators that influence presentation for the recipient as follows. Unplayed audio or video messages, grouped according to common attributes, render by default for the recipient in forward chronological order by recording time. In accordance with aspects of the present invention, once an “urgency” flagged message is received, the message, and subsequently recorded messages with selected common attributes, render prior to unplayed messages with such attributes and an earlier recording time. Once a “flush” flagged message is received, prior messages with selected common attributes are no longer playable. Importantly, messages need not share a common subject or discussion identifier, or relate back to a specific prior message, to affect the manner or order of presentation, as in a threaded approach. 
     In video near real-time audio or video messaging, the present invention offers substantial advantages over the prior art. In embodiments that implement the one-on-one exchange of messages, incoming messages may be grouped and playable according to a common sender. In accordance with one or more aspects of the present invention, users may talk on demand and at length, without fear of filling an inbox with messages of limited time value, or expected to be presented in an inopportune order, regardless of whether the recipient is immediately available. Via simple and convenient user interface elements, a sender can signal that material created from that moment forward should be presented before older material, or that older material should not be presented at all. A recipient can wait until a convenient time to listen or view, and expect that the first playable message is the most important in accordance with the sender&#39;s most recent judgment, that messages of equal importance will be presented in forward chronological order, and that no out of date messages remain in the queue. 
     When a recipient is inattentive and a backlog develops, aspects of the present invention facilitate a transition to near real-time interaction for follow-up questions or comments. With a single user interface “urgency” action, any sender can cause a new message, and messages that follow, to be presented before an outstanding backlog. If responses suggest that the other party is confused backlogged messages, then a sender can, with a single user interface action, “flush” the backlog and substitute new messages. These advantages flow from the present invention without complex management by sender or recipient of discussion threads. 
     The embodiment described above groups incoming messages by sender. Some alternative embodiments, prior to the application of “urgency” and/or “flush”, group messages according to additional or alternative common attributes, such as categories of message type, subject tags, geotags, group chat participations, social network connections between users, or measurements of social network proximity, at the option of the recipient. 
     Some alternative embodiments permit the sender to designate deltas, positive and negative values, instead of a simple flag or boolean, that apply a direction and intensity to “urgency” and “flush”. 
     Additional aspects of the invention will be set forth in part in the description, will be obvious from the description, or may be learned by practice of the invention. The aspects of the invention will be realized and attained by means of the elements and combinations particularly pointed out in the appended claims. It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention as claimed. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The accompanying drawings, which are incorporated in and constitute part of this specification, illustrate embodiments of the invention and, together with the description, serve to explain the principles of the invention. The embodiments illustrated herein are presently preferred, it being understood, however, that the invention is not limited to the precise arrangements and instrumentalities shown, wherein: 
         FIG. 1  illustrates an exemplary near real-time audio or video messaging device; 
         FIG. 2  illustrates an exemplary near real-time audio or video messaging communication system; 
         FIG. 3  illustrates an exemplary serialized transport data record format for an near real-time audio or video message; 
         FIG. 4  is a flowchart illustrating an exemplary user interface process for user input and selection of attributes, recording and sending of a near real-time audio or video message; 
         FIG. 5  is a flowchart illustrating an exemplary user interface process for user selection of attributes, and playing a next near real-time audio or video message; 
         FIG. 6  illustrates an exemplary higher-level user interface for user selection of attributes, or bundles of attributes, in respect to near real-time audio or video messages; 
         FIG. 7  illustrates an exemplary lower-level user interface for user selection of attributes in respect to near real-time audio or video messages, and submitting record or play instructions; 
         FIG. 8  is a flowchart illustrating an exemplary process for grouping and filtering near real-time audio or video messages to present in a user interface aggregates based on advantageously reduced sets; 
         FIG. 9  is an SQLite database definition illustrating an exemplary representation of data associated with near real-time audio or video messages; 
         FIG. 10  is an SQLite database query illustrating an exemplary implementation of grouping and filtering near real-time audio or video messages that aggregates advantageously reduced sets grouped according to sender; 
         FIG. 11  is an SQLite database query illustrating an exemplary implementation of grouping and filtering near real-time audio or video messages that aggregates advantageously reduced sets grouped according to subject tag; 
         FIG. 12  is a flowchart illustrating an exemplary process for grouping, filtering and sorting near real-time audio or video messages that plays the next message from an advantageously reduced set sorted in an advantageous order; 
         FIG. 13  is an SQLite database query illustrating an exemplary implementation of grouping, filtering and sorting near real-time audio or video messages from one or more selected senders, that identifies the next to play from an advantageously reduced set sorted in an advantageous order; 
         FIG. 14  is an exemplary implementation of an SQLite database query that identifies the next message to play from an advantageously reduced set of near real-time audio or video messages, associated with one or more selected subject tags, sorted in an advantageous order; 
         FIG. 15  is a series of SQLite operations illustrating an exemplary implementation in which cumulations and summations are precalculated; 
         FIG. 16  is a flowchart similar to  FIG. 12 , illustrating an exemplary process that presents in a user interface an advantageously sorted list of near real-time audio or video messages available for play, after an advantageous reduction; 
         FIG. 17  is an exemplary implementation of an SQLite database query, similar to  FIG. 13 , that produces an advantageously sorted list of near real-time audio or video messages available for play, associated with one or more selected senders, after an advantageous reduction; 
         FIG. 18  is an exemplary implementation of an SQLite database query, similar to  FIG. 14 , that produces an advantageously sorted list of near real-time audio or video messages available for play, associated with one or more selected subject tags, after reduction and sorting. 
         FIG. 19  illustrates an exemplary near real-time audio or video messaging communication system in which audio or video near real-time messages are routed, redirected or reflected to recipients according to a combination of social network, geographical and subject tag data. 
     
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     The following detailed description is of the best currently contemplated modes of carrying out exemplary embodiments of the invention. The description is not intended to be taken in a limiting sense, but is merely for the purpose of illustrating the general principles of the invention. 
       FIG. 1  illustrates an exemplary audio or video near real-time messaging device for use with embodiments of the present invention. The audio or video near real-time messaging device  110  is a user-operated physical apparatus capable of sending and receiving near real-time audio or video messages over a network. Examples of such a device include, without limitation, a desktop computer, a laptop computer, and a mobile phone, alone or in conjunction with bluetooth connected auxiliary devices, such as a headset or wristwatch, or other user-operated communication device. 
     Such an exemplary device generally includes a processor  115 , memory  120 , a display  125  and an interface to a network connection  130 ; and provide a user interface  135  which integrates facilities, or embedded or accessible devices for input from the user, such as a touch input device  140 , text input device  145 , an audio input device  150 , and a still image and/or video input device  155 ; and for output to the user, including a audio output device  160  and such display  125 ; and may include additional facilities to capture accessible data or information, such as GPS sensors  165  that collect global positioning system data. As used herein, the term “processor” is generally understood to be a device that drives a general-purpose computer. It is noted, however, that other processing devices, such as microcontrollers, Field Programmable Gate Arrays (FPGAs), Application Specific Integrated Circuits (ASICs), or a combination thereof, can be used to achieve the benefits and advantages of the present invention. As used herein, the term “memory” is generally understood to be RAM memory, ROM memory, EPROM memory, EEPROM memory, non-volatile RAM (NVRAM) memory, flash memory, magnetic media disk drives, optical drives, and other equipment or media for short and long term data storage. The above memory types are exemplary only, and are thus not limiting as to the types of memory usable within the present invention. 
     For example, within the memory  120  is shown an operating system  121  and a near real-time audio or video messaging client application  122  that consists of instructions executable by the processor. To send and/or play near real-time audio or video messages, the user activates the device  110 , and via the user interface  135 , runs the client application  122 . The client application is operable to send near real-time audio or video messages via the network interface  130 , upon user specification of message attributes, and an instruction to record provided via the input devices  140 ,  145 ,  150  and/or  155  which prompts the recording of an audio message via the audio input device  150  or a video message via the audio and/or video input devices  150  and  155 ; and is operable to play messages received via the network interface  130 , upon user specification of message attributes, and an instruction to play provided via the input devices  140 ,  145 ,  150  and  155  which prompts the playing of an audio message via the audio output device  160  or a video message via the audio output device  160  and/or the display  125 . The client application may, either itself or via an associated background process, receive messages in near real-time via the network interface  130  and store a representation thereof in the memory  120 ; and provide notifications of new messages to the user via the audio output device  160  and/or the display  125 , and present lists of individual messages or aggregates of unplayed messages via the display  125  in accordance with user interface  135  interactions. 
       FIG. 2  illustrates an exemplary communication system for near real-time audio or video instant messaging. The communication system includes a plurality of messaging devices  110  and a messaging server  210 , interconnected by a network  220  over which travel near real-time audio or video messages  230 . The messaging server  210  receives a message  230  from a messaging device  110 , processes and, in some cases, transforms the message based on its content and associated metadata, and routes, redirects or reflects the message to one or more messaging devices  110 . In alternative embodiments, peer-to-peer methods, known to practitioners of the art, transport messages from one device to another without the intermediation of a messaging server. 
       FIG. 3  illustrates an exemplary serialized transport data record format  305  in accordance with a preferred embodiment of the present invention. The format is purely illustrative of general concepts in near real-time messaging and not meant to be comprehensive; a number of other fields or field structures, formats and representations thereof will occur to practitioners of the art with the benefit of the disclosure. While this illustration references relational concepts, it is in no way intended to limit application of the present invention to relational database approaches. 
     In accordance with methods known by practitioners of the art with respect to databases in near real-time messaging systems, relational databases generally and the serializing of data for transport, in such exemplary data record format, message_id  315  uniquely identifies a message. timestamp  320 , with additional seeded random data, represents the recording time reported by the message sending device  110  and also provides a unique pointer to the audio or video content of the message  310 , for example, a compressed digital audio or video file. relation_id  325  references a relationship from one user  330  to another  335 , authorizing a reverse-direction communication pathway of a particular type referenced by message_type_id  340 ; alternatively, relation_id references a relationship between one user and a notional user representing a special purpose service mediated by the messaging server  210 . One or more relation_id references in the data record specify the intended recipients; or, alternatively, trigger special purpose services mediated by the messaging server  210 , such as group chats or social network multicast facilities, which utilize fields of the data record and/or additional data accessible by the messaging server to replace or augment fields of the data record, such as relation_id references. Optionally, one or more tag_id references  345  identify words or phrases as subject tags associated with a message. Optionally, geo_id  370  references geolocation information associated with a message. Optionally, reference_person_id  350  identifies the sender in contexts where relation_id relates to a special purpose facility mediated by the messaging server, as in a group chat or a social network multicast facility. Optionally, reference_message_id  355  identifies a prior message with which the current message is associated. Additional optional fields include a text message  360  or URL  365  that accompanies the audio or video message. Parallel or separate background processes on the messaging device  110  and the messaging server  210  retrieve, transmit, receive and inject transport data records  305 , audio and/or video content  310 , and referenced relational database records if new to recipients. 
     In accordance with a preferred embodiment of the present invention, and illustrating some of its original, innovative and advantageous aspects, an additional field in the exemplary transport data record  305  is urgency  380 , a boolean or flag that represents a judgment that the current message, and messages with common attributes that follow (by implication, with the same intended recipients), are of greater importance than messages with common attributes sent before; another additional field is flush  385 , a boolean or flag that represents a judgment that messages with common attributes sent before are of such lesser relevance and currency that they are obsolete. 
     In an alternative preferred embodiment, urgency  380  is a delta (a positive or negative change value) that reflects the direction and intensity of a judgment about the relative importance of the current message and messages with common attributes that follow, compared to messages with common attributes sent before; and flush  385  is a delta that reflects the direction and intensity of a judgment about the relevance, currency (and potential obsolescence) of messages with common attributes sent before. For example, such a delta might be chosen from −3, −2, −1, 1, 2 or 3. 
       FIG. 4  is a flowchart illustrating an exemplary user interface process for user input and selection of attributes, and the recording and sending of an audio or video near real-time message. In accordance with methods known by practitioners of the art, the user enters the user interface of the client application  405  and steps through an iterative process for entering and/or selecting attributes to be associated with the next outbound audio or video message  230 . If the next attribute is new  410 , the user submits the attribute  415  via a user interface for data entry; for example, the user might provide a new recipient person name or subject tag by typing into a text entry widget. If the next attribute is not new, the user selects an attribute or attribute bundle among options presented in the user interface  420 ; for example, the user might select one or more recipient person names or subject tags from a presented list or representative icon set. If there is another attribute  425 , the user repeats the steps beginning with  410 , with the user interface potentially updating to present new options. The iterative nature of this procedure reflects standard practices in the art to present higher and lower level user interfaces that offer an accessible user experience of “drilling down” to assign values to multiple attributes. 
     In accordance with a preferred embodiment of the present invention, and illustrating some of its original, innovative and advantageous aspects, in  FIG. 4 , the user considers, in the context of the selected attributes, the importance of upcoming messages to be recorded  430  and therefore whether to set an “urgency” flag/delta  435 ; and the relevance and currency of messages sent before  440  and therefore whether to set a “flush” flag/delta  445 , before proceeding to record  450  and send  455  a near real-time audio or video message. 
       FIG. 5  is a flowchart illustrating an exemplary user interface process for user selection of attributes, and playing a next audio or video near real-time message. In accordance with methods known by practitioners of the art, the user enters the user interface of the client application  505  and steps through an iterative process for entering and/or selecting attributes associated with audio or video messages  230  that have already been received prior to the user providing an instruction to play the next message. The user selects an attribute or attribute bundle among options presented in the user interface  510 . If there is another attribute  515 , the user repeats step  510 , with the user interface potentially updating to present new options. (An entry step is of less importance here, as the user interface for attribute selection can adapt to include new options upon the arrival of additional messages). The iterative nature of this procedure reflects the standard practice in the art to present higher and lower level user interfaces that offer an accessible user experience of “drilling down” to assign values to multiple attributes. 
     In accordance with a preferred embodiment of the present invention, and illustrating some of its original, innovative and advantageous aspects, in  FIG. 5 , when the user proceeds to play  520  the next audio or video message, the message chosen will reflect “urgency” and “flush” provided by senders of messages with common attributes. 
       FIG. 6  illustrates an exemplary higher-level user interface for user selection of attributes, or bundles of attributes, in respect to near real-time audio or video messages. In accordance with methods known by practitioners of the art, the interface is a pop-up menu  605  of entries that represent message attributes or bundles of message attributes, sometimes referred to herein as “services”, suitable for aggregation and presentation in lower-level user interfaces. In some cases, services are selectable  615  and, in other cases, are expandable  620  and, if expanded  625  contain submenus of additional selectable options  630 , representing alternatives among other distinguishing attributes. Where appropriate, the interface displays a corresponding counter  635  representing unplayed messages not filtered out in accordance with the present invention. 
       FIG. 7  illustrates an exemplary lower-level user interface for user selection of attributes in respect to near real-time audio or video messages, and submitting record or play instructions. In accordance with methods known by practitioners of the art, the interface  705  has an identifying label  710  that summarizes the choices made in the pop-up menu (representing, in this case, a “service”); a scrollable central region  750  of icons that represent a final attribute for selection  715 , which may be a multi-selection; a counter for messages associated with such final attribute  720  representing unplayed messages not filtered out in accordance with the present invention; and buttons that instruct the application to record  725 , play  730  or cancel  735  audio or video messages with attributes in common with the selected attributes. 
     In accordance with preferred embodiments of the present invention, and illustrating some of its original, innovative and advantageous aspects, in  FIG. 7 , the user may select the “urgency” button  740  and/or the “flush” button  745 —on/off toggle switches or a pull downs or other implement to enter a value—in order to set the “urgency” flag/delta  435  and/or the “flush” flag/delta  445 , prior to sending an audio or video message. 
     Once the user has made selections via the higher-level interface  605  and the lower-level interface  705 , in a preferred embodiment of the present invention, the user has specified a collection of attributes sufficient to send and route outgoing messages in the exemplary near real-time audio or video message communication system illustrated in  FIG. 2 , and for the presentation in an advantageous order of incoming messages advantageously filtered, in accordance with the present invention. 
     Data associated with audio or video near real-time messages are usable, among other things known to practitioners of the art, to uniquely identify the message, the time and place of recording, the sender and the intended recipient(s); to route a message; to characterize the subject matter of a message; to manipulate or transform a message; and to filter, sort, group or aggregate a collection of messages. 
     In notation used herein, data associated with a single message is represented by a tuple t of attributes {A 1 , A 2 , . . . , A n }, with relation R a collection of such tuples.
 
 r=π   a     1     ,a     2     , . . . ,a     m   (σ C ( R ))
 
denotes a selection (σ) applying conditions C on attributes in R, and a projection (π) on to a subset of m attributes in R, to produce a new relation r.
 
               s   =     G     c   1         ,     G     c   2       ,   …   ⁢           ,       G     c   j       ⁢   g   ⁢           ⁢           f   1     ⁢     (   ·   )       ,       f   2     ⁡     (   ·   )       ,   …   ⁢           ,       f   k     ⁡     (   ·   )           ︸     {       b   1     ,     b   2     ,     …   ⁢           ⁢     b   l         }         ⁢     (   r   )             
denotes a grouping (g) in which aggregations f 1 (•), f 2  (•), . . . , f k  (•) such as sum, maximum, minimum or count are applied to attributes {b 1 , b 2 , . . . , b 1 }, and grouped by other attributes {c 1 , c 2 , . . . , c j }, in each case drawn from attributes {a 1 , a 2 , . . . , a m } of r, to produce a new relation s.
 
τ L (s) denotes a sorting operation, where L is a list of attributes of s, each identified either as an ascending or descending sorting key to be applied successively from left to right.
 
     The following illustrates some general concepts of the present invention in this notation. With relation R representing data associated with a collection of messages
 
 r=π   urgency,flush,time,played,a     4     ,a     5      . . . ,a     m   (σ C ( R ))
 
is a selection (σ) applying conditions C on message attributes to limit the set of messages under consideration, for example, in connection with a selective user interface presentation of messages with a certain type and/or from a certain sender and/or with certain subject tags; and a projection (π) of attributes needed for filtering, grouping and presentation, resulting in a new relation r. In accordance with the present invention, included among exemplary projected attributes are urgency, flush and time (for example, epoch).
 
     New relation r′ extends with three additional values each tuple x of r, where tuple x satisfies the condition σ played=false : 
               cumulative_urgency             ⁢   x       ⁢     :     ⁢           ⁢       ∑     i   =   1     x     ⁢         π   urgency     ⁡     (       τ     time   asc       ⁡     (       σ     C   x       ⁡     (   r   )       )       )       i                     cumulative_flush             ⁢   x       ⁢     :     ⁢           ⁢       ∑     i   =   1     x     ⁢         π   flush     ⁡     (       τ     time   asc       ⁡     (       σ     C   x       ⁡     (   r   )       )       )       i                     sum_flush             ⁢   x       ⁢     :     ⁢           ⁢       ∑   i     ⁢         π   flush     ⁡     (       σ     C   x       ⁡     (     r   i     )       )       .             
cumulative_urgency is a forward chronological cumulative sum of urgency values (0 or 1 if implemented as a boolean) of tuples representing messages that satisfy a condition σ C     x    that embodies a selective user interface presentation, for example, a requirement that messages have a common sender σ r     sender       i     =r     sender       x   . cumulative_flush is a forward chronological cumulative sum of flush values of tuples representing messages that satisfy condition σ C     x   . sum_flush is a sum of flush values of all tuples, regardless of chronology, representing messages that satisfy condition σ C     x   .
 
     To transform r′ into an advantageously reduced result set:
 
 r″=σ   cumulative   _   flush&gt;=sum   _   flush ( r ′)
 
which is suitable for aggregation, for example, in connection with a selective user interface presentation of pending message counts according to sender:
 
 s=G   sender   g   count(•) ( r ″)
 
     To transform r″ into an advantageously sorted result set, for example, in connection with user interface presentation of playable messages, or operation of a button that plays the next message from a plurality of playable messages:
 
 r′″=τ   cumulative   _   urgency     desc     ,time     asc   (σ C     y   ( r ″))
 
where condition σ C     y    represents, for example, user interface selection of a particular sender.
 
     Although the above illustration uses additive cumulation and summation functions, and inequalities that are not strict, there are a variety of alternative mathematical transformations of the aforementioned relations, such as subtractive cumulation, negative summation, products or geometric progression, and consonant conditions such as strict inequalities or equalities, in each case, obvious to practitioners of the art with the benefit of the disclosure, that effect the same reduction and sorting. 
     In preferred embodiments of the present invention, attributes of audio or video near real-time messages are represented, in a manner known to practitioners of the art, by relational SQL databases, a decomposition of such a relation R into normalized relvars {R 1 , R 2 , . . . , R n }, each a table with a header, attributes drawn from attributes {A 1 , A 2 , . . . , A n }, primary and/or foreign keys and integrity constraints. Selections (σ) and projections (π) operate on a relation {circumflex over (R)} s  recomposed via a series of joins (           ) on a subset of such relvars
     
       
         
           
             
               
                 
                   R 
                   ^ 
                 
                 s 
               
               = 
               
                 
                   R 
                   a 
                 
                 ⁢ 
                 ⁢ 
                 
                   R 
                   b 
                 
                 ⁢ 
                 ⁢ 
                 
                   R 
                   c 
                 
               
             
             , 
             … 
           
         
       
     
     In such preferred embodiments, aggregations representing alternative groupings, for example, the presentation of counts in a higher-level user interface representing multiple service types  605 , will consist of separate selection (σ) and projection (π) operations on recompositions of tailored subsets of relvars:
 
 {circumflex over (r)}   1 =π urgency,flush,time,played,a     4       1     ,a     5       1     . . . ,a     x       1   (σ C     1   ( {circumflex over (R)}   1 )),
 
 {circumflex over (r)}   2 =π urgency,flush,time,played,a     4       2     ,a     5       2     . . . ,a     y       2   (σ C     2   ( {circumflex over (R)}   2 )),
 
 {circumflex over (r)}   3 =π urgency,flush,time,played,a     4       3     ,a     5       3     . . . ,a     z       3   (σ C     3   ( {circumflex over (R)}   3 )), . . .
 
     New relation {circumflex over (r)} x ′ extends each tuple of {circumflex over (r)} x  which satisfies the condition σ played=false  with the aforementioned values cumulative_urgency, cumulative_flush and sum_flush as above, with advantageous reductions of each relation:
 
 {circumflex over (r)}   1 ″=σ cumulative   _   flush&gt;=sum   _   flush ( r   1 ′),
 
 {circumflex over (r)}   2 ″=σ cumulative   _   flush&gt;=sum   _   flush ( r   2 ′),
 
 {circumflex over (r)}   3 ″=σ cumulative   _   flush&gt;=sum   _   flush ( r   3 ′), . . .
 
with such exemplary presentation of aggregates according to:
 
 ŝ=G   identifier     1     G   attribute     1     g   count(•) ( {circumflex over (r)}   1 ″),
 
∪ G   identifier     2     G   attribute     2     g   count(•) ( {circumflex over (r)}   2 ″)
 
∪ G   identifier     3     G   attribute     3     g   count(•) ( {circumflex over (r)}   3 ″), . . .
 
each representing a “service” or attribute bundle identifier, grouped by attribute x .
 
     To transform {circumflex over (r)}″ into an advantageously sorted result set, for example, in connection with user interface presentation of playable messages, or operation of a button that plays the next message from a plurality of playable messages:
 
 {circumflex over (r)}′″=τ   cumulative   _   urgency     desc     ,time     asc   (σ C     y   ({circumflex over ( r )}″))
 
where condition σ C     y    represents, for example, user interface selection of a particular sender.
 
     The use of relational databases in preferred embodiments is not intended to in any way limit the scope of the present invention, which can be implemented by practitioners of the art with the benefit of the disclosure using “noSQL” databases, denormalized records, key-value stores, and other data storage and retrieval methods and techniques. 
       FIG. 8  is a flowchart illustrating an exemplary process for grouping and filtering audio or video near real-time messages to present in a user interface aggregates of advantageously reduced sets of messages. In accordance with preferred embodiments of the present invention, and illustrating some of its original, innovative and advantageous aspects, in  FIG. 8 , one or more audio or video messages are received  805 , including data representing associated attributes. Inbound messages with common attributes that meet a user interface specification are grouped together  810 , a step known to practitioners of the art and performed in a wide range of typical user interface paradigms; for example, grouping of messages according to common type, and/or sender and/or subject tag. The next steps are to traverse the messages in each group in forward chronological order  815  and, in the course of such traversal, to assign to each message that is unplayed (according to a corresponding attribute) the cumulative sum of the flush flags/deltas for the messages in the group  820 , and to calculate a sum of the flush flags/deltas for all the messages in the group  825 . From each group, messages are excluded  830  if already played or if the cumulative value of flush flags/deltas assigned is less than the sum of flush flags/deltas for all messages in the group. A count of messages remaining in each group  835  is presented in the user interface  840 . 
       FIG. 9  is an SQLite database definition illustrating an exemplary representation of data associated with audio or video near real-time messages, set forth as table create operations  900 . In preferred embodiments of the present invention, in accordance with methods typical for near real-time messaging and known by practitioners of the art, parallel or separate background processes inject into the database  900  data representing attributes of outgoing messages upon a recording event; retrieve from the database  900  data representing attributes of outgoing messages, and assemble and transmit to the messaging server  210  data transport records  305  and relational database records referenced therein; receive from the messaging server  210  data transport records  305  and relational database records referenced therein, and perform injections into the database  900  representing attributes of incoming messages; and update attributes of messages upon a play event. 
       FIG. 10  is an SQLite database query illustrating an exemplary implementation of grouping and filtering audio or video near real-time messages that aggregates advantageously reduced sets grouped according to sender. In a preferred embodiment of the present invention, one of the user interface specifications that may be selected in a higher-level user interface  605  is standard one-to-one (or one-to-many) messaging, denoted type “pathway”; the user&#39;s selection determines the choice of a lower-level user interface  705  and database query. In this implementation, a lower-level user interface is built with the result set of query  1000 , with icons  715  representing users with whom one can exchange messages. The query requires message type “pathway”, and calculates additive cumulations and summations for messages that share a common relation authorizing inbound messages from a particular other user, which effects the desired grouping. In accordance with the present invention, and illustrating some of its original, innovative and advantageous aspects, the result set value assigned to the counter  720  associated with each icon excludes a message if already played or the cumulative value of the flush flags/deltas assigned to it, calculated traversing messages in the group chronologically, is less than than the sum of flush flags/deltas for all the messages in the group. This advantageous reduction excludes from the counter messages that, in the judgment of the sender, no longer have continuing relevance and currency. 
       FIG. 11  is an SQLite database query illustrating an exemplary implementation of grouping and filtering audio or video near real-time messages that aggregates advantageously reduced sets grouped according to subject tag. In a preferred embodiment, one of the user interface specifications that may be selected in a higher-level user interface  605  is “assistant” messaging with a particular other user, in which messages are associated with subject tags from a predefined set; the user&#39;s selection determines the choice of a lower-level user interface  705  and database query. In this implementation, a lower-level user interface is built with the result set of query  1100 , with icons  715  representing subject tags associated with exchanged messages. The query requires message type “assistant” and a particular sender, and calculates additive cumulations and summations for messages that share a common subject tag, which effects the desired grouping. In accordance with the present invention, and illustrating some of its original, innovative and advantageous aspects, the result set value assigned to the counter  720  associated with each icon excludes a message if already played or the cumulative value of the flush flags/deltas assigned to it, calculated traversing messages in the group chronologically, is less than the sum of flush flags/deltas for all the messages in the group. This advantageous reduction excludes from the counter messages that, in the judgment of the sender, no longer have continuing relevance and currency for the associated subject tag. 
       FIG. 12  is a flowchart illustrating an exemplary process for grouping, filtering and sorting audio or video near real-time messages that identifies and plays the next message from an advantageously reduced set sorted in an advantageous order. In accordance with preferred embodiments of the present invention, and illustrating some of its original, innovative and advantageous aspects, in  FIG. 12 , the user provides a play instruction with selected attributes  1205 , including the attributes associated with a current user interface specification and one or more selections; for example, in a lower-level user interface  705  for messages of a particular type, the user selects one or more icons  715  that represent senders, and presses the play button  730 . Messages that meet the current user interface specification and selections are grouped together  1210 . The next steps are to traverse the messages in the group in forward chronological order  1215  and, in the course of such traversal, to assign to each message that is unplayed (according to a corresponding attribute) the cumulative sum of the “urgency” flags/deltas for messages in the group  1220 , to assign to each message that is unplayed (according to a corresponding attribute) the cumulative sum of the flush flags/deltas for messages in the group  1225 , and to calculate a sum of the flush flags/deltas for all messages in the group  1230 . A message is excluded  1235  if already played or if the cumulative value of flush flags/deltas assigned to the message is less than the sum of flush flags/deltas for all messages in the group. The next message played  1240  is the message remaining with the earliest timestamp and the maximum assigned cumulative sum of “urgency” flags/deltas. With respect to judgments by a sender, this advantageously presents messages of greater importance first, preserves forward chronological presentation of messages of equal importance, and excludes obsolete messages. 
     It is noted that, in some preferred embodiments, the selection of more than one icon  715  in a lower-level user interface groups together messages from multiple senders, whose judgments about “urgency” and “flush” are then treated equally and collectively in the performance of reduction and sorting in accordance with the present invention. 
       FIG. 13  is an SQLite database query illustrating an exemplary implementation of grouping, filtering and sorting audio or video near real-time messages, from one or more selected senders, that identifies the next to play from an advantageously reduced set in an advantageous order. In a preferred embodiment of the present invention, one of the user interface specifications that may be selected in a higher-level user interface  605  is standard one-to-one (or one-to-many) messaging, denoted type “pathway”; the user&#39;s selection determines the choice of a lower-level user interface  705  and database query. In this implementation, the user selects one or more icons  715  representing users with whom one can exchange messages. The query  1300  requires message type “pathway” and a relation authorizing incoming messages from any of the users selected, which effects the desired grouping. In accordance with the present invention, and illustrating some of its original, innovative and advantageous aspects, the query excludes a message if already played or the cumulative value of the flush flags/deltas assigned to it, calculated traversing the messages in the group chronologically, is less than than the sum of flush flags/deltas for all the messages in the group; sorts the remaining messages according to their assigned cumulative urgency value (descending), and the epoch or recording time (ascending), applied left to right; and identifies the next message to play. With respect to judgments by senders, considered collectively, this advantageously presents messages of greater importance first, preserves forward chronological presentation of messages of equal importance, and excludes obsolete messages. 
       FIG. 14  is an SQLite database query illustrating an exemplary implementation of grouping, filtering and sorting audio or video near real-time messages, associated with one or more selected subject tags, that identifies the next to play from an advantageously reduced set in an advantageous order. In a preferred embodiment, one of the user interface specifications that may be selected in a higher-level user interface  605  is “assistant” messaging with a particular other user, in which messages are associated with subject tags from a predefined set; the user&#39;s selection determines the choice of a lower-level user interface  705  and database query. In this implementation, the user selects one or more icons  715  representing subject tags associated with exchanged messages. The query  1400  requires message type “assistant”, a relation authorizing incoming messages from a particular sender, and any of the subject tags selected, which effects the desired grouping. In accordance with the present invention, and illustrating some of its original, innovative and advantageous aspects, the query excludes a message if already played or the cumulative value of the flush flags/deltas assigned to it, calculated traversing messages in the group chronologically, is less than than the sum of flush flags/deltas for all the messages in the group; sorts the remaining messages according to their assigned cumulative urgency value (descending), and the epoch or recording time (ascending), from left to right; and identifies the next message to play. With respect to judgments by the sender, considered collectively according to the selected subject tag(s), this advantageously presents messages of greater importance first, preserves forward chronological presentation of messages of equal importance, and excludes obsolete messages. 
     In a manner obvious to practitioners of the art with the benefit of the disclosure, alternative embodiments precalculate and store cumulations and summations in a convenient data record upon receipt of each message, rather than performing such calculations at the time of a user interface presentation or play event.  FIG. 15  is a series of SQLite operations  1500  illustrating an exemplary implementation in which, at the time of injection of a transport data record, an insert into the RELATION table  1501  holds cumulative values for “urgency” and “flush” for all messages with the same sender and type “pathway”, with the current value of such cumulations injected into the MESSAGE table  1507 ; which simplifies and streamlines queries for aggregation by sender  1525  and next message to play by sender  1546 . While this approach offers computational efficiencies, there is less flexibility for the user interface to offer multiple selections. 
       FIG. 16  is a flowchart similar to  FIG. 12 , illustrating an exemplary process that presents in a user interface an advantageously sorted list of messages available for play that fit the user interface specification and the user&#39;s selections, after an advantageous reduction, in accordance with the present invention.  FIG. 17  is an exemplary implementation of an SQLite database query, similar to  FIG. 13 , that produces an advantageously sorted list of messages available for play, associated with one or more selected senders, after an advantageous reduction in accordance with the present invention.  FIG. 18  is an exemplary implementation of an SQLite database query, similar to  FIG. 14 , that produces an advantageously sorted list of messages available for play, associated with one or more selected subject tags, after reduction and sorting in accordance with the present invention. 
     As discussed herein, in some preferred embodiments, user interface specifications and user selections may group together messages from multiple senders, whose judgments about “urgency” and “flush” are then treated equally and collectively in respect to reduction and sorting in accordance with the present invention. In additional preferred embodiments, special purpose services mediated by a messaging server  210  apply common attributes to messages from multiple senders that facilitate such a grouping together. 
       FIG. 19  illustrates an exemplary audio or video near real-time messaging communication system in which messages are routed, redirected or reflected to recipients using social network, geographical and subject tag data in accordance with the present invention. In accordance with methods known by practitioners of the art, in the exemplary transport data record  1905 , a relation_id record  1910  references a relationship between a sending user and a notional user representing a special purpose service. Receipt of the data record by the messaging server  1915  triggers a special purpose service that utilizes fields of the data record and additional data accessible by the messaging server and/or supporting databases and analytical servers  1915  (referred to herein as “reflector” services) to replace or augment the fields of the data record. A preferred embodiment group chat service rewrites the relation_id  1920  record to reference a plurality of relationships  1925  between the notional user and recipient users held in the database records of the messaging server, and adds an additional field reference_person_id which passes the identity of the sender. In accordance with the present invention, and illustrating some of its original, innovative and advantageous aspects, recipients then have the option to group messages in accordance with user interface specifications and selections such as membership in a group chat, by sender or common subject tags, for the purpose of filtering and sorting in accordance with the present invention. 
     A preferred embodiment social networking service for broadcast multicasting performs a similar rewrite and augmentation of the data transport record using social networking data held on supporting servers providing reflector services  1815 , which multicasts messages to recipients according to subject tags and degrees of separation in a social graph. A preferred embodiment geolocation-based broadcasting service performs a similar rewrite and augmentation of the data transport record using geolocation data held on supporting servers providing reflector services  1815 , which multicasts messages to recipients according to subject tags and geographic proximity. In these additional preferred embodiments, recipients then have the option to group messages in accordance with user interface specifications and selections, such as by degree of separation in a social graph, or by sender, subject tag or geo-proximity, for the purpose of filtering and sorting in accordance with the present invention.