Source: http://www.freepatentsonline.com/y2007/0135099.html
Timestamp: 2020-01-21 08:07:24
Document Index: 655070396

Matched Legal Cases: ['art 400', 'art 400', 'art 400', 'art 400', 'art 400', 'art 400', 'art 500', 'art 500', 'art 500', 'art 500', 'art 500', 'art 500', 'art 500', 'art 700', 'art 700', 'art 700', 'art 700', 'art 700', 'art 700', 'art 800', 'art 800', 'art 800', 'art 800', 'art 800', 'art 800']

Message history display system and method - Taylor, Paulo
United States Patent Application 20070135099
A technique for message history display includes combining message histories for multiple different messaging services. A system constructed according to the technique may include, for example, a message history database; a history aggregation engine that aggregates message logs for storage in the message history database; and a history provisioning engine that provides an aggregated message log associated with the user from the message history database to a requesting device. A method according to the technique may include, for example, identifying a device in association with a user profile; providing an online platform that receives messages from and sends messages to the device; and creating an aggregated log from messages sent to and from the device.
Taylor, Paulo (Amsterdam, NL)
Rueb, Jan-joost (Amsterdam, NL)
Bakker, Onno (Amsterdam, NL)
11/637964
H04L12/58; H04M1/725; H04Q7/22
Download PDF 20070135099 PDF help
20070135175 Handsfree system June, 2007 Matsuda
20050221831 Routing area selection for a communication device accessing a network through a secondary communication network October, 2005 Pecen et al.
1. A system comprising: a message history database, embodied in a computer-readable medium, including a mobile device message log associated with a user; a database interface for accessing the message history database; a history aggregation engine, embodied in a computer-readable medium and coupled to the database interface, that aggregates log entries associated with messages sent to or from a mobile device associated with the user for storage in the message history database; an online history provisioning engine, embodied in a computer-readable medium and coupled to the database interface, that provides an aggregated message log associated with the user from the message history database to a requesting device.
2. The system of claim 1, wherein the mobile device is one of a plurality of mobile devices and the mobile device message log is one of a plurality of mobile device message logs, further comprising: a plurality of mobile devices associated with the user and respectively associated with a plurality of mobile device message logs; a plurality of networks coupling the plurality of devices to the history aggregation engine; wherein, in operation, the history aggregation engine receives messages from the plurality of mobile devices through the plurality of networks, and forms the mobile device message logs thereby.
3. The system of claim 1, wherein the mobile device is one of a plurality of mobile devices and the mobile device message log is one of a plurality of mobile device message logs, further comprising: a plurality of user devices associated with the user and respectively associated with a plurality of message logs; a plurality of networks coupling the plurality of devices to the history provisioning engine; wherein, in operation, the history provisioning engine receives a request from a device of the plurality of devices and provides the aggregated message log to the device in a format suitable for display on the device.
4. The system of claim 1, further comprising: a user profile database, embodied in a computer-readable medium, including a user record that sufficient data to identify a plurality of message log formats associated with a user; the message history database, including a message log associated with the user; wherein, in operation, the message log provisioning engine provides the message log in one of the plurality of message log formats.
5. The system of claim 1, wherein, in operation, the history aggregation engine compiles the aggregated message log on the fly.
6. The system of claim 1, wherein the plurality of message logs are stored in the message history database in a respective plurality of message log formats.
7. The system of claim 1, wherein, in operation, the history aggregation engine compiles at least a portion of the aggregated message log in advance of receiving a request from the requesting device.
8. The system of claim 1, wherein the plurality of message logs are stored in the message history database in an aggregated log format.
9. A method comprising: identifying a plurality of devices in association with a user profile; creating a plurality of message logs for respective ones of the plurality of devices; aggregating the plurality of message logs; receiving a request for one of the plurality of message logs from a respective one of the plurality of devices; compiling at least a portion of the aggregated message log, including a portion of at least a subplurality of the plurality of message logs, into a format suitable for display on a device associated with the requested message log; providing the at least a portion of the aggregated message log in response to the request.
10. The method of claim 9, further comprising making message log entries when a message is sent to or from one of the plurality of devices.
11. The method of claim 9, further comprising: storing one of the plurality of message logs on a respective one of the plurality of devices; uploading the one of the plurality of message logs for aggregation.
12. The method of claim 9, wherein the request is from the device associated with the requested message log.
13. The method of claim 9, further comprising compiling the aggregated message log on the fly.
14. The method of claim 9, further comprising compiling at least a portion of the aggregated message log prior to receiving the request.
15. The method of claim 9, further comprising storing the aggregated message log in a plurality of formats, wherein at least one of the plurality of formats is suitable for display on each of the plurality of devices.
16. The method of claim 9, further comprising displaying the aggregated message log on the device associated with the requested message log.
17. A method comprising: identifying a device in association with a user profile; providing an online platform that receives messages from and sends messages to the device; creating an aggregated log from messages sent to and from the device.
18. The method of claim 17, further comprising creating an aggregated log from a group chat message.
19. The method of claim 17, further comprising timestamping message entries in the aggregated log.
20. The method of claim 17, further comprising making the aggregated log available online.
This Patent Application claims priority to U.S. Provisional Patent App. No. 60/748,988, filed Dec. 9, 2005, which is incorporated herein by reference. This Patent Application is related to U.S. Patent App. Nos. (Attorney Docket No. 63017-8001.US01), (Attorney Docket No. 63017-8002.US01), (Attorney Docket No. 63017-8004.US01), (Attorney Docket No. 63017-8005.US01), to Taylor, et al., respectively entitled HIGH LEVEL NETWORK LAYER SYSTEM AND METHOD, PICTURE PROVISIONING SYSTEM AND METHOD, EVENT NOTIFICATION SYSTEM AND METHOD, and CONTACT LIST DISPLAY SYSTEM AND METHOD, filed concurrently herewith and incorporated by reference herein.
Popular instant messaging services on the public Internet include .NET Messenger Service, 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 Intemet Relay Chat (IRC).
A technique for message history display includes combining message histories for multiple different messaging services. A system constructed according to the technique may include, for example, a message history database; a history aggregation engine that aggregates the message logs for storage in the message history database; and a history provisioning engine that provides an aggregated message log associated with the user from the message history database to a requesting device.
A method according to the technique may include, for example, identifying a device in association with a user profile; providing an online platform that receives messages from and sends messages to the device; and creating an aggregated log from messages sent to and from the device.
FIG. 3 depicts an example of a system for message history aggregation and provisioning.
FIG. 4 depicts a flowchart of an example of a method for message log aggregation and provisioning.
FIG. 5 depicts a flowchart of another example of a method for message log aggregation and provisioning.
FIG. 6 depicts a computer system suitable for implementation of the techniques described with reference to FIGS. 1-5, 7-8.
FIG. 7 depicts a flowchart of an example of a method for message log aggregation and provisioning.
FIG. 8 depicts a flowchart of another example of a method for message log aggregation and provisioning.
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 two way communications. The two way communication (e.g., 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.
Message history can be stored by most IM clients on a local computer. For lternative 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
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).
The client 202 and the client 210 (and the clients 214) may or may not be associated with a single user. Advantageously, when a single user is associated with more than one client, the user can view content at any one client normally available on some other type of network. Thus, for example, a user who uses a cell phone for chat and an IM client for chat can view an aggregation of a mobile phone chat log and an IM chat history on the cell phone or on the IM client.
FIG. 3 depicts an example of a system 300 for message history aggregation and provisioning. The system 300 includes user devices 302, network 304, a server 306, a user profile database 308, and a message history database 310.
The user devices 302 may include a mobile phone 312, an IM client 322, a web browser 332, and other client 342. The networks 304 may include a cellular network 314 coupled to the mobile phone 312, an IM network 324 coupled to the IM client 322, a web network 334 coupled to the web browser 332, and other network 344 coupled to the other client 342. Each of the networks 304 is coupled to the server 306. It may be noted that the other client 342 may include another mobile phone, IM client, web browser, or some other known or convenient client. Similarly, the other network 344 may include a cellular network, IM network, web network, or some other known or convenient network.
In the example of FIG. 3, the server 306 includes a history aggregation engine 316, a user profile database interface 318, a message history database interface 320, and a history provisioning engine 326. The user profile database interface 318 and the message history database interface 320 may be incorporated into a single database interface, depending upon the implementation.
The history aggregation engine 316, which may be embodied in a computer-readable medium at the server 306, is for taking message histories from a plurality of environments associated with a single user identified in the user profile database 308 and aggregating the message histories in the message history database 310.
For example, a mobile phone chat log associated with the mobile phone 312 may be stored on the mobile phone 312, in the cellular network 314, or elsewhere. The history aggregation engine 316 can access the user profile database 308 through the user profile database interface 318 to determine where the mobile phone chat log is stored (or, for example, the mobile phone 312 could be queried). The mobile phone chat log can be stored in its current format in the message history database 310, or the mobile phone chat log could be converted to a generic format or some other format (e.g., an XML format) prior to storage in the message history database 310. Regardless of the format chosen by implementation or configuration, the history aggregation engine 316 can provide some or all of the mobile phone chat log to the message history database interface 320 for storage in the message history database 310.
As another example, an IM chat history associated with the IM client 314 may be stored on the IM client 322, in the IM network 324, or elsewhere (e.g., on a high level IM network server). As with the mobile phone chat log example, the history aggregation engine 316 can access the user profile database 308 through the user profile database interface 318 to determine where the IM chat history is stored and convert some or all of the IM chat history, if necessary, for storage in the message history database 310.
As another example, a web-based chat history associated with the web browser 332 may be stored on a computer on which the web browser 332 is embodied in a computer-readable medium, in the web network 334, or elsewhere. The history aggregation engine 316 can access the user profile database 308 through the user profile database interface 318 to determine where the web-based chat history is stored and convert some or all of the web-based chat history, if necessary, for storage in the message history database 310. In one implementation, all of the other histories are converted into a web-based format, and aggregated for a user for display on the web browser 332. Of course, in other implementations, other formats (or a generic format so that display is facilitated on any of the user's devices) can be used.
The history provisioning engine 326, which may be embodied in a computer- readable medium at the server 306, may take a request for a log from one of the user devices 302 and query the message history database interface 320 for an aggregated log stored in the message history database 310. Depending upon the implementation, the history provisioning engine 326 may receive a plurality of logs in different formats associated with each of the user devices 302 and convert the different formats into a format suitable for display on the device from which a request for a log was received; receive a plurality of logs, each of which is in a generic format, and convert the generic format into a format suitable for display on the device from which a request for a log was received; or receive a plurality of logs, each of which is in a particular format (e.g., XML) and convert the particular format into a format suitable for display on the device from which a request for a log was received, if the device is not suited to display the particular format. Alternatively, the message history database 310 could include multiple formats for the same log, and the format most suitable for provisioning to a requesting device may be provided to the history provisioning engine 326, which, in this case, would not need to reformat the log. In any case, the history provisioning engine 326 provides the aggregated log in a suitable format to a requesting device.
FIG. 4 depicts a flowchart 400 of an example of a method for message log aggregation and provisioning. This method and other methods are depicted as serially arranged modules. However, modules of the methods may be reordered, or arranged for parallel execution as appropriate. In the example of FIG. 4, the flowchart 400 begins at module 402 where a plurality of devices are identified in association with a user profile.
In the example of FIG. 4, the flowchart 400 continues to module 404 where a plurality of message logs respectively associated with the plurality of devices are stored. The message logs may or may not be stored on separate devices. For example, an IM chat history may be stored on an IM server, while a mobile phone chat log may be stored on the mobile phone.
In the example of FIG. 4, the flowchart 400 continues to module 406 where a request for a message log of the plurality of message logs is received. Such a request would typically (though not necessarily) be received from a device that uses the messaging protocol that results in the message log. In an alternative, the device may send a request explicitly for the aggregated message log. In such an alternative, a response to a request for the (unaggregated) message log may include the message log and not the aggregated message log.
In the example of FIG. 4, the flowchart 400 continues to module 408 where the plurality of message logs are compiled into an aggregated message log having a format suitable for display on a device associated with the requested message log. The aggregated message log may be compiled on the fly (e.g., when the request is received) or could be stored in advance in anticipation of the request. If stored in advance, multiple redundant aggregated message logs could be stored in different formats, each of which is suitable for display on a device associated with the user profile.
In the example of FIG. 4, the flowchart 400 continues to module 410 where the aggregated message log is provided in response to the request. The aggregated message log would typically (though not necessarily) be sent to the device that uses the messaging protocol that results in the requested message log. In a non-limiting embodiment, the device need not request the aggregated message, but receives it anyway.
In the example of FIG. 4, the various message logs are kept in their native formats. The message logs could reside in known or convenient locations associated with the various formats (e.g., a mobile phone chat log could be stored on the mobile phone). When compiling the various message logs into an aggregated message log, each of the locations may need to be checked for data. This can take some time. Also, some devices may be off (e.g., a mobile phone could be off) or off-line (e.g., an IM server that includes an IM chat log could be down for maintenance), which could result in an incomplete aggregated message log. This problem can be ameliorated by storing the aggregated message log in each possible requested format for a particular user, though this solution may result in wasting storage resources.
FIG. 5 depicts a flowchart 500 of another example of a method for message log aggregation and provisioning. In the example of FIG. 5, various message logs are stored in an aggregated log format. In the example of FIG. 5, the flowchart 500 starts at module 502 where a plurality of devices are identified in association with a user profile.
In the example of FIG. 5, the flowchart 500 continues to module 504 where a plurality of message logs respectively associated with the plurality of devices are converted into an aggregated log format. The aggregated log format may be the same format as would be suitable for display on at least one of the devices associated with a user, or the aggregated log format may be a generic format that would not be displayed on any of a user's devices without reformatting.
In the example of FIG. 5, the flowchart 500 continues to module 506 where the plurality of message logs are stored in the aggregated log format. Advantageously, the plurality of message logs can be (though are not necessarily) collected and stored on a single device or collection of devices that are relatively local with respect to one another. This may improve the speed with which the aggregated message log can be accessed.
In the example of FIG. 5, the flowchart 500 continues to module 508 where a request is received from a device of the plurality of devices for a message log of the plurality of message logs. In an alternative, the request may be explicitly for the aggregated message log. In this alternative, it may be possible to request and receive a non-aggregated message log, as well.
In the example of FIG. 5, the flowchart 500 continues to module 510 where the plurality of message logs are converted from the aggregated log format to a format associated with the requested message log. This conversion may or may not be necessary, depending upon the implementation. For example, the aggregated format may be a format that is not suitable for display without conversion on any of the devices associated with the user profile. As another example, the aggregated format may be a format that is suitable for display on one or more of the devices associated with the user profile (making conversion unnecessary for a subset of the devices), but unsuitable for display on one or more other devices associated with the user profile (making conversion necessary for a subset of the devices).
In the example of FIG. 5, the flowchart 500 continues to module 512 where the plurality of message logs are provided in the format associated with the requested message log to the requesting device. Advantageously, since the format of all of the message logs is converted (if necessary) to a format that is suitable for display on the requesting device, no matter from which device a user requests a message history, the aggregated message history can be displayed.
FIG. 6 depicts a computer system 600 suitable for implementation of the techniques described above with reference to FIGS. 1-5 (and 7-8, described later). The computer system 600 includes a computer 602, I/O devices 604, and a display device 606. The computer 602 includes a processor 608, a communications interface 610, memory 612, display controller 614, non-volatile storage 616, and I/O controller 618. The computer 602 may be coupled to or include the I/O devices 604 and display device 606.
The non-volatile storage 616, 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 612 during execution of software in the computer 602. The non-volatile storage 616 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 508 and also encompasses a carrier wave that encodes a data signal.
The computer system 600 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®, Linux, and Mac OS®. 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.
FIG. 7 depicts a flowchart 700 of an example of a method for message log aggregation and provisioning. In the example of FIG. 7, the flowchart 700 starts at module 702 where a plurality of devices are identified in association with a user profile. Thus, at least one user of a system will have a plurality (i.e., two or more) devices that are capable of generating message logs. This is not intended to mean that all users of a system must have two devices that are capable of generating message logs. Indeed, as explained later with reference to FIG. 8, it is possible to have users associated with a single device in certain embodiments and/or implementations.
In the example of FIG. 7, the flowchart 700 continues to module 704 where a plurality of message logs are created for a respective plurality of the devices and to module 706 where the plurality of message logs are aggregated. Thus, each device has an associated message log. It should be noted that, in a non-limiting embodiment, the message logs could be created simultaneously as a single log, which would have the effect of, essentially, combining modules 704 and 706.
In the example of FIG. 7, the flowchart 700 continues to module 708 where a request for one of the plurality of message logs is received from a respective one of the plurality of devices. It may be noted that the requesting device may have a NULL message log associated with it, and could still request a message log. Thus, any device associated with a user profile could request a message log. It may also be noted that a device could become identified in association with a user profile (702) after having aggregated the plurality of message logs (708), and still request a message log.
In the example of FIG. 7, the flowchart 700 continues to module 710 where at least a portion of the aggregated message log, including a portion of at least a subplurality of the plurality of message logs, is compiled into a format suitable for display on a device associated with the requested message log. Message logs can become quite long over time. While, as used herein, it is intended that, in some cases where a message log is referred to as “sent” or “provided” that only a portion of the message log may or may not be provided. In the example of FIG. 7, a portion is intended to mean the entire portion or a subportion of the aggregated message log. The message logs may be stored, as they are generated, in the aggregated message log. Indeed, the system may or may not, depending upon the implementation, even be able to distinguish between a message log generated by one device and a message generated by another device. The aggregated message log may be compiled into a format that is suitable for display on a requesting device. If the system knows the device is used in association with the user profile, the system may also have formatting preferences. In some cases, the aggregated message log may be stored in a format that does not require changing for some or all of the plurality of devices, in which case module 710 is obviated, at least to the extent compiling is called for.
In the example of FIG. 7, the flowchart 700 continues to module 712 where at least a portion of the aggregated message log is provided in response to the request.
FIG. 8 depicts a flowchart 800 of another example of a method for message log aggregation and provisioning. In the example of FIG. 8, the flowchart 800 starts at module 802 where a first device is identified in association with a user profile. The device may be any device that is capable of sending or receiving messages (typically, though not necessarily, both sending and receiving). Such a device may include, by way of example but not limitation, a browser embodied in a computer-readable medium.
In the example of FIG. 8, the flowchart 800 continues to module 804 where an online platform is provided that sends messages to and from the first device. In a non-limiting embodiment, the online platform would forward outgoing messages from the first device and forward incoming messages from a sender (not shown) to the first device. Thus, the online platform can serve as an intermediary between sender and recipient. Advantageously, the online platform can serve as intermediary for all devices associated with a user, enabling an aggregated message log to be generated from all of the user's devices with messages that pass through the online platform.
In the example of FIG. 8, the flowchart 800 continues to module 806 where an aggregated message log is created from the messages sent to and from the first device. The message log may be aggregated from entries associated with each message sent to or from the first device. Advantageously, the message log can also be aggregated from entries associated with messages sent to or from other devices associated with the user. For example, the message log could aggregate both, e.g., cell phone chat histories and, e.g., game console chat histories into the message log for a user.
In the example of FIG. 8, the flowchart 800 continues to module 808 where a second device is identified in association with the user profile. This module is optional because the user could use a single device (i.e., the first device) to send and receive messages and to receive the aggregated message log.
In the example of FIG. 8, the flowchart 800 continues to module 810 where the aggregated message log is made available from the online platform to the second device. Thus, the first device could include, e.g., a cell phone and the second device could include, e.g., a browser embodied in a computer readable medium on a laptop computer. The user would be able to access the cell phone chatlog online on the laptop computer. As was noted with reference to module 808, the first device and the second device may be the same device. That is, an IM message log associated with, e.g., a smart phone could be aggregated at the online platform, and then the same smart phone could be used to access the aggregated message log.
Previous Patent: Interactive voice browsing system for mobile devices on wireless networks
Next Patent: Method for implementing an automatic answering service of short message in mobile network