US20060031080A1 - Method and system for IMPS-based transient objects - Google Patents

Method and system for IMPS-based transient objects Download PDF

Info

Publication number
US20060031080A1
US20060031080A1 US10/911,543 US91154304A US2006031080A1 US 20060031080 A1 US20060031080 A1 US 20060031080A1 US 91154304 A US91154304 A US 91154304A US 2006031080 A1 US2006031080 A1 US 2006031080A1
Authority
US
United States
Prior art keywords
transient object
displaying
monitored
transient
specific information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
US10/911,543
Other versions
US7720719B2 (en
Inventor
Satya Mallya
Santhana Krishnasamy
Wilson Lau
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
France Telecom SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom SA filed Critical France Telecom SA
Priority to US10/911,543 priority Critical patent/US7720719B2/en
Assigned to FRANCE TELECOM reassignment FRANCE TELECOM ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: KRISHNASAMY, SANTHANA, LAU, WILSON, MALLYA, SATYA
Priority to EP05291499A priority patent/EP1624410A1/en
Publication of US20060031080A1 publication Critical patent/US20060031080A1/en
Application granted granted Critical
Publication of US7720719B2 publication Critical patent/US7720719B2/en
Active legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce
    • G06Q30/06Buying, selling or leasing transactions
    • G06Q30/08Auctions
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange

Definitions

  • the present invention relates to a method and system for registering an interest in a subject having dynamically changing characteristics and receiving updates therefor, and in one embodiment, a method and system for registering for updates to an auction item or category in which a consumer has expressed an interest.
  • Various on-line auction systems such as Wanadoo, uBid and eBayTM, support web-based auction systems that enable consumers to bid on items put-up for auction.
  • potential purchasers visit a web site and place bids on items of interest.
  • Periodically users check back to see if they are still the highest bidder, and if not, may increase their bid if they want to outbid the current highest bidder.
  • such a mechanism is cumbersome in that it is up to the user to determine when they are no longer the highest bidder.
  • IMPS Immediate Messaging and Presence Services
  • IMPP Instant Messaging and Presence Protocol
  • APEX Proposed by Wireless Village
  • PRIM Proposed by MMS
  • SIP/SIMPLE Proposed by Wireless Village
  • XMPP Presence Protocol
  • AOL IM AIM
  • Yahoo Wanadoo & MSN Messenger
  • IMPS technology has been the subject of various Internet Engineering Task Force (IETF) publications including, but not limited to: Common Presence and Instant Messaging: Message Format, Presence Information Data Format (PIDF), Address Resolution for Instant Messaging and Presence, Common Profile for Presence (CPP), Common Profile for Instant Messaging (CPIM), as well as several Requests for Comments, including: A Model for Presence and Instant Messaging (RFC 2778), Instant Messaging/Presence Protocol Requirements (RFC 2779), and Date and Time on the Internet: Timestamps (RFC 3339).
  • IETF Internet Engineering Task Force
  • IETF Internet Engineering Task Force
  • a method and system according to the present invention has been developed.
  • a method and system can notify registered participants of changes in the status of those transient objects.
  • One use of such technology is in the area of on-line auctions, but the present invention is generally directed to the area of distributed queuing for an item of interest (or a subject of interest) and dispatching to similarly interested users, through transitive presence, information concerning corresponding transactions or actions.
  • a communications system can “push” information about the changes to the registered users rather than requiring the users to periodically re-request information.
  • a service can send association control commands with a transient object that will allow a user to act on the item.
  • FIG. 1 is a schematic illustration of a computer for implementing at least a portion of the present invention
  • FIG. 2 is a schematic illustration of exemplary components providing portions of functionality according to various aspects of the present invention
  • FIG. 3A is a flowchart showing a high-level view of a process of finding auction items for sale utilizing IMPS technology utilizing the exemplary components of FIG. 2 ;
  • FIG. 3B is a flowchart showing a high-level view of a process of registering that an item is of interest utilizing IMPS technology
  • FIG. 3C is a flowchart showing a high-level view of processes for displaying changes in the state of registered items of interest utilizing IMPS technology (e.g., using presence messages);
  • FIG. 3D is a flowchart showing a high-level view of processes for changing the state of registered items of interest utilizing IMPS technology (e.g., using presence messages);
  • FIG. 4 is an exemplary user interface (including a context sensitive menu) for adding an auction item to a list of registered, transient objects of interest;
  • FIG. 5 is an exemplary filter for specifying transient objects of interest (e.g., an auction item) for which a participant would like to receive status updates;
  • transient objects of interest e.g., an auction item
  • FIG. 6 is an exemplary user interface for adding an auction item as a transient object of interest that a participant would like to receive notices about;
  • FIG. 7 is an exemplary user interface for requesting to place a bid on an auction item acting as a transient object of interest
  • FIG. 8 is an exemplary user interface for placing a bid on an auction item acting as a transient object of interest
  • FIG. 9 is an exemplary user interface for receiving bid information on an auction item acting as a transient object of interest according to a first embodiment of displaying the bid information;
  • FIG. 10 is an exemplary user interface for receiving bid information on an auction item acting as a transient object of interest according to a second embodiment of displaying the bid information;
  • FIG. 11 is a screenshot of an exemplary user interface for deleting an auction item acting as a transient object of interest from a participant's list of objects of interest.
  • FIG. 1 is a schematic illustration of a computer system for implementing, in one embodiment, a portion of the present invention.
  • a computer 100 implements the method of the present invention, wherein the computer housing 102 houses a motherboard 104 which contains a CPU 106 , memory 108 (e.g., DRAM, ROM, EPROM, EEPROM, SRAM, SDRAM, and Flash RAM), and other optional special purpose logic devices (e.g., ASICs) or configurable logic devices (e.g., GAL and reprogrammable FPGA).
  • a CPU 106 e.g., DRAM, ROM, EPROM, EEPROM, SRAM, SDRAM, and Flash RAM
  • other optional special purpose logic devices e.g., ASICs
  • configurable logic devices e.g., GAL and reprogrammable FPGA
  • the computer 100 also includes plural input devices, (e.g., a keyboard 122 and mouse 124 ), and a display card 110 for controlling monitor 120 .
  • the computer system 100 further includes a floppy disk drive 114 ; other removable media devices (e.g., compact disc 119 , tape, and removable magneto-optical media (not shown)); and a hard disk 112 , or other fixed, high density media drives, connected using an appropriate device bus (e.g., a SCSI bus, an Enhanced IDE bus, or a Ultra DMA bus).
  • the computer 100 may additionally include a compact disc reader 118 , a compact disc reader/writer unit (not shown) or a compact disc jukebox (not shown).
  • compact disc 119 is shown in a CD caddy, the compact disc 119 can be inserted directly into CD-ROM drives which do not require caddies.
  • a printer also provides printed listings of transient objects of interest.
  • the system includes at least one computer readable medium.
  • Examples of computer readable media are compact discs 119 , hard disks 112 , floppy disks, tape, magneto-optical disks, PROMs (EPROM, EEPROM, Flash EPROM), DRAM, SRAM, SDRAM, etc.
  • the present invention includes software for controlling both the hardware of the computer 100 and for enabling the computer 100 to interact with a human user.
  • Such software may include, but is not limited to, device drivers, operating systems and user applications, such as development tools.
  • the computer code devices of the present invention can be any interpreted or executable code mechanism, including but not limited to scripts, interpreters, dynamic link libraries, Java classes, and complete executable programs.
  • the computer code devices of the present invention need not be co-resident and may instead be physically separate and communicate with each other. Such communications may be via either physically linked communication (e.g., over serial or USB connections) or may be via indirect communications (e.g., using packet-based communications where addressing is used to identify the destination (and potentially source) of the communication). Examples of packet based communications include TCP/IP, UDP/IP, and Reliable Datagram Protocol (RDP).
  • Such communications may be over any communications adapter, including, but not limited to, Ethernet, Token-ring, ATM, and FDDI.
  • the present invention need not be implemented on a general purpose computer, but may instead be implemented on any hand-held or fixed (e.g., desktop) device.
  • hand-held or fixed (e.g., desktop) device examples include PDAs, mobile and/or smart phones and custom-designed IMPS devices, such as IMFree by Motorola.
  • various IMPS clients 200 communicate via any available IMPS platform 210 .
  • the IMPS platform 210 communicates with the transient object messaging and control system 220 which may interact with various back-end applications 290 which provide information on various transient objects under the control of the system 220 .
  • transient objects are defined to mean objects having short-term lives. An example of a short-tem life is the time period of an auction such that the object only exists while an item is available for bids. Similarly, in the case of an object representing an incoming call in a call center, the transient object only exists for the duration of the call.
  • transient object messaging and control system 220 information on the existence and state of transient objects is maintained to present the transient objects to participants through an IMPS interface.
  • the application 290 interacts with the proxy item manager 240 , and the proxy item manager 240 requests the buddy list manager 235 to add a transient object (representing the auction item) as a buddy to at least one user's list of buddies.
  • the proxy item manager 240 also requests that the buddy list manager 235 remove the transient object (representing the auction item) from a list of buddies when an item is no longer available (e.g., when an auction has closed).
  • the transient object only appears on the participant's list during specified activities or time periods (i.e., while the transient object is being managed by the system).
  • the system may manage groups or sets of transient objects as lists, arrays or any other data structure. Such groups or sets may be either ordered or unordered, depending on the application's requirements.
  • a buddy list manager 235 may place additional conditions on transient objects (e.g., provide rules for adding/deleting transient objects to the system).
  • the transient objects are generally distributed objects which generally appear on an IMPS client and for which distributed actors can cause status updates to been seen by other distributed actors within the system.
  • the buddy list manager 235 manages the buddy list for a user and accepts requests from the proxy item manager 240 to add or remove entries from the list of buddies. This buddy list manager 235 also checks for the policy settings of the user before adding a transient object/buddy and any user requests to remove/add a transient object/buddy.
  • a participant may become the owner of a transient object based on a series of application-specific rules (e.g., by becoming the highest bidder in an auction or by being first to answer a call in a call center). In the case of an auction, management of the ownership of the object may implemented using a “compete model” of queuing where users “compete” (by bidding) to be an owner of an object.
  • the transient object application 290 maintains a record of the items (e.g., by storing the items in a memory structure such as a queue, list or array) and relays the information about the items to the buddy list manager 235 .
  • the buddy list manager 235 adds a buddy to the user's buddy list for new objects of interest to the user items or deletes the transient buddy if the items are removed.
  • the buddy information manager 230 manages the information content associated with a transient buddy and usually describes the item added and/or removed by the requesting application 290 . This will typically include information displayed as a status of the buddy.
  • the buddy information manager also sends the control message commands to the user as the state of the item changes.
  • the response agent 260 handles any response (received via the IMPS technology) from the user. It then forwards the response to the transactional manager.
  • the transactional manager 260 maintains the transactional integrity of the item. It ensures that only one response (e.g., the first response or the response from the highest priority user) is accepted after validating the response.
  • FIGS. 3A-3D a variety of messages can be exchanged between the components of the exemplary embodiment of FIG. 2 .
  • a user that wishes to see auction items related to TV's can utilize an interaction 300 (e.g., a mouse click or text entry) to cause the user's client 200 to send a message 305 to the IMPS system 210 .
  • the IMPS system 210 then processes the message 305 and the message 310 on to the proxy item manager 240 .
  • the messages 305 and 310 need not be in the same format even though the message is “forwarded.”
  • a message recipient component that “forwards” a message may remove or add some information before passing the message on to its next intended recipient component.
  • the proxy item manager 240 may either handle the request itself (e.g., when the request is for an item already known to and managed by the proxy item manager) or it may pass the request on to the backend auction application 290 for further processing on the request (e.g., for returning a list of items or categories that correspond to a request for information).
  • the proxy item manager 240 forwards on a message 315 to the auction application 290 requesting that the user be provided with information identifying those categories that correspond to the keyword “TV.”
  • the application 290 returns a message (or messages) 320 containing the categories matching “TV” to the proxy item manager 240 .
  • the item manager 240 then forwards a message 325 to the buddy list manager 235 requesting that the buddy list manager 235 add the corresponding categories to the user's buddy list.
  • the buddy list manager 235 then sends a message 330 to the IMPS client 200 providing the categories to that can now be displayed in response to the interaction 300 .
  • the display of at least a portion of the returned information is shown as an output 335 .
  • a user may interact with that information (or other information) using an interaction 340 .
  • This may involve “drilling down” on the returned information by selecting a series of increasingly specific choices until a user has found an item (or category) of interest.
  • the user interacts ( 340 ) with the IMPS client 200 to request that “digital televisions” corresponding to the returned results of the “TV” request (of FIG. 3A ) be added as buddies (or items) in the user's buddy list.
  • the IMPS client 200 sends a message 345 to the buddy list manager 235 (implicitly by way of the IMPS system 210 ).
  • the buddy list manager 235 requests ( 350 ) from the proxy item manager 240 items corresponding to the “digital television” request. Those items may either be already managed by the proxy item manager 240 or may be obtained by communicating ( 355 / 360 ) with the auction application 290 . For items being managed by the proxy item manager 240 (including those obtained in the communication 360 ), the proxy item manager 240 requests ( 365 ) that the buddy list manager 235 add those items to the user's buddy list. The buddy list manager 235 then communicates ( 370 ) to the client 200 the new items (for display or selection 385 ).
  • the proxy item manager 240 interacts ( 375 ) with the buddy information manager 230 to generate any menu items (e.g., place bid, cancel bid or unregister for item) or state information (e.g., current bid, time until auction close) corresponding to the new items.
  • the buddy information manager 230 then communicates ( 380 ) with the client 200 the corresponding commands for the items as well as any item information as a presence message using the IMPS technology.
  • an IMPS client 200 may interact ( 400 ) with the client 200 to see menu items (e.g., by right clicking on a listed item) corresponding to actions that can be performed on the selected item. Also, a user may obtain information about an item by interaction ( 410 ) with an item, e.g., “hovering over” or “mousing over” the item with a mouse (or other input device).
  • menu items e.g., by right clicking on a listed item
  • a user may obtain information about an item by interaction ( 410 ) with an item, e.g., “hovering over” or “mousing over” the item with a mouse (or other input device).
  • the backend auction application 290 may also generate messages destined for the IMPS clients 200 autonomously. For example, in response to an auction participant interacting ( 420 ) with the backend application 290 to increase a bid (via a web interface, a telephone interface or an IMPS interface), the backend auction application 290 notifies ( 425 ) the proxy item manager 240 . This in turn causes the proxy item manager 240 to notify ( 430 ) the buddy information manager 230 of the change. This notification ( 435 ) is then propagated to the IMPS clients 200 that have the associated object listed as a buddy that the state of the associated object has changed, as shown in FIG. 3C . The user can then interact ( 440 ) with the IMPS client 200 to see that change.
  • actions may also be performed autonomously by the application 290 .
  • the application 290 may signal that an item has been bought at its “Buy now” price or the auction may have closed. In either case, the auction is marked as no longer available for bids, and the proxy item manager 240 is notified that the item should be dequeued (or otherwise removed form the list of items to be managed). Such a change in the status of the item is also communicated to the IMPS client 200 and eventually the user.
  • the response agent 260 handles any requests ( 450 ) (e.g., requests to change a bid) from the user (via the IMPS technology) that require transactional support.
  • the transactional manager 260 maintains the transactional integrity of items (e.g., it ensures that only one response (for example, the first response or the response from the highest priority user) is accepted after validating the request). Requests 450 are then forwarded on to the application 290 in charge of those requests.
  • information ( 480 ) may be sent back to the IMPS client 200 reflecting the results of the request. For example, a user may be notified that it now has the “ownership bid” representing the highest bid on the item.
  • the system may utilize any number of message formats.
  • XML-based messages are used for at least a portion of the message exchanges.
  • the system may generate an XML formatted message:
  • the system may generate an exemplary Presence XML tag in the form of:
  • an “Add Auction Item” request may generate an exemplary XML tag such as:
  • ⁇ iq>tags are generally for querying and sending the information between Servers and Clients.
  • an exemplary XML tag for a Sell Item request may be:
  • various types of objects can be treated as buddies.
  • items up for auction can be treated as buddies, but other objects such as incoming calls can also be treated as buddies.
  • various participants may be “in charge” of the object for a period of time as those participants are the current highest bidders for the corresponding period.
  • one participant may become the owner of the object (i.e., the call) for the lifetime of the object.
  • participants that are not “in charge” of an object may either have that object removed from their buddy list altogether or may simply see a reduction in the types of functions which they can perform on the corresponding object.
  • an IMPS interface may include a menu system (e.g., a context sensitive menu system) that enables a user to add not only contacts but also auction items.
  • a menu system e.g., a context sensitive menu system
  • an interface such as the one shown in FIG. 5
  • the participant specifies a filter so that items to choose from include televisions that can be delivered “Within 1 week” and that are in the price range of $1 to $1000.
  • the price and delivery time could have been left unspecified in order to obtain a list of all televisions.
  • the IMPS client 200 sends via the IMPS platform 210 a request to the buddy information manager, and the information is then sent to the proxy item manager to determine (either by consultation with the records of the proxy item manager or the information of the auction application 290 ) if there is an auction item matching the conditions (i.e., the filter) specified by the participant. If so, the information regarding the matching item is transferred back to the participant.
  • This information may be in the form of a list from which the participant may choose.
  • an interface may also be provided by which a participant may add additional information corresponding to the item found. For example, if the IMPS client selected a matching item having the transient name “phone1@a1234.com”, then the participant may add a more recognizable name to the transient name (e.g., “FT phone”) and place it in a preferred group (e.g., “Auction items”). This enables the user to more intuitively deal with the potentially numerous outstanding auction items on which he/she has bids or is interested.
  • the IMPS client 200 may allow further context sensitive information. For example, by right clicking on an item that is still part of an open auction, the participant may be given an interface such as that shown in FIG. 7 . Such an exemplary interface allows a user to (1) place a bid, (2) buy the item outright at its “sale” price, and (3) remove the item from the list of transient objects being monitored on behalf of the participant. The same interface may also allow the participant to send traditional messages or chat with other participants using IMPS messaging.
  • an interface such as the one shown in FIG. 8 may be presented to it. This enables the bid to be communicated via IMPS messaging to the auction application 290 which then communicates the change to all the registered participants for that item.
  • FIGS. 9 and 10 show that the user interface can include additional controls thereon, such as pushbuttons with either text, graphics or both thereon. Such pushbuttons may implement commonly used functions (generating a pop-up to send a message or add a new item or user) without having to utilize context sensitive menus.)
  • a participant may also select to remove an auction item from its list of transient objects being monitored.
  • the IMPS messaging system 210 informs the proxy item manager to remove the item from the participant's buddylist.
  • the system of the present invention utilizes IMPS messaging to contact all participants about a transient object (e.g., representing an auction item) when the status of the transient object changes. For example, when participant 1 is currently a highest bidder for an auction item that participants 1-3 wish to bid on (and therefore have in their buddy lists), participants may elect to place a bid on the item and become the new highest bidder. Since IMPS messaging is used, participant 1 and participant 3 are immediately notified of the change, e.g., by changing a color of the text or graphic in the buddy list that represents the corresponding item, based on information “pushed” to them (as opposed to pulling down additional data from a web-server at the request of the web client).
  • IMPS messaging is used, participant 1 and participant 3 are immediately notified of the change, e.g., by changing a color of the text or graphic in the buddy list that represents the corresponding item, based on information “pushed” to them (as opposed to pulling down additional data from a web-server at the request of the
  • Either of those users may then “mouse over” the item to determine its new status (e.g., the new highest bid and who has placed it). After successful placement of the bid the user becomes the owner for this “item” (e.g., as indicated by a change of presence indication) until he/she is out bided by others. At the same time the “item” presence status of the previous owner will change to “outbid”.
  • either of the other participants may increase their bids (e.g., by at least a fixed bid increment size) manually or they may have established an agent internal to the IMPS client (or working in conjunction with the IMPS client) that automatically increases the participants bid according to an established set of rules (e.g., up to a specified maximum).
  • This automatic bid changing can be done at either the IMPS client or at a proxy identified by the IMPS client.
  • the present invention may be utilized for technical areas other than auctions.
  • call centers that utilize problem tickets may also benefit from the present invention by treating those problem tickets as transient objects.
  • the trouble ticket is added to the buddy lists of customer service agents having the qualifications needed to address the ticket.
  • the present invention may utilize filtering when establishing the addition of buddies to a buddy list.
  • the auction application 290 would be replaced by (or supplemented by) a trouble ticket application 290 ′.
  • the trouble ticket application 290 ′ identifies the group of users who can handle the problem ticket and dispatches to the proxy item manager the problem ticket item and the corresponding list of buddies.
  • the proxy item manager manages the process of adding a transient buddy to the selected users and passing information about the problem to the buddy information manager.
  • Users A, B and C see the problem item appear as a buddy in their worklist group of buddies.
  • User A right hovers on the problem ticket buddy to see the description displayed by the buddy information manager. He then creates an IM session to get detailed description about the problem or enters a command to own the transaction.
  • the problem ticket item will be removed from the User B & User C and the User A can handle the problem through the IM client.
  • the present invention further provides a messaging protocol that provides to the IMPS client 200 information about the context-specific menu items that a user is monitoring. For example, rather than building an interface that is auction-specific, the system may send from the application to the IMPS client 200 context menus that vary depending on the type of object and/or the relationship between the object and the participant. In the context of an auction item for which a participant is already the highest bidder, the present invention may inform the IMPS client 200 that it is to remove (or show as deactivated) the “bid” or “increase bid” menu item. Similarly, if an item does not have a “sale” price that will enable it to be purchased outright at any point, then that option is not provided to the IMPS client 200 .
  • the information to be prompted for when a menu item is selected may also be specified from the application to the IMPS client 200 .
  • a form description language e.g., like that used in Web interfaces
  • the present invention can also provide dynamic list displays.
  • an IMPS client can build a navigatable list of possible matching entries. For example, by searching on “televisions”, rather than providing an unsorted list of all entries matching “televisions”, the IMPS client could be provided with lists entitled “by name”, by “type”, and “by price range”. Each of those categories would then contain main groups with sub-groups and/or items.
  • the “by name” entry may include associated therewith “Sony” and “Toshiba” as the names of manufacturers, while the “by type” may include “plasma” and “projection” as groups.
  • the “by name” and “by type” lists may include overlap since there may be plasma TVs by both Toshiba and Sony. In this way, the user can open portions of the hierarchy without having the clutter of an unsorted list. Also, the data can be grouped logically, thereby enabling the user to understand the results of the query quickly.
  • a participant may also utilize existing web interfaces to identify that it is interested in a particular transient object (e.g., auction item).
  • an auction provider may include an IMPS interface control (e.g., a push button on a Web interface showing an available auction) which, when activated, prompts the participant to enter its IMPS messaging id.
  • the auction provider may inform the auction application 290 and thereby register the participant as interested in that object.
  • the participant's IMPS messaging id may be included in the participant's information stored with the auction provider. In this way, when a participant logs onto an auction web site, its IMPS messaging id may immediately be known to the auction system. Thus, when a user activates a corresponding interface control to track an object or bid on an object, the auction provider can again notify the auction application 290 to enable the auction item to appear as a transient buddy to the participant.
  • While auctions and call centers have been described hereinabove with respect to person-to-person communication and collaboration, the present invention is similarly applicable to shopping, supply chain management, interactive gaming, field support, Sales force automation, Sales force/CRM, and fleet management, as well as other fields.
  • manufacturing parts requisitions in an inventory system could appear as a buddy in the supplier's console and a supplier can take ownership of the requisition depending on the supply chain business rules (e.g., preferred supplier, minimum bid, and supplier's reliability).
  • IMPS and distributed queueing
  • customer requests can appear as a buddy to fleet operators (simultaneously dispatched and queued as buddies) and fleet operators can hover to see location and destination information and sign up to handle the problem.
  • prospect information (or support information) from corresponding systems can appear as buddies to field sales, sales teams and support teams.
  • the system would facilitate viewing, signing up and acting on the prospects as well as viewing and acting upon support needs.
  • game artifacts such as ammunition, artillery, tank shells, and tanks could appear as buddies and traded or exchanged between team members.
  • IMPS technology As described herein, various applications of IMPS technology have been described including text messaging, auctions, shopping, etc. As would be appreciated by one of ordinary skill in the art, such applications may be implemented as separate applications, each with their own interface, or may be combined to include a single interface for all applications implemented on the same IMPS client 200 .
  • the process of combining interfaces for multiple applications may be achieved through the use of object messages received from a remote server to an IMPS client 200 .
  • Such messages may be in the form of at least one of data, menu items and downloadable code.
  • a “base” application for displaying a basic interface may be extended to include one or more mini-applications running in the context of the “base” application by dynamically linking code to or interpreting code in the “base” application.

Abstract

By utilizing IMPS technology and transient objects or object identifiers, a method and system can notify registered participants of changes in the status of those transient objects. One use of such technology is in the area of on-line auctions, but other uses include the general area of distributed queuing for an item of interest (or a subject of interest) and dispatching to similarly interested users, through transitive presence, information concerning corresponding transactions or actions.

Description

    BACKGROUND OF THE INVENTION
  • 1. Field of the Invention
  • The present invention relates to a method and system for registering an interest in a subject having dynamically changing characteristics and receiving updates therefor, and in one embodiment, a method and system for registering for updates to an auction item or category in which a consumer has expressed an interest.
  • 2. Discussion of the Background
  • Various on-line auction systems, such as Wanadoo, uBid and eBay™, support web-based auction systems that enable consumers to bid on items put-up for auction. In such systems, potential purchasers visit a web site and place bids on items of interest. Periodically users check back to see if they are still the highest bidder, and if not, may increase their bid if they want to outbid the current highest bidder. However, such a mechanism is cumbersome in that it is up to the user to determine when they are no longer the highest bidder.
  • As described in Chapter 7 of mobile messaging: technologies and services: SMS, EMS and MMS, by Le Bodic, ISBN 0-470-84876-6 (2003), incorporated herein by reference, another recently developed technology is Immediate Messaging and Presence Services (IMPS) (proposed by Wireless Village) which includes Instant Messaging and Presence Protocol (IMPP) and variants such as APEX, PRIM, SIP/SIMPLE, XMPP, AOL IM, AIM, Yahoo, Wanadoo & MSN Messenger. Using IMPS technology, people can sign up to send messages to other participants on a list of known participants (or buddies). People can be added to conversations by selecting their corresponding name(s), email address(es) or instant messaging address(es) from a list or via manually inputting the appropriate information. Such addresses are generally considered to be references to people and are thus valid for a long period of time and may be considered persistent identifiers (as opposed to transient identifiers). IMPS technology has been the subject of various Internet Engineering Task Force (IETF) publications including, but not limited to: Common Presence and Instant Messaging: Message Format, Presence Information Data Format (PIDF), Address Resolution for Instant Messaging and Presence, Common Profile for Presence (CPP), Common Profile for Instant Messaging (CPIM), as well as several Requests for Comments, including: A Model for Presence and Instant Messaging (RFC 2778), Instant Messaging/Presence Protocol Requirements (RFC 2779), and Date and Time on the Internet: Timestamps (RFC 3339). The contents of each of those IETF publications and RFCs is incorporated herein by reference. As used herein, “Immediate Messaging and Presence Services communications protocols” or “IMPS communications protocols” will be used to collectively refer to the communications protocols described above.
  • SUMMARY OF THE INVENTION
  • It is against this background that a method and system according to the present invention has been developed. By utilizing IMPS technology and transient objects or object identifiers, a method and system can notify registered participants of changes in the status of those transient objects. One use of such technology is in the area of on-line auctions, but the present invention is generally directed to the area of distributed queuing for an item of interest (or a subject of interest) and dispatching to similarly interested users, through transitive presence, information concerning corresponding transactions or actions.
  • Thus, it is an object of the present invention to provide a method and system for creating transient objects that represent items or subjects of interest whose importance is time-limited. By registering to be notified of changes in the object of interest, a communications system can “push” information about the changes to the registered users rather than requiring the users to periodically re-request information.
  • With respect to an additional feature of the invention, a service can send association control commands with a transient object that will allow a user to act on the item.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • These and other advantages of the invention will become more apparent and more readily appreciated from the following detailed description of the exemplary embodiments of the invention taken in conjunction with the accompanying drawings, where:
  • FIG. 1 is a schematic illustration of a computer for implementing at least a portion of the present invention;
  • FIG. 2 is a schematic illustration of exemplary components providing portions of functionality according to various aspects of the present invention;
  • FIG. 3A is a flowchart showing a high-level view of a process of finding auction items for sale utilizing IMPS technology utilizing the exemplary components of FIG. 2;
  • FIG. 3B is a flowchart showing a high-level view of a process of registering that an item is of interest utilizing IMPS technology;
  • FIG. 3C is a flowchart showing a high-level view of processes for displaying changes in the state of registered items of interest utilizing IMPS technology (e.g., using presence messages);
  • FIG. 3D is a flowchart showing a high-level view of processes for changing the state of registered items of interest utilizing IMPS technology (e.g., using presence messages);
  • FIG. 4 is an exemplary user interface (including a context sensitive menu) for adding an auction item to a list of registered, transient objects of interest;
  • FIG. 5 is an exemplary filter for specifying transient objects of interest (e.g., an auction item) for which a participant would like to receive status updates;
  • FIG. 6 is an exemplary user interface for adding an auction item as a transient object of interest that a participant would like to receive notices about;
  • FIG. 7 is an exemplary user interface for requesting to place a bid on an auction item acting as a transient object of interest;
  • FIG. 8 is an exemplary user interface for placing a bid on an auction item acting as a transient object of interest;
  • FIG. 9 is an exemplary user interface for receiving bid information on an auction item acting as a transient object of interest according to a first embodiment of displaying the bid information;
  • FIG. 10 is an exemplary user interface for receiving bid information on an auction item acting as a transient object of interest according to a second embodiment of displaying the bid information; and
  • FIG. 11 is a screenshot of an exemplary user interface for deleting an auction item acting as a transient object of interest from a participant's list of objects of interest.
  • DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
  • Referring now to the drawings, wherein like reference numerals designate identical or corresponding parts throughout the several views, FIG. 1 is a schematic illustration of a computer system for implementing, in one embodiment, a portion of the present invention. A computer 100 implements the method of the present invention, wherein the computer housing 102 houses a motherboard 104 which contains a CPU 106, memory 108 (e.g., DRAM, ROM, EPROM, EEPROM, SRAM, SDRAM, and Flash RAM), and other optional special purpose logic devices (e.g., ASICs) or configurable logic devices (e.g., GAL and reprogrammable FPGA). The computer 100 also includes plural input devices, (e.g., a keyboard 122 and mouse 124), and a display card 110 for controlling monitor 120. In addition, the computer system 100 further includes a floppy disk drive 114; other removable media devices (e.g., compact disc 119, tape, and removable magneto-optical media (not shown)); and a hard disk 112, or other fixed, high density media drives, connected using an appropriate device bus (e.g., a SCSI bus, an Enhanced IDE bus, or a Ultra DMA bus). Also connected to the same device bus or another device bus, the computer 100 may additionally include a compact disc reader 118, a compact disc reader/writer unit (not shown) or a compact disc jukebox (not shown). Although compact disc 119 is shown in a CD caddy, the compact disc 119 can be inserted directly into CD-ROM drives which do not require caddies. In addition, a printer (not shown) also provides printed listings of transient objects of interest.
  • As stated above, the system includes at least one computer readable medium. Examples of computer readable media are compact discs 119, hard disks 112, floppy disks, tape, magneto-optical disks, PROMs (EPROM, EEPROM, Flash EPROM), DRAM, SRAM, SDRAM, etc. Stored on any one or on a combination of computer readable media, the present invention includes software for controlling both the hardware of the computer 100 and for enabling the computer 100 to interact with a human user. Such software may include, but is not limited to, device drivers, operating systems and user applications, such as development tools. Together, the computer readable media and the software thereon form a computer program product of the present invention for notifying a plurality of recipients in parallel about changes in objects represented as buddies or participants in IMPS communications. The computer code devices of the present invention can be any interpreted or executable code mechanism, including but not limited to scripts, interpreters, dynamic link libraries, Java classes, and complete executable programs. Moreover, the computer code devices of the present invention need not be co-resident and may instead be physically separate and communicate with each other. Such communications may be via either physically linked communication (e.g., over serial or USB connections) or may be via indirect communications (e.g., using packet-based communications where addressing is used to identify the destination (and potentially source) of the communication). Examples of packet based communications include TCP/IP, UDP/IP, and Reliable Datagram Protocol (RDP). Such communications may be over any communications adapter, including, but not limited to, Ethernet, Token-ring, ATM, and FDDI.
  • As would be appreciated by one of ordinary skill in the art, the present invention need not be implemented on a general purpose computer, but may instead be implemented on any hand-held or fixed (e.g., desktop) device. Examples of such devices include PDAs, mobile and/or smart phones and custom-designed IMPS devices, such as IMFree by Motorola.
  • Turning now to FIG. 2, various components of several aspects of the present invention are illustrated. Not all of the components of FIG. 2 (or any other figure herein) need be practiced together, and various sub-systems may be separately patentable herein. In the exemplary embodiment, various IMPS clients 200 communicate via any available IMPS platform 210. The IMPS platform 210 communicates with the transient object messaging and control system 220 which may interact with various back-end applications 290 which provide information on various transient objects under the control of the system 220. As used herein, transient objects are defined to mean objects having short-term lives. An example of a short-tem life is the time period of an auction such that the object only exists while an item is available for bids. Similarly, in the case of an object representing an incoming call in a call center, the transient object only exists for the duration of the call.
  • Within the transient object messaging and control system 220, information on the existence and state of transient objects is maintained to present the transient objects to participants through an IMPS interface. When a new item is to be made available in an auction environment, the application 290 interacts with the proxy item manager 240, and the proxy item manager 240 requests the buddy list manager 235 to add a transient object (representing the auction item) as a buddy to at least one user's list of buddies. The proxy item manager 240 also requests that the buddy list manager 235 remove the transient object (representing the auction item) from a list of buddies when an item is no longer available (e.g., when an auction has closed). In this way, the transient object only appears on the participant's list during specified activities or time periods (i.e., while the transient object is being managed by the system). Internally, the system may manage groups or sets of transient objects as lists, arrays or any other data structure. Such groups or sets may be either ordered or unordered, depending on the application's requirements. Moreover, according to application specific rules, a buddy list manager 235 may place additional conditions on transient objects (e.g., provide rules for adding/deleting transient objects to the system). The transient objects are generally distributed objects which generally appear on an IMPS client and for which distributed actors can cause status updates to been seen by other distributed actors within the system.
  • The buddy list manager 235 manages the buddy list for a user and accepts requests from the proxy item manager 240 to add or remove entries from the list of buddies. This buddy list manager 235 also checks for the policy settings of the user before adding a transient object/buddy and any user requests to remove/add a transient object/buddy. A participant may become the owner of a transient object based on a series of application-specific rules (e.g., by becoming the highest bidder in an auction or by being first to answer a call in a call center). In the case of an auction, management of the ownership of the object may implemented using a “compete model” of queuing where users “compete” (by bidding) to be an owner of an object.
  • The transient object application 290 maintains a record of the items (e.g., by storing the items in a memory structure such as a queue, list or array) and relays the information about the items to the buddy list manager 235. The buddy list manager 235 adds a buddy to the user's buddy list for new objects of interest to the user items or deletes the transient buddy if the items are removed.
  • The buddy information manager 230 manages the information content associated with a transient buddy and usually describes the item added and/or removed by the requesting application 290. This will typically include information displayed as a status of the buddy. The buddy information manager also sends the control message commands to the user as the state of the item changes.
  • Generally, the response agent 260 handles any response (received via the IMPS technology) from the user. It then forwards the response to the transactional manager. The transactional manager 260 maintains the transactional integrity of the item. It ensures that only one response (e.g., the first response or the response from the highest priority user) is accepted after validating the response.
  • As shown in FIGS. 3A-3D, a variety of messages can be exchanged between the components of the exemplary embodiment of FIG. 2. As shown in FIG. 3A, a user that wishes to see auction items related to TV's can utilize an interaction 300 (e.g., a mouse click or text entry) to cause the user's client 200 to send a message 305 to the IMPS system 210. The IMPS system 210 then processes the message 305 and the message 310 on to the proxy item manager 240. As with all message forwarding described herein, the messages 305 and 310 need not be in the same format even though the message is “forwarded.” In fact, a message recipient component that “forwards” a message, as described herein, may remove or add some information before passing the message on to its next intended recipient component.
  • Depending on the type of request is received in the message 310, the proxy item manager 240 may either handle the request itself (e.g., when the request is for an item already known to and managed by the proxy item manager) or it may pass the request on to the backend auction application 290 for further processing on the request (e.g., for returning a list of items or categories that correspond to a request for information). In the illustrated message sequence of FIG. 3A, the proxy item manager 240 forwards on a message 315 to the auction application 290 requesting that the user be provided with information identifying those categories that correspond to the keyword “TV.” In response, the application 290 returns a message (or messages) 320 containing the categories matching “TV” to the proxy item manager 240. The item manager 240 then forwards a message 325 to the buddy list manager 235 requesting that the buddy list manager 235 add the corresponding categories to the user's buddy list. The buddy list manager 235 then sends a message 330 to the IMPS client 200 providing the categories to that can now be displayed in response to the interaction 300. The display of at least a portion of the returned information is shown as an output 335.
  • As shown in FIG. 3B, having displayed at least a portion of the returned information from FIG. 3A, a user may interact with that information (or other information) using an interaction 340. This may involve “drilling down” on the returned information by selecting a series of increasingly specific choices until a user has found an item (or category) of interest. For example, the user interacts (340) with the IMPS client 200 to request that “digital televisions” corresponding to the returned results of the “TV” request (of FIG. 3A) be added as buddies (or items) in the user's buddy list. To achieve this, the IMPS client 200 sends a message 345 to the buddy list manager 235 (implicitly by way of the IMPS system 210). The buddy list manager 235 requests (350) from the proxy item manager 240 items corresponding to the “digital television” request. Those items may either be already managed by the proxy item manager 240 or may be obtained by communicating (355/360) with the auction application 290. For items being managed by the proxy item manager 240 (including those obtained in the communication 360), the proxy item manager 240 requests (365) that the buddy list manager 235 add those items to the user's buddy list. The buddy list manager 235 then communicates (370) to the client 200 the new items (for display or selection 385). In addition, the proxy item manager 240 interacts (375) with the buddy information manager 230 to generate any menu items (e.g., place bid, cancel bid or unregister for item) or state information (e.g., current bid, time until auction close) corresponding to the new items. The buddy information manager 230 then communicates (380) with the client 200 the corresponding commands for the items as well as any item information as a presence message using the IMPS technology.
  • As shown in FIG. 3C, once an IMPS client 200 is monitoring at least one auction, the user may interact (400) with the client 200 to see menu items (e.g., by right clicking on a listed item) corresponding to actions that can be performed on the selected item. Also, a user may obtain information about an item by interaction (410) with an item, e.g., “hovering over” or “mousing over” the item with a mouse (or other input device).
  • The backend auction application 290 may also generate messages destined for the IMPS clients 200 autonomously. For example, in response to an auction participant interacting (420) with the backend application 290 to increase a bid (via a web interface, a telephone interface or an IMPS interface), the backend auction application 290 notifies (425) the proxy item manager 240. This in turn causes the proxy item manager 240 to notify (430) the buddy information manager 230 of the change. This notification (435) is then propagated to the IMPS clients 200 that have the associated object listed as a buddy that the state of the associated object has changed, as shown in FIG. 3C. The user can then interact (440) with the IMPS client 200 to see that change.
  • While FIG. 3C has been described above with reference to an external user performing an action (e.g., chainging a bid), actions may also be performed autonomously by the application 290. For example, the application 290 may signal that an item has been bought at its “Buy now” price or the auction may have closed. In either case, the auction is marked as no longer available for bids, and the proxy item manager 240 is notified that the item should be dequeued (or otherwise removed form the list of items to be managed). Such a change in the status of the item is also communicated to the IMPS client 200 and eventually the user.
  • As shown in FIG. 3D, the response agent 260 handles any requests (450) (e.g., requests to change a bid) from the user (via the IMPS technology) that require transactional support. The transactional manager 260 maintains the transactional integrity of items (e.g., it ensures that only one response (for example, the first response or the response from the highest priority user) is accepted after validating the request). Requests 450 are then forwarded on to the application 290 in charge of those requests.
  • Depending on the type of request, information (480) may be sent back to the IMPS client 200 reflecting the results of the request. For example, a user may be notified that it now has the “ownership bid” representing the highest bid on the item.
  • In order to facilitate the communications described above with respect to FIGS. 3A-3D, the system may utilize any number of message formats. In one exemplary (but not limiting) embodiment of the present invention, XML-based messages are used for at least a portion of the message exchanges. For example, in response to the bid placement illustrated with reference to FIG. 8, the system may generate an XML formatted message:
    • <bid to=“phone 1 @a1234.com”><amount>300.0</amount></bid>.
  • In the event of a change in the highest bidder, the system may generate an exemplary Presence XML tag in the form of:
    • <presence to=“user@localhost” from=“phone1@a1234.com”>
    • <show>outbidded</show><status>You have been outbidded</status>
    • <highestbidder>srini</highestbidder><bidamount>400.0</bidamount></presence>
  • Similar to an Add Contact function, an “Add Auction Item” request may generate an exemplary XML tag such as:
    • <presence to=“phone2@a1234.com” type=“subscribe”></presence>
    • <iq type=“set”><query xmlns=“jabber:iq:roster”><item jid=“phone2@auctionplace” name=“phone2” ask=“subscribe”><group>Auction Items</group></item></query></iq>.
  • <iq>tags are generally for querying and sending the information between Servers and Clients. Lastly, an exemplary XML tag for a Sell Item request may be:
    • <iq=“sell”><query xmlns=“jabber:iq:roster”><item jid=“phone3@a1234.com” name=“phone3” initialprice=“320.0” buynowprice=“400.0” ask=“subscribe”><group>Sell Items</group></item></query></iq>
  • Utilizing the system 220 of the present invention, various types of objects can be treated as buddies. As described above, items up for auction can be treated as buddies, but other objects such as incoming calls can also be treated as buddies. In the auction example, various participants may be “in charge” of the object for a period of time as those participants are the current highest bidders for the corresponding period. However, in the case of managing incoming calls (e.g., at a call center), one participant may become the owner of the object (i.e., the call) for the lifetime of the object. In the second case, participants that are not “in charge” of an object may either have that object removed from their buddy list altogether or may simply see a reduction in the types of functions which they can perform on the corresponding object.
  • Returning to the example of an auction, as shown in FIG. 4, an IMPS interface may include a menu system (e.g., a context sensitive menu system) that enables a user to add not only contacts but also auction items. In response to the “Add Auction item . . . ” entry (of FIG. 4) being selected, an interface, such as the one shown in FIG. 5, may be displayed to a participant in order to allow the participant to further specify what type of auction items are of interest. In the example of FIG. 5, the participant specifies a filter so that items to choose from include televisions that can be delivered “Within 1 week” and that are in the price range of $1 to $1000. Alternatively, the price and delivery time could have been left unspecified in order to obtain a list of all televisions.
  • In response to the information about the item being entered, using a series of messages, the IMPS client 200 sends via the IMPS platform 210 a request to the buddy information manager, and the information is then sent to the proxy item manager to determine (either by consultation with the records of the proxy item manager or the information of the auction application 290) if there is an auction item matching the conditions (i.e., the filter) specified by the participant. If so, the information regarding the matching item is transferred back to the participant. This information may be in the form of a list from which the participant may choose.
  • As shown in FIG. 6, an interface may also be provided by which a participant may add additional information corresponding to the item found. For example, if the IMPS client selected a matching item having the transient name “phone1@a1234.com”, then the participant may add a more recognizable name to the transient name (e.g., “FT phone”) and place it in a preferred group (e.g., “Auction items”). This enables the user to more intuitively deal with the potentially numerous outstanding auction items on which he/she has bids or is interested.
  • Once an item has been added as a transient object or buddy, the IMPS client 200 may allow further context sensitive information. For example, by right clicking on an item that is still part of an open auction, the participant may be given an interface such as that shown in FIG. 7. Such an exemplary interface allows a user to (1) place a bid, (2) buy the item outright at its “sale” price, and (3) remove the item from the list of transient objects being monitored on behalf of the participant. The same interface may also allow the participant to send traditional messages or chat with other participants using IMPS messaging.
  • If the participant was to select that it wished to place a bid, an interface such as the one shown in FIG. 8 may be presented to it. This enables the bid to be communicated via IMPS messaging to the auction application 290 which then communicates the change to all the registered participants for that item.
  • If a participant wishes to obtain information on the current state of an auction, the participant may simply “mouse over” the corresponding item in its buddy list. The information may then be shown in a pop-up, such as is shown in FIGS. 9 and 10. (It is noted that FIGS. 10 and 11 also show that the user interface can include additional controls thereon, such as pushbuttons with either text, graphics or both thereon. Such pushbuttons may implement commonly used functions (generating a pop-up to send a message or add a new item or user) without having to utilize context sensitive menus.)
  • As described above with respect to FIG. 7, using an interface such as shown in FIG. 11, a participant may also select to remove an auction item from its list of transient objects being monitored. In such a case, the IMPS messaging system 210 informs the proxy item manager to remove the item from the participant's buddylist.
  • As described above, the system of the present invention utilizes IMPS messaging to contact all participants about a transient object (e.g., representing an auction item) when the status of the transient object changes. For example, when participant1 is currently a highest bidder for an auction item that participants1-3 wish to bid on (and therefore have in their buddy lists), participants may elect to place a bid on the item and become the new highest bidder. Since IMPS messaging is used, participant1 and participant3 are immediately notified of the change, e.g., by changing a color of the text or graphic in the buddy list that represents the corresponding item, based on information “pushed” to them (as opposed to pulling down additional data from a web-server at the request of the web client). Either of those users may then “mouse over” the item to determine its new status (e.g., the new highest bid and who has placed it). After successful placement of the bid the user becomes the owner for this “item” (e.g., as indicated by a change of presence indication) until he/she is out bided by others. At the same time the “item” presence status of the previous owner will change to “outbid”.
  • In response to being outbid, either of the other participants may increase their bids (e.g., by at least a fixed bid increment size) manually or they may have established an agent internal to the IMPS client (or working in conjunction with the IMPS client) that automatically increases the participants bid according to an established set of rules (e.g., up to a specified maximum). This automatic bid changing can be done at either the IMPS client or at a proxy identified by the IMPS client.
  • As described briefly above, the present invention may be utilized for technical areas other than auctions. For example, call centers that utilize problem tickets may also benefit from the present invention by treating those problem tickets as transient objects. In such a case, the trouble ticket is added to the buddy lists of customer service agents having the qualifications needed to address the ticket. Thus, the present invention may utilize filtering when establishing the addition of buddies to a buddy list. In such a case, the auction application 290 would be replaced by (or supplemented by) a trouble ticket application 290′. In that embodiment, the trouble ticket application 290′ identifies the group of users who can handle the problem ticket and dispatches to the proxy item manager the problem ticket item and the corresponding list of buddies. The proxy item manager manages the process of adding a transient buddy to the selected users and passing information about the problem to the buddy information manager. Users A, B and C see the problem item appear as a buddy in their worklist group of buddies. User A right hovers on the problem ticket buddy to see the description displayed by the buddy information manager. He then creates an IM session to get detailed description about the problem or enters a command to own the transaction. The problem ticket item will be removed from the User B & User C and the User A can handle the problem through the IM client.
  • In order to provide a flexible, context-specific interface, the present invention further provides a messaging protocol that provides to the IMPS client 200 information about the context-specific menu items that a user is monitoring. For example, rather than building an interface that is auction-specific, the system may send from the application to the IMPS client 200 context menus that vary depending on the type of object and/or the relationship between the object and the participant. In the context of an auction item for which a participant is already the highest bidder, the present invention may inform the IMPS client 200 that it is to remove (or show as deactivated) the “bid” or “increase bid” menu item. Similarly, if an item does not have a “sale” price that will enable it to be purchased outright at any point, then that option is not provided to the IMPS client 200.
  • The information to be prompted for when a menu item is selected may also be specified from the application to the IMPS client 200. In one embodiment of this aspect of the invention, a form description language (e.g., like that used in Web interfaces) may be used to specify the fields and their corresponding labels which are shown to the participant in response to the selection of a menu item (like a response would occur to a selection of a web page).
  • Using the same dynamically generated interface, the present invention can also provide dynamic list displays. By specifying a hierarchy of information that matches a query sent to it by a IMPS client, an IMPS client can build a navigatable list of possible matching entries. For example, by searching on “televisions”, rather than providing an unsorted list of all entries matching “televisions”, the IMPS client could be provided with lists entitled “by name”, by “type”, and “by price range”. Each of those categories would then contain main groups with sub-groups and/or items. For example, the “by name” entry may include associated therewith “Sony” and “Toshiba” as the names of manufacturers, while the “by type” may include “plasma” and “projection” as groups. However, the “by name” and “by type” lists may include overlap since there may be plasma TVs by both Toshiba and Sony. In this way, the user can open portions of the hierarchy without having the clutter of an unsorted list. Also, the data can be grouped logically, thereby enabling the user to understand the results of the query quickly.
  • A participant may also utilize existing web interfaces to identify that it is interested in a particular transient object (e.g., auction item). In the case of an auction, an auction provider may include an IMPS interface control (e.g., a push button on a Web interface showing an available auction) which, when activated, prompts the participant to enter its IMPS messaging id. Using the information about the object that was associated with the interface control and the IMPS messaging id, the auction provider may inform the auction application 290 and thereby register the participant as interested in that object.
  • In yet another embodiment, the participant's IMPS messaging id may be included in the participant's information stored with the auction provider. In this way, when a participant logs onto an auction web site, its IMPS messaging id may immediately be known to the auction system. Thus, when a user activates a corresponding interface control to track an object or bid on an object, the auction provider can again notify the auction application 290 to enable the auction item to appear as a transient buddy to the participant.
  • While auctions and call centers have been described hereinabove with respect to person-to-person communication and collaboration, the present invention is similarly applicable to shopping, supply chain management, interactive gaming, field support, Sales force automation, Sales force/CRM, and fleet management, as well as other fields. For example, in a supply chain environment, manufacturing parts requisitions in an inventory system could appear as a buddy in the supplier's console and a supplier can take ownership of the requisition depending on the supply chain business rules (e.g., preferred supplier, minimum bid, and supplier's reliability). Using IMPS (and distributed queueing) enables visibility between suppliers as well as between suppliers and the company (consumer). So a wheel manufacturer might be able to sign up for a bid but might hold off shipping until he sees other critical parts have gone through the fulfillment process.
  • In a trucking, cab or other fleet management environment, customer requests can appear as a buddy to fleet operators (simultaneously dispatched and queued as buddies) and fleet operators can hover to see location and destination information and sign up to handle the problem.
  • In field sales and field support environments, prospect information (or support information) from corresponding systems can appear as buddies to field sales, sales teams and support teams. In such an embodiment, the system would facilitate viewing, signing up and acting on the prospects as well as viewing and acting upon support needs.
  • In interactive gaming (e.g., war gaming), game artifacts, such as ammunition, artillery, tank shells, and tanks could appear as buddies and traded or exchanged between team members.
  • As described herein, various applications of IMPS technology have been described including text messaging, auctions, shopping, etc. As would be appreciated by one of ordinary skill in the art, such applications may be implemented as separate applications, each with their own interface, or may be combined to include a single interface for all applications implemented on the same IMPS client 200. The process of combining interfaces for multiple applications may be achieved through the use of object messages received from a remote server to an IMPS client 200. Such messages may be in the form of at least one of data, menu items and downloadable code. Alternatively, a “base” application for displaying a basic interface may be extended to include one or more mini-applications running in the context of the “base” application by dynamically linking code to or interpreting code in the “base” application.
  • Obviously numerous modifications of the above can be made without departing from the spirit of the present invention. Thus, only the claims appended hereto define the scope of protection afforded to the inventors.

Claims (22)

1. A computer implemented method of utilizing an instant messaging protocol to monitor updated information about a transient object, the method comprising:
specifying a transient object to be monitored by a participant;
receiving updates about the transient object using presence messages of an immediate messaging and presence protocol; and
displaying the updates about the transient object using an immediate messaging and presence protocol interface.
2. The method as claimed in claim 1, wherein the transient object comprises an auction object.
3. The method as claimed in claim 1, wherein the transient object comprises a trouble ticket object.
4. The method as claimed in claim 1, wherein specifying the transient object to be monitored comprises specifying characteristics of the transient object to be monitored and receiving a list of potential matching objects.
5. The method as claimed in claim 4, wherein receiving a list of potential matching objects comprises receiving a grouped list and displaying the list sorted by groups.
6. The method as claimed in claim 1, further comprising displaying context specific information about the transient object to be monitored.
7. The method as claimed in claim 6, wherein displaying context specific information about the transient object to be monitored comprises at least one of enabling and disabling a menu item associated with the transient object to be monitored based on a change in the state of the transient object to be monitored.
8. The method as claimed in claim 6, wherein displaying context specific information about the transient object to be monitored comprises receiving the context specific information from a remote site and displaying at least one menu item including the context specific information from the remote site.
9. The method as claimed in claim 6, wherein displaying context specific information about the transient object to be monitored comprises receiving a menu from a remote site and displaying at least one menu item of the menu received from the remote site.
10. The method as claimed in claim 6, wherein displaying context specific information about the transient object to be monitored comprises displaying the context specific information about the transient object in response to a mouse over.
11. The method as claimed in claim 1, wherein the immediate messaging and presence protocol comprises a protocol compatible with a messaging protocol selected from the group consisting of IMPP, APEX, PRIM, SIP/SIMPLE, XMPP, AOL IM, AIM, and Yahoo, Wanadoo & MSN Messenger.
12. A computer program product including computer instructions embedded therein for causing, upon execution of said computer instructions, a computer processor to perform the steps of:
specifying a transient object to be monitored by a participant;
receiving updates about the transient object using presence messages of an immediate messaging and presence protocol; and
displaying the updates about the transient object using an immediate messaging and presence protocol interface.
13. The computer program product as claimed in claim 1, wherein the transient object comprises an auction object.
14. The computer program product as claimed in claim 1, wherein the transient object comprises a trouble ticket object.
15. The computer program product as claimed in claim 1, wherein specifying the transient object to be monitored comprises specifying characteristics of the transient object to be monitored and receiving a list of potential matching objects.
16. The computer program product as claimed in claim 15, wherein receiving a list of potential matching objects comprises receiving a grouped list and displaying the list sorted by groups.
17. The computer program product as claimed in claim 1, further comprising displaying context specific information about the transient object to be monitored.
18. The computer program product as claimed in claim 17, wherein displaying context specific information about the transient object to be monitored comprises at least one of enabling and disabling a menu item associated with the transient object to be monitored based on a change in the state of the transient object to be monitored.
19. The computer program product as claimed in claim 17, wherein displaying context specific information about the transient object to be monitored comprises receiving the context specific information from a remote site and displaying at least one menu item including the context specific information from the remote site.
20. The computer program product as claimed in claim 17, wherein displaying context specific information about the transient object to be monitored comprises receiving a menu from a remote site and displaying at least one menu item of the menu received from the remote site.
21. The computer program product as claimed in claim 17, wherein displaying context specific information about the transient object to be monitored comprises displaying the context specific information about the transient object in response to a mouse over.
22. The computer program product as claimed in claim 12, wherein the immediate messaging and presence protocol comprises a protocol compatible with a messaging protocol selected from the group consisting of IMPP, APEX, PRIM, SIP/SIMPLE, XMPP, AOL IM, AIM, and Yahoo, Wanadoo & MSN Messenger.
US10/911,543 2004-08-05 2004-08-05 Method and system for IMPS-based transient objects Active 2027-02-10 US7720719B2 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US10/911,543 US7720719B2 (en) 2004-08-05 2004-08-05 Method and system for IMPS-based transient objects
EP05291499A EP1624410A1 (en) 2004-08-05 2005-07-12 Method and system for IMPS-based transient objects

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US10/911,543 US7720719B2 (en) 2004-08-05 2004-08-05 Method and system for IMPS-based transient objects

Publications (2)

Publication Number Publication Date
US20060031080A1 true US20060031080A1 (en) 2006-02-09
US7720719B2 US7720719B2 (en) 2010-05-18

Family

ID=34942472

Family Applications (1)

Application Number Title Priority Date Filing Date
US10/911,543 Active 2027-02-10 US7720719B2 (en) 2004-08-05 2004-08-05 Method and system for IMPS-based transient objects

Country Status (2)

Country Link
US (1) US7720719B2 (en)
EP (1) EP1624410A1 (en)

Cited By (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040148347A1 (en) * 2002-11-18 2004-07-29 Barry Appelman Dynamic identification of other users to an online user
US20060167991A1 (en) * 2004-12-16 2006-07-27 Heikes Brian D Buddy list filtering
US20070027915A1 (en) * 2005-07-29 2007-02-01 Morris Robert P Method and system for processing a workflow using a publish-subscribe protocol
US20070043646A1 (en) * 2005-08-22 2007-02-22 Morris Robert P Methods, systems, and computer program products for conducting a business transaction using a pub/sub protocol
US20070168420A1 (en) * 2005-12-30 2007-07-19 Morris Robert P Method and apparatus for providing customized subscription data
US20080147799A1 (en) * 2006-12-13 2008-06-19 Morris Robert P Methods, Systems, And Computer Program Products For Providing Access To A Secure Service Via A Link In A Message
US20080183814A1 (en) * 2007-01-29 2008-07-31 Yahoo! Inc. Representing online presence for groups
US20080183816A1 (en) * 2007-01-31 2008-07-31 Morris Robert P Method and system for associating a tag with a status value of a principal associated with a presence client
US20080208982A1 (en) * 2007-02-28 2008-08-28 Morris Robert P Method and system for providing status information relating to a relation between a plurality of participants
US20080270546A1 (en) * 2007-04-30 2008-10-30 Morris Robert P Methods And Systems For Communicating Task Information
US20080313323A1 (en) * 2007-06-15 2008-12-18 Morris Robert P Methods, Systems, And Computer Program Products For Monitoring Transaction Status With A Presence Tuple
US20090037582A1 (en) * 2007-07-31 2009-02-05 Morris Robert P Method And System For Managing Access To A Resource Over A Network Using Status Information Of A Principal
US20090213001A1 (en) * 2002-11-18 2009-08-27 Aol Llc Dynamic Location of a Subordinate User
US20090292766A1 (en) * 2006-02-01 2009-11-26 Morris Robert P HTTP Publish/Subscribe Communication Protocol
US20100031164A1 (en) * 2008-08-01 2010-02-04 International Business Machines Corporation Method for providing a virtual world layer
US7669213B1 (en) 2004-10-28 2010-02-23 Aol Llc Dynamic identification of other viewers of a television program to an online viewer
CN101197790B (en) * 2007-12-27 2010-06-09 腾讯科技(深圳)有限公司 Method and device for acquiring latest dynamic information of users in instant communication
US8452849B2 (en) 2002-11-18 2013-05-28 Facebook, Inc. Host-based intelligent results related to a character stream
US8577972B1 (en) 2003-09-05 2013-11-05 Facebook, Inc. Methods and systems for capturing and managing instant messages
US8701014B1 (en) 2002-11-18 2014-04-15 Facebook, Inc. Account linking
US20140244473A1 (en) * 2005-11-30 2014-08-28 Genesys Telecommunications Laboratories, Inc. System and methods for matching electronic proposals to electronic requests
US8874672B2 (en) 2003-03-26 2014-10-28 Facebook, Inc. Identifying and using identities deemed to be known to a user
US8965964B1 (en) 2002-11-18 2015-02-24 Facebook, Inc. Managing forwarded electronic messages
US9203794B2 (en) 2002-11-18 2015-12-01 Facebook, Inc. Systems and methods for reconfiguring electronic messages
US9203879B2 (en) 2000-03-17 2015-12-01 Facebook, Inc. Offline alerts mechanism
US9246975B2 (en) 2000-03-17 2016-01-26 Facebook, Inc. State change alerts mechanism
US9319356B2 (en) 2002-11-18 2016-04-19 Facebook, Inc. Message delivery control settings
US9324173B2 (en) 2008-07-17 2016-04-26 International Business Machines Corporation System and method for enabling multiple-state avatars
US9667585B2 (en) 2002-11-18 2017-05-30 Facebook, Inc. Central people lists accessible by multiple applications
US10187334B2 (en) 2003-11-26 2019-01-22 Facebook, Inc. User-defined electronic message preferences
US10369473B2 (en) 2008-07-25 2019-08-06 International Business Machines Corporation Method for extending a virtual environment through registration

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8165925B2 (en) * 2008-04-03 2012-04-24 Retrevo Inc. Methods, systems, and program products for generating multidimensional comparisons

Citations (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5974398A (en) * 1997-04-11 1999-10-26 At&T Corp. Method and apparatus enabling valuation of user access of advertising carried by interactive information and entertainment services
US20020038282A1 (en) * 2000-09-27 2002-03-28 Montgomery Rob R. Buyer-side auction dynamic pricing agent, system, method and computer program product
US20020138393A1 (en) * 2001-01-22 2002-09-26 Tatge Jason G. Computerized system and method for conducting an online virtual auction
US20020165849A1 (en) * 1999-05-28 2002-11-07 Singh Narinder Pal Automatic advertiser notification for a system for providing place and price protection in a search result list generated by a computer network search engine
US20030041007A1 (en) * 2001-08-22 2003-02-27 William Grey System and method for conducting a two-sided auction
US6564261B1 (en) * 1999-05-10 2003-05-13 Telefonaktiebolaget Lm Ericsson (Publ) Distributed system to intelligently establish sessions between anonymous users over various networks
US6732364B1 (en) * 2000-07-14 2004-05-04 International Business Machines Corporation Mechanism for developing and dynamically deploying awarelets
US6763384B1 (en) * 2000-07-10 2004-07-13 International Business Machines Corporation Event-triggered notification over a network
US6859783B2 (en) * 1995-12-29 2005-02-22 Worldcom, Inc. Integrated interface for web based customer care and trouble management
US20050120306A1 (en) * 2003-12-01 2005-06-02 Research In Motion Limited Previewing a new event on a small screen device
US20050143103A1 (en) * 2003-12-31 2005-06-30 France Telecom, S.A System, method, device, and computer program product for a sender to send a personalized notification to a recipient of a communication
US20060277053A1 (en) * 2003-07-09 2006-12-07 Michael Lobb Automated communication for financial information
US7219080B1 (en) * 1999-03-31 2007-05-15 Autobytel.Com, Inc. Continuous online auction system and method
US7542920B1 (en) * 1999-07-30 2009-06-02 Catherine Lin-Hendel System for interactive computer-assisted on-line auctions

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ATE207638T1 (en) 1996-03-29 2001-11-15 Egghead Com Inc METHOD AND SYSTEM FOR PROCESSING AND TRANSMITTING ELECTRONIC AUCTION INFORMATION
KR20010069021A (en) 2000-01-11 2001-07-23 정성민 Method for providing auction information using instant messenger in internet
DE10053246A1 (en) 2000-10-26 2002-05-16 Sebworld Internationale Verwer System on the Internet for holding an auction

Patent Citations (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6859783B2 (en) * 1995-12-29 2005-02-22 Worldcom, Inc. Integrated interface for web based customer care and trouble management
US5974398A (en) * 1997-04-11 1999-10-26 At&T Corp. Method and apparatus enabling valuation of user access of advertising carried by interactive information and entertainment services
US7219080B1 (en) * 1999-03-31 2007-05-15 Autobytel.Com, Inc. Continuous online auction system and method
US6564261B1 (en) * 1999-05-10 2003-05-13 Telefonaktiebolaget Lm Ericsson (Publ) Distributed system to intelligently establish sessions between anonymous users over various networks
US20020165849A1 (en) * 1999-05-28 2002-11-07 Singh Narinder Pal Automatic advertiser notification for a system for providing place and price protection in a search result list generated by a computer network search engine
US7542920B1 (en) * 1999-07-30 2009-06-02 Catherine Lin-Hendel System for interactive computer-assisted on-line auctions
US6763384B1 (en) * 2000-07-10 2004-07-13 International Business Machines Corporation Event-triggered notification over a network
US6732364B1 (en) * 2000-07-14 2004-05-04 International Business Machines Corporation Mechanism for developing and dynamically deploying awarelets
US20020038282A1 (en) * 2000-09-27 2002-03-28 Montgomery Rob R. Buyer-side auction dynamic pricing agent, system, method and computer program product
US20020138393A1 (en) * 2001-01-22 2002-09-26 Tatge Jason G. Computerized system and method for conducting an online virtual auction
US20030041007A1 (en) * 2001-08-22 2003-02-27 William Grey System and method for conducting a two-sided auction
US20060277053A1 (en) * 2003-07-09 2006-12-07 Michael Lobb Automated communication for financial information
US20050120306A1 (en) * 2003-12-01 2005-06-02 Research In Motion Limited Previewing a new event on a small screen device
US20050143103A1 (en) * 2003-12-31 2005-06-30 France Telecom, S.A System, method, device, and computer program product for a sender to send a personalized notification to a recipient of a communication

Cited By (72)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9203879B2 (en) 2000-03-17 2015-12-01 Facebook, Inc. Offline alerts mechanism
US9736209B2 (en) 2000-03-17 2017-08-15 Facebook, Inc. State change alerts mechanism
US9246975B2 (en) 2000-03-17 2016-01-26 Facebook, Inc. State change alerts mechanism
US9075868B2 (en) 2002-11-18 2015-07-07 Facebook, Inc. Intelligent results based on database queries
US9647872B2 (en) 2002-11-18 2017-05-09 Facebook, Inc. Dynamic identification of other users to an online user
US10778635B2 (en) 2002-11-18 2020-09-15 Facebook, Inc. People lists
US10389661B2 (en) 2002-11-18 2019-08-20 Facebook, Inc. Managing electronic messages sent to mobile devices associated with electronic messaging accounts
US20040148347A1 (en) * 2002-11-18 2004-07-29 Barry Appelman Dynamic identification of other users to an online user
US9171064B2 (en) 2002-11-18 2015-10-27 Facebook, Inc. Intelligent community based results related to a character stream
US10033669B2 (en) 2002-11-18 2018-07-24 Facebook, Inc. Managing electronic messages sent to reply telephone numbers
US9894018B2 (en) 2002-11-18 2018-02-13 Facebook, Inc. Electronic messaging using reply telephone numbers
US9852126B2 (en) 2002-11-18 2017-12-26 Facebook, Inc. Host-based intelligent results related to a character stream
US9203794B2 (en) 2002-11-18 2015-12-01 Facebook, Inc. Systems and methods for reconfiguring electronic messages
US9774560B2 (en) 2002-11-18 2017-09-26 Facebook, Inc. People lists
US9769104B2 (en) 2002-11-18 2017-09-19 Facebook, Inc. Methods and system for delivering multiple notifications
US9729489B2 (en) 2002-11-18 2017-08-08 Facebook, Inc. Systems and methods for notification management and delivery
US9667585B2 (en) 2002-11-18 2017-05-30 Facebook, Inc. Central people lists accessible by multiple applications
US7899862B2 (en) 2002-11-18 2011-03-01 Aol Inc. Dynamic identification of other users to an online user
US8122137B2 (en) 2002-11-18 2012-02-21 Aol Inc. Dynamic location of a subordinate user
US9621376B2 (en) 2002-11-18 2017-04-11 Facebook, Inc. Dynamic location of a subordinate user
US8452849B2 (en) 2002-11-18 2013-05-28 Facebook, Inc. Host-based intelligent results related to a character stream
US9571439B2 (en) 2002-11-18 2017-02-14 Facebook, Inc. Systems and methods for notification delivery
US8701014B1 (en) 2002-11-18 2014-04-15 Facebook, Inc. Account linking
US8775560B2 (en) 2002-11-18 2014-07-08 Facebook, Inc. Host-based intelligent results related to a character stream
US8819176B2 (en) 2002-11-18 2014-08-26 Facebook, Inc. Intelligent map results related to a character stream
US9571440B2 (en) 2002-11-18 2017-02-14 Facebook, Inc. Notification archive
US9560000B2 (en) 2002-11-18 2017-01-31 Facebook, Inc. Reconfiguring an electronic message to effect an enhanced notification
US8954534B2 (en) 2002-11-18 2015-02-10 Facebook, Inc. Host-based intelligent results related to a character stream
US8954530B2 (en) 2002-11-18 2015-02-10 Facebook, Inc. Intelligent results related to a character stream
US8954531B2 (en) 2002-11-18 2015-02-10 Facebook, Inc. Intelligent messaging label results related to a character stream
US8965964B1 (en) 2002-11-18 2015-02-24 Facebook, Inc. Managing forwarded electronic messages
US9047364B2 (en) 2002-11-18 2015-06-02 Facebook, Inc. Intelligent client capability-based results related to a character stream
US9053175B2 (en) 2002-11-18 2015-06-09 Facebook, Inc. Intelligent results using a spelling correction agent
US9053174B2 (en) 2002-11-18 2015-06-09 Facebook, Inc. Intelligent vendor results related to a character stream
US9053173B2 (en) 2002-11-18 2015-06-09 Facebook, Inc. Intelligent results related to a portion of a search query
US9515977B2 (en) 2002-11-18 2016-12-06 Facebook, Inc. Time based electronic message delivery
US9075867B2 (en) 2002-11-18 2015-07-07 Facebook, Inc. Intelligent results using an assistant
US9356890B2 (en) 2002-11-18 2016-05-31 Facebook, Inc. Enhanced buddy list using mobile device identifiers
US9319356B2 (en) 2002-11-18 2016-04-19 Facebook, Inc. Message delivery control settings
US20090213001A1 (en) * 2002-11-18 2009-08-27 Aol Llc Dynamic Location of a Subordinate User
US9313046B2 (en) 2002-11-18 2016-04-12 Facebook, Inc. Presenting dynamic location of a user
US9203647B2 (en) 2002-11-18 2015-12-01 Facebook, Inc. Dynamic online and geographic location of a user
US9253136B2 (en) 2002-11-18 2016-02-02 Facebook, Inc. Electronic message delivery based on presence information
US9736255B2 (en) 2003-03-26 2017-08-15 Facebook, Inc. Methods of providing access to messages based on degrees of separation
US9516125B2 (en) 2003-03-26 2016-12-06 Facebook, Inc. Identifying and using identities deemed to be known to a user
US9531826B2 (en) 2003-03-26 2016-12-27 Facebook, Inc. Managing electronic messages based on inference scores
US8874672B2 (en) 2003-03-26 2014-10-28 Facebook, Inc. Identifying and using identities deemed to be known to a user
US10102504B2 (en) 2003-09-05 2018-10-16 Facebook, Inc. Methods for controlling display of electronic messages captured based on community rankings
US9070118B2 (en) 2003-09-05 2015-06-30 Facebook, Inc. Methods for capturing electronic messages based on capture rules relating to user actions regarding received electronic messages
US8577972B1 (en) 2003-09-05 2013-11-05 Facebook, Inc. Methods and systems for capturing and managing instant messages
US10187334B2 (en) 2003-11-26 2019-01-22 Facebook, Inc. User-defined electronic message preferences
US7669213B1 (en) 2004-10-28 2010-02-23 Aol Llc Dynamic identification of other viewers of a television program to an online viewer
US8255950B1 (en) 2004-10-28 2012-08-28 Aol Inc. Dynamic identification of other viewers of a television program to an online viewer
US20060167991A1 (en) * 2004-12-16 2006-07-27 Heikes Brian D Buddy list filtering
US20070027915A1 (en) * 2005-07-29 2007-02-01 Morris Robert P Method and system for processing a workflow using a publish-subscribe protocol
US20070043646A1 (en) * 2005-08-22 2007-02-22 Morris Robert P Methods, systems, and computer program products for conducting a business transaction using a pub/sub protocol
US20140244473A1 (en) * 2005-11-30 2014-08-28 Genesys Telecommunications Laboratories, Inc. System and methods for matching electronic proposals to electronic requests
US20070168420A1 (en) * 2005-12-30 2007-07-19 Morris Robert P Method and apparatus for providing customized subscription data
US20090292766A1 (en) * 2006-02-01 2009-11-26 Morris Robert P HTTP Publish/Subscribe Communication Protocol
US20080147799A1 (en) * 2006-12-13 2008-06-19 Morris Robert P Methods, Systems, And Computer Program Products For Providing Access To A Secure Service Via A Link In A Message
US20080183814A1 (en) * 2007-01-29 2008-07-31 Yahoo! Inc. Representing online presence for groups
US20080183816A1 (en) * 2007-01-31 2008-07-31 Morris Robert P Method and system for associating a tag with a status value of a principal associated with a presence client
US20080208982A1 (en) * 2007-02-28 2008-08-28 Morris Robert P Method and system for providing status information relating to a relation between a plurality of participants
US20080270546A1 (en) * 2007-04-30 2008-10-30 Morris Robert P Methods And Systems For Communicating Task Information
US20080313323A1 (en) * 2007-06-15 2008-12-18 Morris Robert P Methods, Systems, And Computer Program Products For Monitoring Transaction Status With A Presence Tuple
US20090037582A1 (en) * 2007-07-31 2009-02-05 Morris Robert P Method And System For Managing Access To A Resource Over A Network Using Status Information Of A Principal
CN101197790B (en) * 2007-12-27 2010-06-09 腾讯科技(深圳)有限公司 Method and device for acquiring latest dynamic information of users in instant communication
US9324173B2 (en) 2008-07-17 2016-04-26 International Business Machines Corporation System and method for enabling multiple-state avatars
US10424101B2 (en) 2008-07-17 2019-09-24 International Business Machines Corporation System and method for enabling multiple-state avatars
US10369473B2 (en) 2008-07-25 2019-08-06 International Business Machines Corporation Method for extending a virtual environment through registration
US10166470B2 (en) * 2008-08-01 2019-01-01 International Business Machines Corporation Method for providing a virtual world layer
US20100031164A1 (en) * 2008-08-01 2010-02-04 International Business Machines Corporation Method for providing a virtual world layer

Also Published As

Publication number Publication date
US7720719B2 (en) 2010-05-18
EP1624410A1 (en) 2006-02-08

Similar Documents

Publication Publication Date Title
US7720719B2 (en) Method and system for IMPS-based transient objects
US8694895B2 (en) Human interaction with application from email client
US9294512B2 (en) System and method for handling complaints about unsolicited communications
US7752335B2 (en) Networked computing using objects
US7321928B2 (en) Super peering architecture
US9224109B2 (en) Filtered peer-to-peer business communication in a distributed computer environment
US20080300962A1 (en) Lead distribution and tracking with integrated corporate data usage and reporting capabilities
US20080091782A1 (en) Method and system for delegating and managing tasks over instant messenger
US20090037306A1 (en) System and Method for Managing Customer Interactions
US6578013B1 (en) Method and system for communicating between supplier and customer devices
WO2001017172A1 (en) Method and system for process interaction among a group
CN103020813A (en) Technology of managing remote events
US20190073213A1 (en) Sending updates associated with a transaction platform to a distribution group of users associated with a messaging service
US20080300961A1 (en) Lead distribution and tracking with integrated corporate data usage and reporting capabilities with message templating
CN101523867A (en) Mobile monetization
CN112150256A (en) Data processing method, device, equipment and storage medium
US10798038B2 (en) Communication control method and information processing apparatus
US20160232482A1 (en) Method and system for enterprise marketplace including notification services
US20100064011A1 (en) Automatic Non-Junk Message List Inclusion
KR100532560B1 (en) A multiple avatar management system and method for instant messenger and web service
US20060026178A1 (en) Method and apparatus for adapting an email application program user interface to interface with a business management system
US20080010334A1 (en) Method, system, and program product for providing automatic group subscriptions
US20110213841A1 (en) System and method for generating an electronic communication
CA2590777A1 (en) Lead distribution and tracking with integrated corporate data usage and reporting capabilities
CA2590581A1 (en) Lead distribution and tracking with integrated corporate data usage and reporting capabilities with message templating

Legal Events

Date Code Title Description
AS Assignment

Owner name: FRANCE TELECOM, FRANCE

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:MALLYA, SATYA;KRISHNASAMY, SANTHANA;LAU, WILSON;REEL/FRAME:016078/0702

Effective date: 20040908

Owner name: FRANCE TELECOM,FRANCE

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:MALLYA, SATYA;KRISHNASAMY, SANTHANA;LAU, WILSON;REEL/FRAME:016078/0702

Effective date: 20040908

STCF Information on status: patent grant

Free format text: PATENTED CASE

FPAY Fee payment

Year of fee payment: 4

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552)

Year of fee payment: 8

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 12TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1553); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 12