Patent Description:
The present disclosure relates to the fields of mobile computing and communication, in particular, to message notification alert method and apparatus.

With advances in integrated circuit, computing and communication technologies, there are increasing numbers of laptops, smartphones, tablets and other mobile computing and/or communication devices being used. It is not uncommon to have several computing and/or communication devices proximally located within each other, and active at any one time. In such cases, it is annoying that all of these devices generate audio notification alerts for the same incoming message, be that email, Facebook notifications, Twitter messages, and so forth. Due to network path delays and device 'polling' settings, the different instances of the same message may arrive at the different devices at slightly different times, resulting in a symphony of successive audio notification alerts of the various arrivals. This is particularly annoying at meal times or other social events.

<CIT> and <CIT> relate to background knowledge.

In the following description, any embodiment referred to and not falling within the scope of the claims is merely an example useful to the understanding of the invention.

Embodiments are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings.

The present disclosure presents methods and apparatuses for message notification alert. In particular, the present disclosure presents methods and apparatuses for coordinating audio notification alert for receipt of the same message by multiple proximally located devices. In the embodiment, an apparatus for computing includes a receiver; a speaker; circuitry coupled to the receiver and speaker; and a service to be operated by the circuitry to receive an instance of a message via the receiver, and to conditionally affect a provision, through the speaker, an audio notification alert of the receipt of the instance of the message. In the embodiment, to conditionally affect the provision includes to bypass or cause to bypass of the provision of the audio notification alert, on determination that another audio notification alert has been or will be provided by another proximally located apparatus for receiving another instance of the same message.

In the description to follow, reference is made to the accompanying drawings, which form a part hereof wherein like numerals designate like parts throughout, and in which is shown by way of illustration embodiments that may be practiced. It is to be understood that other embodiments may be utilized.

Operations of various methods may be described as multiple discrete actions or operations in turn, in a manner that is most helpful in understanding the claimed subject matter. However, the order of description should not be construed as to imply that these operations are necessarily order dependent. In particular, these operations may not be performed in the order of presentation. Operations described may be performed in a different order than the described embodiments. Various additional operations may be performed and/or described operations may be omitted, split or combined in additional embodiments.

As used hereinafter, including the claims, the terms "interface" and "engine" may refer to, be part of, or include an Application Specific Integrated Circuit (ASIC), an electronic circuit, a programmable combinational logic circuit (e.g., field programmable gate arrays (FPGA)), a processor (shared or dedicate) and/or memory (shared or dedicated) that execute a plurality of programming instructions of one or more software or firmware programs to provide the described functionality.

Referring now <FIG>, wherein an overview of an example computing and/or communication environment having the audio notification alert coordination technology of the present disclosure, in accordance with various embodiments, is shown. As illustrated, example computing and/or communication environment <NUM> may include a number of computing devices 102a-102d proximally located to each other at particular point in time. For example, a number of laptops, smartphones, tablets and so forth may be proximally located to each other in a session of a conference, or at a family dinner. In the example conference session situation, all the devices may receive the same conference related announcement message or email, e.g., message <NUM>, at roughly (but not exactly) the same time, resulting in a symphony of successive audio notification alerts, e.g., <NUM>, of receipt of the same conference related announcement message or email, unless all the devices are silenced. Similarly, in the sample family dinner situation, all the devices may receive a social message, e.g., message <NUM>, from a common friend of a social network at roughly (but not exactly) the same time, resulting also in a symphony of audio notification alerts, e.g., <NUM>, of receipt of the same social message, unless all the devices are silenced.

To prevent or reduce the likelihood of such annoying/undesirable experience, devices 102a-102d may be respectively incorporated with the audio notification alert coordination (ANAC) technology of the present disclosure. For ease of illustration, incorporation of the ANAC technology is illustrated for device 102d only. As a result of the respective incorporation of the ANAC technology in devices 102a-102d, typically, only one device, the earliest receiving device of an instance of message <NUM>, would provide audio notification alert <NUM> for the receipt of message <NUM>. Other devices 102a, 102c and 102d, receiving their respective instances of message <NUM> would suppress or bypassing generation of the audio notification alert <NUM>, thereby potentially providing an enhanced user experience for users of devices 102a-102d.

It should be noted while for ease of understanding, only four (<NUM>) devices are illustrated in <FIG>, in real life, there could be many more devices of many more users proximally located from each other at one point in time, with each potentially giving audio notification alerts for receipt of incoming messages. On the other hand, in embodiments, the practice may be limited to devices of a single user, that is, a user with multiple devices (e.g., a tablet and a smartphone) will receive only one audio alert.

Referring now to <FIG>, wherein the computing and/or communication environment of <FIG> is illustrated in further detail, in accordance with various embodiments. As shown, in embodiments, ANAC technology <NUM> incorporated in a device 102a-102d may include coordination logic <NUM>. In embodiments, coordination logic <NUM> may be configured to monitor for receipt of messages. In embodiments, coordination logic <NUM> may register itself with a service of an operating system of a device to notify coordination logic <NUM> about arrivals of messages. Further, coordination logic <NUM> may be configured to determine, on detection or notification of the receipt of a message, whether the received message is already known to at least one of the other proximally located devices 102a-102d. In embodiments, coordination logic <NUM> is provided with an associated table <NUM> to store identifiers of received messages, to allow coordination logic <NUM> to determine whether the received message is already known to at least one of the other proximally located devices 102a-102d. In embodiments, the message identifiers may be hash values generated based on content of the messages (to be described more fully below). In some embodiments, the message identifiers may be hash values generated further based on other secondary factors, such as group identifiers or individual email addresses, in addition to the content of the messages, to provide more granular scope of coordination. For example, if the message identifiers are hash values generated further based on individual email addresses, alert coordination would apply only to messages received by devices of the same user, e.g., a user having a mobile phone, a laptop, and so forth, proximally disposed to each other. In some embodiments, the message identifiers may be hash values generated based at least on the sender and recipient email addresses. In any case, table <NUM> is referred to as message hash table <NUM>.

On determination that the received message is not already known to at least one of the other proximally located devices 102a-102d, coordination logic <NUM> may broadcast a message receipt notification <NUM> for the other devices 102a-102d, informing the other devices 102a-102d of the first receipt of the message. On broadcast of the message receipt notification <NUM>, coordination logic <NUM> may take no further action in suppression of the generation of audio notification alert <NUM>, allowing the users of devices 102a-102d to be audibly notified of the receipt of the message. Alternatively, in embodiments, coordination logic <NUM> may be configured to affirmatively cause the generation of audio notification alert <NUM> (e.g., request the notification service of the operating system of the device to generate audio notification alert <NUM>.

On the other hand, on determination that the received message is already known to at least one of the other proximally located devices 102a-102d, coordination logic <NUM> may skip broadcasting of a message receipt notification <NUM> for the other devices 102a-102d. Further, coordination logic <NUM> may take affirmative action in suppression of the generation of audio notification alert <NUM> for the received message, to avoid duplication of audio notification alert having been or to be provided by the other devices 102a-102d. In embodiments, coordination logic <NUM> may be configured to affirmatively suppress the output of audio notification alert <NUM>, e.g., by shutting off audio outputs (such as, speakers) of the device), or request the notification service of the operating system of the device to skip generation and/or causing output of audio notification alert <NUM>.

In embodiments, coordination logic <NUM> may be implemented as a standalone middleware service of the device. In other embodiments, coordination logic <NUM> may be integrated with respective ones of the applications receiving the messages. In still other embodiments, coordination logic <NUM> may be integrated with the operating system of the device, e.g., a message notification service of the operating system.

In embodiments, message receipt notification <NUM> may be broadcast as an "ultrasonic" message, in a frequency that is outside the range of human hearing frequencies, such that it will not be heard by the users of devices 102a-102d. <FIG> illustrates an example "ultrasonic" message receipt notification <NUM> (in a frequency outside the range of human hearing frequencies). Example "ultrasonic" message receipt notification <NUM> may include a preamble portion <NUM> and a body portion <NUM>. Preamble portion <NUM> may include a signal signature to enable a receiving device to recognize the signal as an "ultrasonic" message receipt notification <NUM>. Body portion <NUM> may include a hash of the message to identify the message, and a device identifier to identify the broadcasting device.

Referring now to <FIG>, wherein example processes for coordinating message notification alerts, in accordance with various embodiments, is shown. As illustrated, processes for coordinating message notification alerts may include processes <NUM>, <NUM> and <NUM>. Processes <NUM>, <NUM> and <NUM> may be performed e.g., by the earlier described coordination logic <NUM> of ANAC technology incorporated in a device 102a-102d. In alternate embodiments, processes <NUM>, <NUM> and <NUM> may include more or less operations, the operations may be combined or split, or having the operations performed in different order.

Process <NUM> may be associated with monitoring for receipt of a new message. Process <NUM> may start at block <NUM> where the receipt or an arrival of a message is detected. The message may be received e.g., through a receiver of the device. Next at block <NUM>, a determination may be made on whether the received message is already known to at least one of the proximally located/neighboring devices (to be described more fully later on with references to <FIG>).

If the received message is already known to at least one of the proximally located/neighboring devices (Yes ("Y") branch), process <NUM> may proceed to block <NUM>. At block <NUM>, the provision of audio message notification alert may be skipped or suppressed. As described earlier, depending on implementation, having the received message subsequently displayed on the receiving device (on request of the user of the device), without providing any audio alert of the arrival of the message, may involve affirmative action on the part of coordination logic <NUM>, such as shutting off the audio outputs (e.g., speakers) of the device temporarily, or requesting a notification service of an operating system to skip triggering the audio alert.

On the other hand, if the received message is not already known to at least one of the proximally located/neighboring devices (No ("N") branch), process <NUM> may proceed to block <NUM>. At block <NUM>, an "ultrasonic" message receipt notification may be broadcast for the neighboring devices at a frequency outside the human hearing frequencies. In embodiments, a user device may include a power-saving mode, when selected by the user, the device would power on the receiver (e.g., microphone) for a limited duration to listen for the "ultrasonic" message. Next, at block <NUM>, the audio message notification alert may be provided. Thereafter, the received message may be displayed on the receiving device, on request of the user of the device. As described earlier, depending on implementation, provision of the audio message notification alert, may involve affirmative action on the part of coordination logic <NUM>, such as requesting a notification service of an operating system to trigger the audio alert, or take no action to influence the triggering of the audio alert by a notification service of the operating system.

<FIG> illustrates an embodiment for a process for implement the determination performed at block <NUM> of <FIG>. Process <NUM> for implementing the determination performed at block <NUM> of <FIG> to ascertain whether the received message is already known to at least one of the neighboring devices may include operations performed at blocks <NUM>-<NUM>.

Process <NUM> may start at block <NUM>. At block <NUM>, a hash may be generated for a receipt message, based at least in part on the content of the message, to serve as an identifier of the message. Next, at block <NUM>, a determination may be made using the generated hash to ascertain whether a hash of the message has already been stored in a message hash table. The presence of the message hash in the message hash table may signify the message is already known to at least one of the other neighboring devices (earlier received by the at least one of the other neighboring devices). If a result of the determination indicates that the message hash is already in the message hash table (Yes "Y" branch), process <NUM> may end, and an inference may be made that the message is already known to at least one of the other neighboring devices. On the other hand, if a result of the determination indicates that the message hash is not already in the message hash table (No "N" branch), process <NUM> may proceed to block <NUM>. At block <NUM>, the message hash along with an identifier identifying the device may be stored in the message hash table, and an inference may be made that the message is not already known to at least one of the other neighboring devices. The device is the first among the devices in receiving the message.

<FIG> illustrates an embodiment for a process for listening or monitoring for the "ultrasonic" message receipt notifications broadcast by the neighboring devices. Process <NUM> for monitoring or listening for the "ultrasonic" message receipt notifications broadcast by the neighboring devices may include operations performed at blocks <NUM>-<NUM>.

Process <NUM> may start at block <NUM>. At block <NUM>, an "ultrasonic" message receipt notification may be detected/received, e.g., via a microphone of the device. Next at block <NUM>, a determination may be made on whether the "ultrasonic" message receipt notification is broadcast by another device. If a result of the determination indicates that the "ultrasonic" message receipt notification is not broadcast by another device (No "N" branch), process <NUM> may end. The "ultrasonic" message receipt notification was broadcast by the device itself. In embodiments, the determination may be made based at least in part on the device identifier included in the "ultrasonic" message receipt notification.

On the other hand, if a result of the determination indicates that the "ultrasonic" message receipt notification was broadcast by a neighboring device (Yes "Y" branch), process <NUM> may proceed to block <NUM>, or optionally at block <NUM> first. For embodiments where e.g., due to the duration of the broadcast, an "ultrasonic" message receipt notification may be received more than once by a device, process <NUM> may proceed to block <NUM> first. At block <NUM>, a determination may be made on whether the message hash and the device identifier pair has already been saved in the message hash table. If a result of the determination indicates the message hash and the device identifier pair has already been saved in the message hash table (Yes "Y" branch), process <NUM> may end. If a result of the determination indicates the message hash and the device identifier pair has not already been saved in the message hash table (No "N" branch), process <NUM> may proceed to block <NUM>.

At block <NUM>, the message hash and the device identifier pair may be saved in the message hash table, allowing the device to determine that the message is already known to a neighboring device, if the device later receives the same message.

Referring now to <FIG>, wherein a block diagram of a computer device suitable for use to practice the present disclosure (or aspects thereof), in accordance with various embodiments, is illustrated. As shown, in embodiments, computer device <NUM> may include one or more processors <NUM> and system memory <NUM>. Each processor <NUM> may include one or more processor cores. In embodiments, one or more processors <NUM> may include one or more hardware accelerators <NUM> (such as, FPGA). System memory <NUM> may include any known volatile or non-volatile memory. Additionally, computer device <NUM> may include mass storage device(s) <NUM> (such as solid state drives), input/output device interface <NUM> (to interface with e.g., speakers, microphone, and so forth <NUM>) and communication interfaces <NUM> (such as serial interface, near field communication, network interface cards, modems and so forth having their respective transmitters, receivers or transceivers). The elements may be coupled to each other via system bus <NUM>, which may represent one or more buses. In the case of multiple buses, they may be bridged by one or more bus bridges (not shown).

Each of these elements may perform its conventional functions known in the art. In particular, system memory <NUM> and mass storage device(s) <NUM> may be employed to store a working copy and a permanent copy of the executable code of the programming instructions implementing the operations described earlier, e.g., but are not limited to, operations associated with coordination logic <NUM> (with message hash table <NUM>). In embodiments, the executable code of the programming instructions may also implement an operating system (OS) with notification service <NUM> and/or one or more applications <NUM>. In embodiments, as described earlier, coordination logic <NUM> may be implemented as a standalone middleware, integrated with applications <NUM> or integrated with OS <NUM>. The programming instructions may comprise assembler instructions supported by processor(s) <NUM> or high-level languages, such as, for example, C, that can be compiled into such instructions. In embodiments, some of the functions performed by applications <NUM>, coordination logic <NUM> and/or OS <NUM> may be implemented with hardware accelerator <NUM> instead.

The permanent copy of the executable code of the programming instructions and/or the bit streams to configure hardware accelerator <NUM> may be placed into permanent mass storage device(s) <NUM> or hardware accelerator <NUM> in the factory, or in the field, through, for example, a distribution medium (not shown), such as a compact disc (CD), or through communication interface <NUM> (from a distribution server (not shown)).

Except for the use of computer device <NUM> to host coordination logic <NUM> and message hash table <NUM>, the constitutions of the elements <NUM>-<NUM> are otherwise known, and accordingly will not be further described.

Referring now to <FIG>, wherein an example non-transitory computer-readable storage medium having instructions configured to practice all or selected ones of the operations associated with applications <NUM>, coordination logic <NUM> and/or OS <NUM>, in accordance with various embodiments, is shown. As illustrated, non-transitory computer-readable storage medium <NUM> may include the executable code of a number of programming instructions <NUM>. Executable code of programming instructions <NUM> may be configured to enable a system, e.g., device 102a-102d or computer device <NUM>, in response to execution of the executable code/programming instructions, to perform, e.g., various operations associated with coordination logic <NUM>. In alternate embodiments, executable code/programming instructions <NUM> may be disposed on multiple non-transitory computer-readable storage medium <NUM> instead. In still other embodiments, executable code/programming instructions <NUM> may be encoded in transitory computer readable medium, such as signals.

In embodiments, a processor may be packaged together with a computer-readable storage medium having some or all of executable code of programming instructions <NUM> configured to practice all or selected ones of the operations earlier described. For one embodiment, a processor may be packaged together with such executable code <NUM> to form a System in Package (SiP). For one embodiment, a processor may be integrated on the same die with a computer-readable storage medium having such executable code <NUM>. For one embodiment, a processor may be packaged together with a computer-readable storage medium having such executable code <NUM> to form a System on Chip (SoC). For at least one embodiment, the SoC may be utilized in, e.g., client device 102a-102d.

Claim 1:
An apparatus (102a, 102b, 102c, 102d) for computing, comprising:
a receiver;
a speaker;
circuitry coupled to the receiver and speaker; and
a software or firmware program to be operated by the circuitry to receive an instance of a message via the receiver, and to conditionally affect a provision, through the speaker, an audio notification alert of the receipt of the instance of the message;
wherein to conditionally affect the provision includes to bypass or cause bypass of the provision of the audio notification alert, on determination that another audio notification alert has been or will be provided by another proximally located apparatus for receiving another instance of the same message,
wherein on receipt of the instance of the message, the software or firmware program determines whether there is such another proximally located apparatus having received the another instance of the same message, and provided or about to provide the another audio notification alert, and
wherein to determine whether there is such another proximally located apparatus having received the another instance of the same message, the software or firmware program is configured to generate a hash for the message based at least in part on content of the message, check for whether the hash has already been previously stored in a message hash table on the apparatus, and check the message hash table for information indicating the apparatus having been ultrasonically informed by such another proximally located apparatus having received the another instance of the same message.