U.S. patent application number 13/554996 was filed with the patent office on 2013-02-28 for event notification system and method.
The applicant listed for this patent is Onno Bakker, Jan-Joost Rueb, Paulo Taylor. Invention is credited to Onno Bakker, Jan-Joost Rueb, Paulo Taylor.
Application Number | 20130054715 13/554996 |
Document ID | / |
Family ID | 38442005 |
Filed Date | 2013-02-28 |
United States Patent
Application |
20130054715 |
Kind Code |
A1 |
Taylor; Paulo ; et
al. |
February 28, 2013 |
EVENT NOTIFICATION SYSTEM AND METHOD
Abstract
A technique for user notification involves modifying a title
associated with a process to include information about an event
that calls for user notification. A method according to the
technique may include running a process, processing an event,
generating a string of characters that includes information
associated with the event, and displaying the string of characters
as a title associated with the process. A system constructed
according to the technique may include a client, a title array, an
event processing engine, and a title provisioning engine.
Inventors: |
Taylor; Paulo; (US) ;
Rueb; Jan-Joost; (US) ; Bakker; Onno;
(US) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Taylor; Paulo
Rueb; Jan-Joost
Bakker; Onno |
|
|
US
US
US |
|
|
Family ID: |
38442005 |
Appl. No.: |
13/554996 |
Filed: |
July 20, 2012 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
13165709 |
Jun 21, 2011 |
8230135 |
|
|
13554996 |
|
|
|
|
Current U.S.
Class: |
709/206 |
Current CPC
Class: |
H04L 51/043 20130101;
H04L 51/04 20130101; G06Q 10/10 20130101; H04L 51/066 20130101;
H04L 67/2823 20130101; H04L 51/22 20130101; G06F 16/958 20190101;
H04L 67/306 20130101; H04L 51/16 20130101; G06Q 10/107 20130101;
H04L 67/2814 20130101; G06F 9/542 20130101; H04M 1/72547 20130101;
H04L 65/403 20130101; H04L 67/02 20130101; H04M 3/493 20130101;
H04L 65/00 20130101; H04L 67/1044 20130101; H04L 51/00
20130101 |
Class at
Publication: |
709/206 |
International
Class: |
G06F 15/16 20060101
G06F015/16 |
Claims
1. A method comprising: processing an event that calls for user
notification; generating an event notification for the event;
storing the event notification in an array; providing the event
notification from the array to a process executed by a processor;
using the event notification as a title in association with the
process; providing an alternative title from the array to the
process; using the alternative title as a title in association with
the process.
2. The method of claim 1, further comprising: generating the
alternative title, wherein the alternative title is associated with
the event; storing the alternative title in the array.
3. The method of claim 1, wherein the event is a first event and
the alternative title is a second event notification, further
comprising: processing a second event that calls for user
notification; generating the second event notification for the
second event; storing the second event notification in the
array.
4. The method of claim 1, further comprising alternating using the
event notification as a title in association with the process with
using a NULL string.
5. The method of claim 1, further comprising generating the
alternative title as a NULL string.
6. The method of claim 1, further comprising alternating using the
event notification as a title in association with the process with
a variation of the event notification.
7. The method of claim 1, further comprising generating the
alternative title as a variation of the event notification.
8. The method of claim 1, further comprising: receiving affirmation
that user notification was successful; clearing the array.
9. The method of claim 1, further comprising repetitively using the
event notification as a title in association with the process.
10. The method of claim 1, further comprising: using the event
notification as a title in association with the process one or more
times; removing the event notification from the array.
11. A system comprising: a means for processing an event that calls
for user notification; a means for generating an event notification
for the event; a means for storing the event notification in an
array; a means for providing the event notification from the array
to a process; a means for using the event notification as a title
in association with the process; a means for providing an
alternative title from the array to the process; a means for using
the alternative title as a title in association with the
process.
12. The system of claim 11, further comprising: generating the
alternative title, wherein the alternative title is associated with
the event; storing the alternative title in the array.
13. The system of claim 11, wherein the event is a first event and
the alternative title is a second event notification, further
comprising: a means for processing a second event that calls for
user notification; a means for generating the second event
notification for the second event; a means for storing the second
event notification in the array.
14. The system of claim 11, further comprising a means for
alternating using the event notification as a title in association
with the process with using a NULL string.
15. The system of claim 11, further comprising a means for
generating the alternative title as a NULL string.
16. The system of claim 11, further comprising a means for
alternating using the event notification as a title in association
with the process with a variation of the event notification.
17. The system of claim 11, further comprising a means for
generating the alternative title as a variation of the event
notification.
18. The system of claim 11, further comprising: a means for
receiving affirmation that user notification was successful; a
means for clearing the array.
19. The system of claim 11, further comprising a means for
repetitively using the event notification as a title in association
with the process.
20. The system of claim 11, further comprising: a means for using
the event notification as a title in association with the process
one or more times; a means for removing the event notification from
the array.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation application of U.S. Ser.
No. 13/165,709, filed Jun. 21, 2011, entitled EVENT NOTIFICATION
SYSTEM AND METHOD, which claims priority to U.S. Ser. No.
11/637,514, filed Dec. 11, 2006, entitled EVENT NOTIFICATION SYSTEM
AND METHOD, which claims priority to U.S. Provisional Patent
Application Ser. No. 60/748,988, filed Dec. 9, 2005, which are
incorporated herein by reference. This Patent Application is
related to U.S. patent application Ser. Nos. 12/721,538, filed Mar.
10, 2010, entitled HIGH LEVEL NETWORK LAYER SYSTEM AND METHOD,
which is a continuation of U.S. Pat. No. 7,730,144, filed Dec. 11,
2006; 11/637,268, filed Dec. 11, 2006, entitled PICTURE
PROVISIONING SYSTEM AND METHOD; 11/637,964 filed Dec. 11, 2006,
entitled MESSAGE HISTORY DISPLAY SYSTEM AND METHOD; and 11/637,316
filed Dec. 11, 2006, entitled CONTACT LIST DISPLAY SYSTEM AND
METHOD.
BACKGROUND
[0002] Instant messaging requires the use of a client program that
hooks up an instant messaging service and differs from e-mail in
that conversations are then able to happen in real time. Most
services offer a presence information feature, indicating whether
people on one's list of contacts are currently online and available
to chat. This may be called a contact list. In early instant
messaging programs, each letter appeared as it was typed, and when
letters were deleted to correct typos this was also seen in real
time. This made it more like a telephone conversation than
exchanging letters. In modern instant messaging programs, the other
party in the conversation generally only sees each line of text
right after a new line is started. Most instant messaging
applications also include the ability to set a status message,
roughly analogous to the message on a telephone answering
machine.
[0003] Popular instant messaging services on the public Internet
include .NET Messenger Service, MSN Messenger, AOL Instant
Messenger, Excite/Pal, Gadu-Gadu, Google Talk, iChat, ICQ, Jabber,
Qnext, QQ, Meetro, Skype, Trillian and Yahoo! Messenger. These
services owe many ideas to an older (and still popular) online chat
medium known as Internet Relay Chat (IRC).
[0004] The foregoing examples of the related art and limitations
related therewith are intended to be illustrative and not
exclusive. Other limitations of the related art will become
apparent to those of skill in the art upon a reading of the
specification and a study of the drawings.
SUMMARY
[0005] The following embodiments and aspects thereof are described
and illustrated in conjunction with systems, tools, and methods
that are meant to be exemplary and illustrative, not limiting in
scope. In various embodiments, one or more of the above-described
problems have been reduced or eliminated, while other embodiments
are directed to other improvements.
[0006] A technique for user notification involves modifying a title
associated with a process to include information about an event
that calls for user notification. A method according to the
technique may include running a process, such as, by way of example
but not limitation, an IM client process, a browser, or some other
process that has a title associated therewith. The method may
further include processing an event, such as by way of example but
not limitation, a new mail event, a new instant message event, a
reminder event, a calendar event, or some other event, and
generating a string of characters that includes information
associated with the event. The method may further include
displaying the string of characters as a title associated with the
process. A system constructed according to the technique may
include a client, a title array, an event processing engine, and a
title provisioning engine.
BRIEF DESCRIPTION OF THE DRAWINGS
[0007] Embodiments of the inventions are illustrated in the
figures. However, the embodiments and figures are illustrative
rather than limiting; they provide examples of the invention.
[0008] FIG. 1 depicts an example of a system for providing instant
messages to clients via a web interface.
[0009] FIG. 2 depicts an example of a system for displaying content
from an IM client at an alternative IM client.
[0010] FIGS. 3A-3D depict examples of screenshots with IM
notification functionality.
[0011] FIG. 4 depicts a flowchart of an example of a method for
changing a title associated with a titlebar.
[0012] FIG. 5 depicts a flowchart of an example of a method for
displaying an event-related title.
[0013] FIG. 6 depicts an example of a system for programmed text
event-specific title provisioning.
[0014] FIG. 7 depicts a flowchart of an example of a method for
displaying programmed text titles.
[0015] FIG. 8 depicts a computer system suitable for implementation
of the techniques described above with reference to FIGS. 1-7.
DETAILED DESCRIPTION
[0016] In the following description, several specific details are
presented to provide a thorough understanding of embodiments of the
invention. One skilled in the relevant art will recognize, however,
that the invention can be practiced without one or more of the
specific details, or in combination with other components, etc. In
other instances, well-known implementations or operations are not
shown or described in detail to avoid obscuring aspects of various
embodiments, of the invention.
[0017] FIG. 1 depicts an example of a system 100 for providing
instant messages to clients via a web interface. In the example of
FIG. 1, the system 100 includes a network 102, a server 104, and an
Instant Messenger (IM) server 106, and an IM network 108. The
server 104 is coupled to the network at least by way of port 80.
The two way communication via port 80 is represented in the example
of FIG. 1 as an arrow 110. The server 104 is coupled to the IM
server 106 via one or more other ports. The two way communication
via the other ports is represented in the example of FIG. 1 as an
arrow 112. The IM server 106 is coupled to the IM network 108 via
any known or convenient mechanism. Indeed, the IM server 106 may be
thought of as part of the IM network 108. The network 102 couples a
plurality of clients 114-1 to 114-N (referred to collectively as
clients 114) to the server 104. In the example of FIG. 1, the
server 104 includes an event queue 116.
[0018] The network 102 may include by way of example but not
limitation LAN, WAN, VLAN, WLAN, Internet, cellular network, phone
network, radio network, or some other known or convenient network.
The term "Internet" as used herein refers to a network of networks
that uses certain protocols, such as TCP/IP, and possibly other
protocols such as the hypertext transfer protocol (HTTP) for
hypertext markup language (HTML) documents that make up the World
Wide Web (the web). The physical connections of the Internet and
the protocols and communication procedures are well known, but any
convenient physical connections or protocols could be used.
[0019] The server 104 may include a multiple servers. Indeed, it
may be desirable, depending upon details of a particular
implementation, to install several servers to cope with the number
of simultaneous users the system 100 supports. It may further be
desirable, depending upon details of a particular implementation,
for the server 104 to have a high CPU throughput, together with
large amounts of RAM, to handle a large number of users. It may
further be desirable, depending upon details of a particular
implementation, to accomplish resource sharing via thread handling
where a pool of threads is shared and used by one or more of the
clients 114 for client-server communication and between the server
104 and the IM server 106.
[0020] The server 104 may include one or more of an application
server, database server, web server, banners server, and content
server, or any combination thereof. To make the most of the
techniques described herein, the server 104 should, though is not
required to, include at least one application server. The other
servers can have supporting roles in, by way of example but not
limitation, serving static content or advertising (e.g., banners),
storing usage data, or fulfilling some other known or convenient
function.
[0021] The server 104 may act as a proxy server between the clients
114 and the IM server 106. The server 104 receives communications
from the clients 114 on http port 80, and responds to the clients
114 on http port 80. Communications from the clients 114 that are
bound for the IM network 108, however, must also come through http
port 80 to the server 104, and are then forwarded to the IM server
106. In this way, the server 104 acts as a carrier of the data from
users to the IM network 108 using a mechanism that controls and
manages the data (e.g., text messages, display images, emoticons,
audio/video streams, etc.) sent between one of the clients 114 and
the server 104, and vice versa.
[0022] The IM server 106 may be any known or convenient IM server
that is compatible with IM. Events, messages, or other appropriate
data from the IM server 106 are collected in the event queue 116 of
the server 104. The events may be collected in association with a
variety of protocols including by way of example but not limitation
port 1863, port 5050, port 5222, port 5190, etc.
[0023] The IM network 108 may include one or a combination of
networks selected from MSN Messenger, Yahoo! Messenger, AIM AOL,
ICQ, QQ, Jabber, Google Talk, IRC, or some other known or
convenient IM network.
[0024] The clients 114 may include any known or convenient device,
including by way of example but not limitation, a Web browser,
mobile client, PDA, game console, TV box, native application, etc.
The clients poll the server 104 for events. The events can be
removed from the event queue 116 and translated into text,
JavaScript, XML, or some other known or convenient format that one
or more of the clients 114 need or expect in order to process data
associated with the event.
[0025] To interact with the IM network 108, the clients 114 send
data to the server 104. The data, which may include commands, is
processed and translated into corresponding data that will be sent
to the appropriate IM network. In an embodiment, the appropriate IM
network may be determinable based upon the protocol encoded in a
message.
[0026] Messages or actions from the clients 114 are collected over
network protocols such as, by way of example but not limitation,
HTTP or plain socket connections. The messages or actions are
transformed to an appropriate protocol format to be sent over a
compliant port from the clients 114 to the server 104, with the IM
protocol on the application side. In a non-limiting embodiment, the
compliant port is http port 80. However, any port having similar
characteristics to those of a typical port 80 could be used.
[0027] The latest available browsers, as of December 2005, enable
the use of a technique called AJAX (Asynchronous JavaScript And
XML). With AJAX, appropriately configured clients 114 can execute
actions and poll for messages or events using only JavaScript. The
method is based on using an XMLHttpRequest object to make HTTP
requests to the server 104. The server 104 may reply with messages
taken from the queue of the corresponding session in XML (or
another) format that are parsed and displayed according to the
message content.
[0028] For clients 114 that include a browser, when accessing the
server 104 the browser typically uses hidden HTML frames to update
information on visible frames. The visible frames display
appropriate information while the hidden frames are reloaded in
short periods of time. In each refresh that hits the server 104,
the browser identifies the current messaging session and checks if
new events or messages associated with the session are in the event
queue 116. When new information arrives and needs to be displayed
in some form, the browser makes use of, for example, JavaScript
code to update the visible frames and windows with new messages or
events keeping the information up to date in the screen. In this
way, automatic refreshing can take place in a hidden frame.
[0029] In another embodiment, certain of the clients 114 with
browsers may not make use of refreshes. For example, a form of
updating the screen without using a refresh technique is to keep
one single HTTP socket request alive for the whole period of a
messaging session without actually closing the socket connection.
In this example, information is initially loaded and displayed in
one single visible frame. While events and messages are being
received by the server 104, JavaScript code can be injected into
the HTML document through the same HTTP socket kept alive and
managed by the server 104. For each event or message, the browser
can interpret the JavaScript code injected and the corresponding
parts of the HTML document and windows will be updated.
[0030] In another embodiment, certain of the clients 114 with
browsers may make use of manual refreshes. Some relatively
unsophisticated browsers, such as WAP and xHTML browsers often
available on mobile phones, do not support hidden frames and/or
JavaScript (and others may be configured such that they do not
support hidden frames and/or JavaScript). In such cases, the
information displayed has to be updated manually by the user.
Manual updating enables any mobile phone, PDA, TV Set or any device
with a browser to connect to the server 104 and use the messaging
platforms made available by the server 104 assuring the
communication between the clients 114 and the IM server 106.
[0031] Message history can be stored by most IM clients on a local
computer. For alternative web and mobile-based.clients local
storage may not be possible. In a non-limiting embodiment, the
server 104, may have the capability to store message history from
IM conversations done via one or more of the clients 114. The
message history can be accessed and searched at any time via the
server 104 by one or more of the clients 114
[0032] FIG. 2 depicts an example of a system 200 for displaying
content from an IM client at an alternative IM client. In the
example of FIG. 2, the system 200 includes a client 202, an IM
network 204, a server 206, an IM network 208, a client 210, other
IM networks 212-1 to 212-N (referred to collectively as other IM
networks 212), and other clients 214-1 to 214-N (referred to
collectively as other clients 214).
[0033] For illustrative purposes, it is assumed that the client 202
has content that is compatible with the IM network 204. However,
the client 210 is capable of reading content formatted to be
compatible with the IM network 208. Thus, in operation, the server
206 collects content from the client 202 (either through the IM
network 204, as shown in FIG. 2, or directly from the client 202,
such as is shown by way of example in FIG. 1). The server 206 then
formats the content as appropriate for use on the IM network 208.
Once the content is properly formatted, it can be made available to
the client 210 (either through the IM network 208, as shown in FIG.
2, or directly to the client 210, such as is shown by way of
example in FIG. 1). Depending upon the embodiment and/or
implementation, the content may also be formatted as appropriate
for one or more of the other IM networks 212, to be made available
for one or more of the other clients 214.
[0034] As is well-understood, different devices provide different
functionality. For example, a desktop typically provides greater
storage, greater display area, and greater power than a cell phone.
Thus, at best, an IM client must work under the constraints imposed
by a particular device. Depending upon the device, certain
functionality may be more useful. For example, a device may have
inferior capabilities with respect to notifying a user when a
message is received.
[0035] The device capabilities may limit the way in which a user
can be notified when a message is received. The environment in
which a user operates may provide another limitation. For example,
a user at work may not want to play a noise or have a popup window
show up every time a message is received. Similarly, a user who
gets lots of messages may not want to hear the noise or see the
popup windows because of the great frequency with which it occurs.
Advantageously, notification can take place in a titlebar, which is
great for devices that have inferior notification functionality,
and great for users who want a subtle notification.
[0036] FIGS. 3A-3D depict examples of screenshots 300 with IM
notification functionality. The bar may be a titlebar, a taskbar,
or some other menu or display item. In the example of FIG. 3A, the
taskbar includes a process identified by the taskbar item 302. For
illustrative purposes, the process is a Firefox.RTM. web browser
that is at the site www.ebuddy.com. The screenshot appears as a
conventional screen might look. However, when a new message
arrives, the taskbar changes.
[0037] In the example of FIG. 3B, the taskbar includes the
Firefox.RTM. web browser process, but the taskbar item 304 appears
differently. Specifically, rather than depicting the site
www.ebuddy.com, the taskbar item 304 now indicates that a new
message is available. The IM notification functionality may be cool
on a desktop, but can be particularly useful in other
implementations.
[0038] For example, notifying a user when new messages arrive or
events happen can gracefully be done by a native IM application.
However, for alternative web clients this is more difficult given
the nature of control from within a browser to the Operating
System. There is less control for alerts like flashing windows etc.
from browsers. In such cases, it may be particularly advantageous
for a server to be able to provide a user with alerts for new
messages or events using the title bar, task bar, or other display
area of a browser.
[0039] In the example of FIG. 3C, the Firefox.RTM. browser is open,
and the taskbar item 306 indicates the current site is
www.ebuddy.com. The titlebar 308 includes similar information. If a
new message is received, then both the titlebar and the taskbar can
be changed.
[0040] In the example of FIG. 3D, the taskbar includes the
Firefox.RTM. web browser with a changed taskbar item 310. The
titlebar 312 is also changed to indicate a new message has been
received. The exact information in a titlebar, taskbar, or other
display area is implementation specific. Thus, the titlebar 312 is
simply illustrative. When an event, message, or other data is
available to the client, the titlebar 312 may change to show
information about the event. If properly configured, the taskbar
item 310 and the titlebar 312 could even display different
information (though in a typical implementation the text is
identical, albeit often necessarily shortened on the taskbar).
[0041] The title can be used to notify users of certain events by
changing the title of the IM client. The changing of the text in
the taskbar and/or titlebar may stand out from other taskbars
and/or with fixed texts.
[0042] FIG. 4 depicts a flowchart 400 of an example of a method for
changing a title associated with a titlebar (and an associated
taskbar item, if applicable). In the example of FIG. 4, the
flowchart 400 starts at module 402 where an IM client process is
running The IM client process may include, by way of example but
not limitation, a browser.
[0043] In the example of FIG. 4, the flowchart 400 continues to
decision point 404 where it is determined whether an event has been
received. If it is determined that an event has not been received
(404-N), then the flowchart 400 continues to decision point 406
where it is determined whether to terminate the IM client process.
If it is determined that the IM client process is to be terminated
(406-Y), then the flowchart 400 continues to module 408 where the
IM client process is terminated, and the flowchart 400 ends. If, on
the other hand, it is determined that the IM client process is not
to be terminated (406-N) then the flowchart 400 loops back to
decision point 404, as described above.
[0044] In the example of FIG. 4, eventually, assuming the IM client
process is not terminated (408), it is determined that an event has
been received (404-Y), and the flowchart 400 continues to module
410 where the event is processed. Events are processed in a known
or convenient manner.
[0045] In the example of FIG. 4, the flowchart 400 continues to
decision point 412 where it is determined whether notification is
called for. Events may or may not result in notification of a user,
depending upon the event, embodiment, implementation, device
limitations, and/or user's IM client configuration. If it is
determined that user notification is called for (412-Y), then the
flowchart 400 continues to module 414 where a title associated with
the IM client process is modified. If, on the other hand, it is
determined that user notification is not called for (412-N), or in
any case after module 414, the flowchart 400 loops back to decision
point 406, as described above.
[0046] Modifying the title (414) presumably modifies the display in
the applicable titlebar and/or the display in the applicable
taskbar item. Conventional browsers typically do not allow setting
a title in a titlebar that is different from the corresponding
taskbar item. However, a display area could display information
different from that of the title, if configured appropriately.
Moreover, future browsers may include functionality that allows
displaying different titles in the titlebar and the taskbar.
[0047] The title of the application may or may not keep the changed
value until the user takes some action (e.g., clicking on the
taskbar item associated with the IM client process). For example,
the original title could be displayed after a certain amount of
time has passed (e.g., a "new message" title could last for 10
seconds before reverting to the original title). FIG. 5 depicts a
flowchart 500 of an example of a method for displaying an
event-related title. In the example of FIG. 5, the flowchart 500
starts at module 502 where a browser is opened.
[0048] In the example of FIG. 5, the flowchart 500 continues to
module 504 a title associated with state of a browser is displayed
in association with the browser. The state of the browser may
include, for example, a current site for which the browser is
displaying a page, as is shown in FIGS. 3A and 3C. In general, the
title associated with state of the browser includes any title that
would normally be displayed in association therewith prior to
updating the title in response to an event notification.
[0049] In the example of FIG. 5, the flowchart 500 continues to
module 506 where an event trigger is received. The event trigger is
associated with an event that calls for notifying a user. For
example, the event trigger may include receipt of a new instant
message.
[0050] In the example of FIG. 5, the flowchart 500 continues to
module 508 where a title associated with the event is displayed in
association with the browser. Thus, the title associated with the
state of the browser is replaced by the title associated with the
event. Moreover, in a non-limiting embodiment, the state of the
browser is unchanged (other than the title, of course).
[0051] In the example of FIG. 5, the flowchart 500 continues to
decision point 510 where it is determined whether to close the
browser. If the browser is not to be closed (510-N), then the
flowchart 500 continues to decision point 512 where it is
determined whether to continue to display the title associated with
the event. If so (512-Y), then the flowchart 500 loops back to
module 508, as described previously. If not (512-N), then the
flowchart 500 loops back to module 504, as described previously.
The determination as to whether to continue to display the title
associated with the event may be based upon, by way of example but
not limitation, a notification timer, an event-specific timer, a
user action, or some other action that is sufficient to indicate
that the title associated with the event should not longer be
displayed. If, on the other hand, the browser is to be closed
(510-Y), then the flowchart 500 continues to module 514 where the
browser is closed, and the flowchart 500 ends.
[0052] The title of, e.g., a window shows up in both the titlebar
of a window and in the taskbar. Advantageously, users can be
notified of events in the taskbar, while they are using another
application. The changing taskbar would benefit clients on devices
using a desktop system that allows multiple applications to run at
the same time, e.g. Mail client, Browser, IM, etc. While users are
switching between various applications and an IM client they may
not be aware of new messages/events that have arrived. The
alternating messages can be seen in a taskbar even if, for example,
the browser window is minimized or behind other application or
browser windows (as in FIGS. 3A, 3B).
[0053] Advantageously, in an embodiment, a title associated with an
event can include programmed text effects. FIG. 6 depicts an
example of a system 600 for programmed text event-specific title
provisioning. The system 600 includes an input device 602, a
network 604, an output device 606, and a computer 610. The input
device 602 may be any known or convenient device that is capable of
generating or forwarding events to the computer 610. In a typical
implementation, events will be received at the computer 610 via the
network 604. Most computers include output devices for on which a
variety of output is displayed.
[0054] The computer 610 includes an interface 612, an event
processing engine 614, a title provisioning engine 616, a title
array 618, a multiplexer 620, and a client 622. The interface 612
may include an implementation-specific number of different kinds of
known or convenient interfaces. The input device 602, the network
604, and the output device 606 are coupled to the computer 610
using the interface 612.
[0055] An event received on the interface 612 (from either the
input device 602 or the network 604) is provided to the event
processing engine 614 for processing in a known or convenient
manner. The event processing engine 614 may be embodied in a
computer-readable medium. If user notification is desired for the
event, the user can be notified in any known or convenient
manner.
[0056] Advantageously, data associated with the event can also (or
in the alternative) be provided to the title provisioning engine
616. The title provisioning engine 616 may be embodied in a
computer-readable medium. In the example of FIG. 6, the title
provisioning engine 616 inputs title strings, which are strings of
characters, to the title array 618. The title array 618 includes
N-1 title array strings, embodied in a computer-readable medium,
which are referenced (for illustrative purposes) as title array
string [0] to title array string [N].
[0057] A given event may cause the title provisioning engine 616 to
rewrite the entire title array 618 with title strings associated
with the most recent events. Alternatively, a given event may cause
the title provisioning engine 616 to append title strings to the
end of the title array 618. In a non-limiting embodiment, the title
provisioning engine 616 updates the current title array 618 by
adding new data associated with an event, excluding redundant data
(e.g., data that is already represented in the title array
618).
[0058] In the example of FIG. 6, the multiplexer 620 selects one of
the title array strings for provisioning to the client 622. The
multiplexer 620 receives a control signal from the title
provisioning engine 616 to accomplish this task. The multiplexer
620 is a conceptual construct that is intended to illustrate
selecting one of the title array strings using an index to the
title array 618. Thus, the multiplexer 620 may or may not be
embodied in a computer-readable medium. It should be noted that the
multiplexer 620, in at least one embodiment, is not a hardware MUX,
though it could conceivably be implemented as such.
[0059] In the example of FIG. 6, the client 622 includes a title
string 624 and a title generator 626. The client 622 may include,
by way of example but not limitation, an IM client, an email
client, a VoIP client, or some other communications-related client.
The client 622 may include a window, panel, or some other display
that includes a title. The title generator 626 generates a title
for the display in a known or convenient manner.
[0060] However, in a non-limiting embodiment, the title
provisioning engine 616 controls the title generator 626 to either
generate a title in the usual way (e.g., using the state of the
client 622 to determine an appropriate title), or to not generate a
title because a title string is available from the title array 618.
Thus, title string 624, which is embodied in a computer-readable
medium in association with the display, will include either a title
generated in accordance with the state of the client 622 or a title
string from the title array 618 (specifically, the title array
string selected by the multiplexer 620). The display (e.g., a
window including the title string 624) is provided to the interface
612 for display on the output device 606.
[0061] Advantageously, although the title string 624 is likely to
have display limitations associated with the client 622, the
operating system, the output device 606, or other factors, creative
control of the title array 618 can yield interesting title display
characteristics. For example, the title can appear to have
scrolling text, blinking, alternating upper and lower case,
etc.
[0062] Scrolling text may be accomplished by cycling through the
title array 618 over time. After the title array string [N] is
displayed, the title array 618 can start over at title array string
[0], or allow the title generator 626 to generate a title instead.
The scrolling text could include the actual message of an IM
message, displayed in the title over time, the scrolling text could
scroll through a list of senders of email that has not yet been
checked. Blinking can be accomplished by, conceptually, making
every other title array string blank. Alternatively, a NULL string
could be periodically provided instead of a title array string. The
number of programmed text effects available to those of ordinary
skill in the art of computer programming, with this teaching before
them, are practically impossible to list exhaustively so no effort
is made to do so herein.
[0063] FIG. 7 depicts a flowchart 700 of an example of a method for
displaying programmed text titles. In the example of FIG. 7, the
flowchart 700 starts at module 702 where an event that calls for
user notification is processed. It may be noted that whether the
event calls for user notification may or may not be known until
after the event is processed.
[0064] In the example of FIG. 7, the flowchart 700 continues to
module 704 where a first string of characters associated with the
event is generated. There may or may not be a second, third, etc.
string of characters associated with the event generated, as
well.
[0065] In the example of FIG. 7, the flowchart 700 continues to
module 706 where the first string of characters is stored in an
array. The array may include other strings of characters associated
with other events, or the first string of characters (and second,
third, etc. string of characters) associated with the event may
replace all current characters strings of the array.
[0066] In the example of FIG. 7, the flowchart 700 continues to
module 708 where the first string of characters is provided from
the array to a process. The process may include, by way of example
but not limitation, an IM client operating in a Windows.RTM.
environment.
[0067] In the example of FIG. 7, the flowchart 700 continues to
module 710 where the first string of characters is used as a title
in association with the process. For example, if the process is an
IM client operating in a Windows.RTM. environment, the first string
of characters could be used such that the window associated with
the IM client includes the first string of characters (or at least
the first subset of the first string of characters, if the window
is too small to display the entire string) in the titlebar.
Similarly, in this specific example, the first string of characters
could be displayed in a taskbar item associated with the IM
client.
[0068] In the example of FIG. 7, the flowchart 700 continues to
module 712 where a second string of characters is provided from the
array to the process. The second string of characters could be
associated with the same event as the first string of characters,
an earlier event (where the second string remains in the array), or
a later event (where the second string replaces or is in addition
to strings associated with the last processed event). The second
string of characters could also be unassociated with an event. For
example, the second string of characters could be a NULL string
that has the effect of causing the first string of characters (if
provided before and after the second string of characters) to blink
or flash.
[0069] In the example of FIG. 7, the flowchart 700 continues to
module 714 where the second string of characters is used as a title
in association with the process. Then the flowchart 700 ends. It
should be noted that the flowchart 700 simply illustrates a first
and second string of characters from the array being used as a
title, and then ends. Of course, the flowchart could continue with
modules (not shown) where the first string of characters is
repeated as a title, another event is processed, a third string of
characters is provided, or with some other applicable module or
sequence of modules.
[0070] FIG. 8 depicts a computer system 800 suitable for
implementation of the techniques described above with reference to
FIGS. 1-7. The computer system 800 includes a computer 802, I/O
devices 804, and a display device 806. The computer 802 includes a
processor 808, a communications interface 810, memory 812, display
controller 814, non-volatile storage 816, and I/O controller 818.
The computer 802 may be coupled to or include the I/O devices 804
and display device 806.
[0071] The computer 802 interfaces to external systems through the
communications interface 810, which may include a modem or network
interface. The communications interface 810 can be considered to be
part of the computer system 800 or a part of the computer 802. The
communications interface 810 can be an analog modem, ISDN modem,
cable modem, token ring interface, satellite transmission interface
(e.g. "direct PC"), or other interfaces for coupling a computer
system to other computer systems. Although conventional computers
typically include a communications interface of some type, it is
possible to create a computer that does not include one, thereby
making the communications interface 810 optional in the strictest
sense of the word.
[0072] The processor 808 may include, by way of example but not
limitation, a conventional microprocessor such as an Intel Pentium
microprocessor or Motorola power PC microprocessor. While the
processor 808 is a critical component of all conventional
computers, any applicable known or convenient processor could be
used for the purposes of implementing the techniques described
herein. The memory 812 is coupled to the processor 808 by a bus
820. The memory 812, which may be referred to as "primary memory,"
can include Dynamic Random Access Memory (DRAM) and can also
include Static RAM (SRAM). The bus 820 couples the processor 808 to
the memory 812, and also to the non-volatile storage 816, to the
display controller 814, and to the I/O controller 818.
[0073] The I/O devices 804 can include a keyboard, disk drives,
printers, a scanner, and other input and output devices, including
a mouse or other pointing device. For illustrative purposes, at
least one of the I/O devices is assumed to be a block-based media
device, such as a DVD player. The display controller 814 may
control, in a known or convenient manner, a display on the display
device 806, which can be, for example, a cathode ray tube (CRT) or
liquid crystal display (LCD).
[0074] The display controller 814 and I/O controller 818 may
include device drivers. A device driver is a specific type of
computer software developed to allow interaction with hardware
devices. Typically this constitutes an interface for communicating
with the device, through a bus or communications subsystem that the
hardware is connected to, providing commands to and/or receiving
data from the device, and on the other end, the requisite
interfaces to the OS and software applications.
[0075] The device driver may include a hardware-dependent computer
program that is also OS-specific. The computer program enables
another program, typically an OS or applications software package
or computer program running under the OS kernel, to interact
transparently with a hardware device, and usually provides the
requisite interrupt handling necessary for any necessary
asynchronous time-dependent hardware interfacing needs.
[0076] The non-volatile storage 816, which may be referred to as
"secondary memory," is often a magnetic hard disk, an optical disk,
or another form of storage for large amounts of data. Some of this
data is often written, by a direct memory access process, into
memory 812 during execution of software in the computer 802. The
non-volatile storage 816 may include a block-based media device.
The terms "machine-readable medium" or "computer-readable medium"
include any known or convenient storage device that is accessible
by the processor 808 and also encompasses a carrier wave that
encodes a data signal.
[0077] The computer system 800 is one example of many possible
computer systems which have different architectures. For example,
personal computers based on an Intel microprocessor often have
multiple buses, one of which can be an I/O bus for the peripherals
and one that directly connects the processor 808 and the memory 812
(often referred to as a memory bus). The buses are connected
together through bridge components that perform any necessary
translation due to differing bus protocols.
[0078] Network computers are another type of computer system that
can be used in conjunction with the teachings provided herein.
Network computers do not usually include a hard disk or other mass
storage, and the executable programs are loaded from a network
connection into the memory 812 for execution by the processor 808.
A Web TV system, which is known in the art, is also considered to
be a computer system, but it may lack some of the features shown in
FIG. 8, such as certain input or output devices. A typical computer
system will usually include at least a processor, memory, and a bus
coupling the memory to the processor.
[0079] The computer system 800 may be controlled by an operating
system (OS). An OS is a software program--used on most, but not
all, computer systems--that manages the hardware and software
resources of a computer. Typically, the OS performs basic tasks
such as controlling and allocating memory, prioritizing system
requests, controlling input and output devices, facilitating
networking, and managing files. Examples of operating systems for
personal computers include Microsoft Windows.RTM., Linux, and Mac
OS.RTM.. Delineating between the OS and application software is
sometimes rather difficult. Fortunately, delineation is not
necessary to understand the techniques described herein, since any
reasonable delineation should suffice.
[0080] As used herein, algorithmic descriptions and symbolic
representations of operations on data bits within a computer memory
are believed to most effectively convey the techniques to others
skilled in the art. An algorithm is here, and generally, conceived
to be a self-consistent sequence of operations leading to a desired
result. The operations are those requiring physical manipulations
of physical quantities. Usually, though not necessarily, these
quantities take the form of electrical or magnetic signals capable
of being stored, transferred, combined, compared, and otherwise
manipulated. It has proven convenient at times, principally for
reasons of common usage, to refer to these signals as bits, values,
elements, symbols, characters, terms, numbers, or the like.
[0081] It should be borne in mind, however, that all of these and
similar terms are to be associated with the appropriate physical
quantities and are merely convenient labels applied to these
quantities. Unless specifically stated otherwise as apparent from
the following discussion, it is appreciated that throughout the
description, discussions utilizing terms such as "processing" or
"computing" or "calculating" or "determining" or "displaying" or
the like, refer to the action and processes of a computer that
manipulates and transforms data represented as physical
(electronic) quantities within the computer system's registers and
memories into other data similarly represented as physical
quantities within the computer system memories or registers or
other such information storage, transmission or display
devices.
[0082] An apparatus for performing techniques described herein may
be specially constructed for the required purposes, or it may
comprise a general purpose computer selectively activated or
reconfigured by a computer program stored in the computer. Such a
computer program may be stored in a computer readable storage
medium, such as, by way of example but not limitation, read-only
memories (ROMs), RAMs, EPROMs, EEPROMs, magnetic or optical cards,
any type of disk including floppy disks, optical disks, CD-ROMs,
DVDs, and magnetic-optical disks, or any known or convenient type
of media suitable for storing electronic instructions.
[0083] The algorithms and displays presented herein are not
inherently related to any particular computer architecture. The
techniques may be implemented using any known or convenient
programming language, whether high level (e.g., C/C++) or low level
(e.g., assembly language), and whether interpreted (e.g., Perl),
compiled (e.g., C/C++), or Just-In-Time (JIT) compiled from
bytecode (e.g., Java). Any known or convenient computer, regardless
of architecture, should be capable of executing machine code
compiled or otherwise assembled from any language into machine code
that is compatible with the computer's architecture.
[0084] As used herein, the term "embodiment" means an embodiment
that serves to illustrate by way of example but not limitation.
[0085] It will be appreciated to those skilled in the art that the
preceding examples and embodiments are exemplary and not limiting
to the scope of the present invention. It is intended that all
permutations, enhancements, equivalents, and improvements thereto
that are apparent to those skilled in the art upon a reading of the
specification and a study of the drawings are included within the
true spirit and scope of the present invention. It is therefore
intended that the following appended claims include all such
modifications, permutations and equivalents as fall within the true
spirit and scope of the present invention.
* * * * *
References