US20010016875A1 - Reducing perceived latency in servicing user requests on low-bandwidth communication channels - Google Patents

Reducing perceived latency in servicing user requests on low-bandwidth communication channels Download PDF

Info

Publication number
US20010016875A1
US20010016875A1 US09/839,858 US83985801A US2001016875A1 US 20010016875 A1 US20010016875 A1 US 20010016875A1 US 83985801 A US83985801 A US 83985801A US 2001016875 A1 US2001016875 A1 US 2001016875A1
Authority
US
United States
Prior art keywords
computer
remote device
information
request
notification
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.)
Abandoned
Application number
US09/839,858
Inventor
Bruce Schwartz
Stephen Boyle
Peter King
Bruce Martin
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.)
Great Elm Group Inc
Original Assignee
Openwave Systems Inc
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 Openwave Systems Inc filed Critical Openwave Systems Inc
Priority to US09/839,858 priority Critical patent/US20010016875A1/en
Publication of US20010016875A1 publication Critical patent/US20010016875A1/en
Assigned to UNWIRED PLANET, INC. reassignment UNWIRED PLANET, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: BOYLE, STEPHEN S., KING, PETER F., MARTIN, JR, BRUCE K., SCHWARTZ, BRUCE V.
Assigned to OPENWAVE SYSTEMS, INC. reassignment OPENWAVE SYSTEMS, INC. MERGER/CHANGE OF NAME Assignors: PHONE.COM, INC.
Assigned to PHONE.COM, INC. reassignment PHONE.COM, INC. CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: UNWIRED PLANET, INC.
Abandoned legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/04Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90Details of database functions independent of the retrieved data types
    • G06F16/95Retrieval from the web
    • G06F16/955Retrieval from the web using information identifiers, e.g. uniform resource locators [URL]
    • G06F16/9562Bookmark management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/06Message adaptation to terminal or network requirements
    • H04L51/066Format adaptation, e.g. format conversion or compression
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/30Managing network names, e.g. use of aliases or nicknames
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/30Managing network names, e.g. use of aliases or nicknames
    • H04L61/301Name conversion
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/45Network directories; Name-to-address mapping
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/14Session management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40Network security protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M1/00Substation equipment, e.g. for use by subscribers
    • H04M1/26Devices for calling a subscriber
    • H04M1/27Devices whereby a plurality of signals may be stored simultaneously
    • H04M1/274Devices whereby a plurality of signals may be stored simultaneously with provision for storing more than one subscriber number at a time, e.g. using toothed disc
    • H04M1/2745Devices whereby a plurality of signals may be stored simultaneously with provision for storing more than one subscriber number at a time, e.g. using toothed disc using static electronic memories, e.g. chips
    • H04M1/2753Devices whereby a plurality of signals may be stored simultaneously with provision for storing more than one subscriber number at a time, e.g. using toothed disc using static electronic memories, e.g. chips providing data content
    • H04M1/2757Devices whereby a plurality of signals may be stored simultaneously with provision for storing more than one subscriber number at a time, e.g. using toothed disc using static electronic memories, e.g. chips providing data content by data transmission, e.g. downloading
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/21Monitoring or handling of messages
    • H04L51/224Monitoring or handling of messages providing notification on incoming messages, e.g. pushed notifications of received messages
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/58Message adaptation for wireless communication
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/02Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]

Definitions

  • the present invention relates generally to devices and methods for interacting with hypermedia servers connected to networks. More particularly, the present invention pertains to structures and methods of system interactions arranged such that practical access to hypermedia servers is available to a wider range of devices such as wireless telephones.
  • HTTP Hypertext Transfer Protocol
  • a unique identifier known as a Uniform Resource Locator (URL) specifies the location of a resource that can be accessed from the network.
  • URL Uniform Resource Locator
  • HTTP clients and HTTP servers typically communicate with one another using any one of a family of communication protocols known collectively as Transmission Control Protocol/Internet Protocol (TCP/IP).
  • TCP Transmission Control Protocol
  • a sender establishes a “connection” with a receiver, transmits an information stream in basic units known as packets, and retransmits any packets that are either lost or corrupted during transmission.
  • One advantage of the TCP is that it guarantees the receiver will receive the bits and bytes in the information stream in the correct order.
  • the TCP requires considerable computing and network bandwidth resources.
  • the establishment of a connection for example, may require an exchange of more than ten packets between sender and receiver.
  • the HTTP In addition to the resources required to implement the TCP, the HTTP itself also requires considerable resources to format, process and display information. This is not a significant disadvantage in many situations because personal computers and other workstations with sufficient computing power, memory and display capabilities are readily available to implement the HTTP client function.
  • a wireless telephone has only a small fraction of the resources provided by a typical desktop or portable computer.
  • the processing power is less than one percent of the processing power in many computers, the memory space is generally much less than 150 kilobytes (kB), and the display is perhaps four lines high and twelve or twenty characters wide. Graphics capabilities are very limited or nonexistent.
  • the communication path is often in the range of 400 to 19,200 bits per sec. and the cost using that communication path is measured in terms of United States dollars per 100 kB or more.
  • the system comprises a computer that is coupled to a transmitter and to a hypermedia server, comprises first storage, the computer executes a first program that causes the computer to receive unsolicited information from the hypermedia server and an identification of an intended recipient of the unsolicited information and, in response thereto, to store in the first storage one or more first records representing contents of the unsolicited information, to generate a plurality of messages in response to the first records, to send the messages via the transmitter so as to be received by a respective remote device associated with the intended recipient, and to send a notification via the transmitter so as to be received by the respective remote device, where the notification indicates the plurality of messages have been sent to the respective remote device.
  • FIGURE illustrates in schematic form the major components of a system in which a device such as a wireless telephone can access the resources provided by a hypermedia server connected to a network.
  • FIGURE illustrates a system in which various aspects of the present invention may be practiced. As will be explained below, some of the components illustrated in the FIGURE may be omitted in various embodiments.
  • client 1 uses network 40 to access resources provided by server 51 and server 52 .
  • server 51 and server 52 are hypermedia servers, perhaps operating in conformity with the Hypertext Transfer Protocol (HTTP), this is not necessary to practice the present invention.
  • HTTP Hypertext Transfer Protocol
  • Client 1 comprises computer 31 and device 11 , which is remotely located with respect to computer 31 .
  • Remote device 11 and computer 31 perform functions that implement client 1 .
  • Remote device 11 provides a user interface through which information can be presented to a user and input can be received from a user.
  • Computer 31 exchanges information with network 40 in a manner that is consistent with a conventional network client.
  • Computer 31 stores parameters and information in storage 32 that typically is a combination of random access memory (RAM), read-only memory (ROM) and long-term storage devices such as magnetic and optical disk drives.
  • Computer 31 communicates with remote device 11 through receiver 21 and transmitter 22 .
  • Information that is sent by computer 31 through transmitter 22 is received by remote device 11 through receiver 16 .
  • Information that is sent by remote device 11 through transmitter 15 is received by computer 31 through receiver 21 .
  • remote device 11 comprises display 12 , one or more buttons 13 , storage 14 , transmitter 15 and receiver 16 .
  • device 11 may be a wireless telephone such as a MobileAccessTM telephone by Mitsubishi Wireless Communications, Inc., or a Duette telephone by Samsung Electronics Corporation.
  • the display 12 is a liquid crystal display (LCD) panel.
  • Buttons 13 represent one or more data entry devices such as switches, keys or buttons.
  • Storage 14 represents memory circuits or other devices that are capable of storing digital information.
  • at least part of storage 14 is persistent storage, meaning that information is retained when device 11 is turned off.
  • a portion of storage 14 is organized into a unified push/pull cache. It is also contemplated that a portion of storage 14 will store program instructions, either in persistent memory or in ROM, and that device 11 will comprise a microprocessor or other type of processing circuitry capable of executing the program instructions.
  • device 11 is a wireless device that uses a communication technology such as electromagnetic transmission in the radio-frequency to infrared portions of the spectrum.
  • a wireless telephone for example, transmitter 15 , receiver 16 , receiver 21 and transmitter 22 represent communication facilities used for normal telephone calls.
  • client 1 In applications where client 1 is implemented as a HTTP client, device 11 provides at least three basic functions.
  • a navigation function allows a user to navigate or traverse HTTP Uniform Resource Locator (URL) hyperlinks.
  • a communication function exchanges information with computer 31 .
  • An interface function provides a user interface through which information may be presented to the user and through which input may be received from the user.
  • these functions are implemented by a software-controlled process using an event-driven architecture.
  • Events may be initiated by a user through buttons 13 , for example, or may be initiated by signals received through receiver 16 .
  • the navigation function operates in either of two states. In the “ready” state the device awaits user input specifying a hyperlink to traverse. In the “pending” state the communication function has submitted a request to computer 31 and the device is waiting for a reply from computer 31 . In terms of the HTTP, the ready state waits for user input specifying the URL of a hypermedia entity to display or process and the pending state waits for computer 31 to provide a requested hypermedia entity.
  • hypermedia information is exchanged with computer 31 according to the Handheld Device Transfer Protocol (HDTP).
  • HDTP Handheld Device Transfer Protocol
  • a specification for a version of this protocol, sometimes referred to as Secure UPLink Gateway Protocol (SUGP) is provided in an Annex.
  • the HDTP resembles the HTTP but is optimized for use with remote devices like wireless telephones and preferably is conveyed using the User Datagram Protocol/IP (UDP/IP).
  • UDP/IP User Datagram Protocol/IP
  • the UDP/IP is generally regarded as being less reliable than TCP/IP, for example, because it does not guarantee that packets will be received, nor does it guarantee that packets will be received in the same order that they are sent.
  • Datagram protocols like the UDP/IP are attractive in practicing the present invention, however, because it does not require a “connection” to be established between a sender and a receiver before information can be exchanged. This eliminates the need to exchange a large number of packets during session creation.
  • hypermedia information is organized according to a Handheld Device Markup Language (HDML) into cards and decks. Multiple decks and other types of message entities can be organized into information structures called digests.
  • HDML Handheld Device Markup Language
  • digests A specification for a version of HDML is provided in the Annex.
  • a “deck” is the smallest unit of HDML information that can be exchanged with computer 31 .
  • Each deck has a unique identifier or URL.
  • a user may navigate from one deck to another by traversing hyperlinks that reference the desired deck.
  • the device If remote device 11 has a cache for received decks, the device first consults the cache to determine if the requested deck is available.
  • Remote device 11 may also be implemented to determine if a desired deck found in cache is also current, that is, not out of date. If so, that deck is accessed without requiring any communication with computer 31 . If the requested deck is not in the cache or is out of date, however, a request for that deck is sent to computer 31 . This is discussed in more detail below.
  • each deck may be organized into one or more cards.
  • a “card” is a unit of information that can be displayed and/or can define how a user may interact with the device.
  • a “display” card conveys information that is to be displayed.
  • An “entry” card conveys a method that permits a user to enter information and typically also conveys information to display.
  • a “choice” card presents alternatives for selection by a user. Entry and choice cards also convey methods to be performed by device 11 that carry out functions necessary to receive input or recognize the chosen alternative.
  • Entry and choice cards cause one or more state variables to be set according to the information that is entered or the alternative that is chosen.
  • a display card can also set one or more variables.
  • a special form of the display card does not cause any visible display but can be used to set one or more variables.
  • a “digest” is an optional information structure that may be used to facilitate the transmission and processing of multiple message entities including HDML decks.
  • each message entity in a digest is processed in sequence according to entity type.
  • message entity types include HDML decks, images and alerts. One important use of the digest and the alert entity is discussed below.
  • the current state of the three basic functions, navigation, communication and interface can be expressed in terms of the deck and card in that deck that is currently displayed and one or more variables needed to process the card.
  • remote device 11 can restore the current state at a future time.
  • a cache of decks, a navigation history of hyperlink traversals and a history of user activity can also be used to improve performance, provide additional functions to the user, and provide additional facilities for use by system developers.
  • Handheld devices like telephones have severely limited facilities for entering information.
  • the input facilities of these devices are often limited to the familiar twelve keys of a pushbutton telephone.
  • One common method for entering text is to assign letters to various numeric keys according to normal telephone conventions. For example, the letters ABC are assigned to the “2” key and the letters DEF are assigned to the “3” key.
  • the letters Q and Z could be assigned to the “0” key, for example.
  • the letter A is entered by pressing the “2” key once and the letter B is entered by pressing the key twice.
  • a form of letter prediction is used to make text entry more efficient.
  • This prediction can be based on the statistics of letter combinations. For example, after entering the letters T and H, it is much more likely that a user will enter the letter E than the letters D or F. Accordingly, after entering T and H, in response to a user pressing the “3” key, remote device 11 will present the letter E first rather than the letter D.
  • the prediction can be based on a table of probabilities for various three-letter combinations stored in storage 14 .
  • Computer 31 together with remote device 11 , provides the functions of a conventional hypermedia client.
  • computer 31 receives information from remote device 11 according to the HDTP, translates the HDTP information into corresponding HTTP information as necessary, and sends the result to server 51 .
  • computer 31 receives information from server 51 according to the HTTP, translates the HTTP information into corresponding HDTP information as necessary, and sends the result to remote device 11 .
  • HDTP information exchanged with remote device 11 is compiled from a textual form into a binary form that reduces the bandwidth requirements of the communication channel and reduces the processing required by remote device 11 to parse and interpret the information.
  • the information may be subjected to other types of data compression to reduce bandwidth requirements.
  • a session can be created more efficiently than is possible using the more common TCP/IP.
  • the exchange of information needed to create a session is similar to the exchange carried out for other types of requests.
  • An exchange can be initiated by remote device 11 sending a request to computer 31 . Subsequently, computer 31 returns a reply to the request and remote device 11 acknowledges receipt of the reply.
  • the reply may either be expected results of the request or it may be an indication of some error encountered while attempting to service the request. If remote device 11 does not receive a reply within some timeout interval, it will send the request to computer 31 again.
  • Remote device 11 will send the request repeatedly until either it receives a reply message, or a standby or “HoldOn” message from computer 31 .
  • the length of the timeout interval can be user configurable or it can be established by information previously received from computer 31 .
  • computer 31 will send the reply repeatedly until it receives the acknowledgement from remote device 11 .
  • remote device 11 may initiate the creation of a session by sending a session-creation request to computer 31 .
  • the request includes any necessary authentication information, one or more session parameters, and information describing the device and version of software in use.
  • Computer 31 receives the request, validates the authentication information, checks that the user is entitled to initiate a session, assigns an identifier to the new session, builds a message containing the session identifier and any information that computer 31 wishes to pass to remote device 11 , and sends the message to remote device 11 .
  • this message also includes the URL of a “home page” associated with the device.
  • Remote device 11 acknowledges receipt of the message and the session is established.
  • remote device 11 when a user traverses a hyperlink, remote device 11 consults its cache, if any, and determines if the cache already has the requested hypermedia entity (HDTP deck). If it does and the deck in the cache is not out of date, remote device 11 can process the requested deck and no further action is required. If the requested deck is not available or is out of date, however, remote device 11 builds a message including a HDTP “Service Request” and the URL of the requested deck and sends the message to computer 31 . According to the HDTP, the message also includes a header with information that is unique to the request. Remote device 11 then waits for a reply from computer 31 . The reply may be the requested deck or it may be an indication that an error occurred while attempting to service the request.
  • HDTP deck hypermedia entity
  • Computer 31 receives the request, checks its validity and attempts to establish a connection with the appropriate network server, say server 51 . If the connection fails, remote device 11 is notified. Otherwise, computer 31 builds a message that includes a HTTP “GET” method and the URL of the desired hypermedia entity.
  • the header of the message is constructed from “common” parameters that are common to all users, from “session” parameters that are unique to the session with remote device 11 , and any “request” parameters that were passed in the header of the HDTP request.
  • any conflicts in the three sets of parameters are resolved in favor of request parameters first, session parameters second, and common parameters last.
  • the HTTP header may be constructed from just common parameters, just session parameters, just request parameters, or any combination of these parameters.
  • computer 31 After constructing the HTTP get request, computer 31 sends it through the established connection to server 51 .
  • Server 51 attempts to service the HTTP “GET” request and sends the result to computer 31 in a HTTP response.
  • Computer 31 checks a result code contained in the header of the HTTP response. If the result code indicates an error occurred, computer 31 may take any of several possible actions explained below. If the result code indicates the request was serviced successfully, computer 31 builds an appropriate HDTP response containing the results of the get request and sends the HDTP response to remote device 11 . Computer 31 may compress, encrypt or convert the result as desired. If server 51 does not respond with a complete result within a reasonable period of time, the connection is dropped and an error indication is returned to remote device 11 .
  • Remote device 11 acknowledges receipt of the HDTP response and displays and/or processes message entities included in the response. If computer 31 does not receive an acknowledgement within a reasonable period of time, it sends the HDTP response again. Computer 31 may repeat the transmission one or more times until an acknowledgment is received. If an acknowledgement is not received after a desired number of attempts, computer 31 may discard the result and abandon the attempt to send it, save the result in storage 32 for a future attempt, or save a message for future transmission indicating the result was discarded.
  • Computer 31 may respond with error indications for a variety of circumstances. For example, computer 31 may notify remote device 11 that the requested URL is for a scheme or protocol that is not supported, or that the requested URL designates a network server that cannot be resolved using the Domain Name Service (DNS).
  • DNS Domain Name Service
  • HTTP result codes are numerical codes of the form XXX. If the result code in a HTTP response is 301 or 302 , a “redirection error,” it indicates the requested resource has been moved. The new URL may be returned to remote device 11 . Alternatively, computer 31 may respond to the redirection error by using the new URL to establish a connection with the new server, say server 52 , construct a new HTTP get request and submit it to server 52 . The response from server 52 and the new URL are returned to remote device 11 .
  • Computer 31 may check storage 32 to determine if there is a user name and password for the realm that generated the error. If an appropriate user name and password are available, computer 31 can resubmit the request with the authorizing information. If a user name and password are not available, or if the resubmitted request results in a another unauthorized error, computer 31 may construct a HDTP deck with an entry card by which the user can enter the correct user name and password for the realm generating the error.
  • client errors (4xx), server errors (5xx) and other types of errors may be handled by computer 31 returning a deck with one or more display cards explaining the nature of the error and what course of action the user may consider taking.
  • Remote device 11 can use a post request to send data to a server.
  • remote device 11 builds a HDTP “Post” request including the URL of the intended network server and a block of data.
  • Computer 31 constructs and sends a corresponding HTTP “POST” method in a manner similar to that described above for the get request.
  • client functions do not need to be implemented to realize the benefits of the present invention, some client functions are important in many applications. These functions include creating and managing sessions with a hypermedia server, handling a variety of error conditions like those discussed above, authenticating a user to the server, establishing a private session and managing user certificates and encryption keys, managing a first level cache, handling redirection errors and validating hypermedia content.
  • the operational characteristics of client 1 are affected by parameters and other information stored in storage 32 .
  • Examples of operational characteristics include a list of authorized subscribers or users, resources that are available to each respective user, and timeout values for respective remote devices 11 and computer 31 .
  • these parameters and information are maintained by a facility on computer 31 that operates as a network server, perhaps a HTTP server. In this manner, the operational characteristics of client 1 can be administered locally or remotely by an authorized network client.
  • the headers for each HTTP request can include a parameter that specifies what type of content for the response is acceptable. As mentioned above, in some embodiments this parameter can be obtained from common parameters, session parameters or request parameters.
  • Computer 31 can check the content of any reply from a server and determine whether the content is acceptable to remote device 11 . If the content is not acceptable, computer 31 may notify remote device 11 of the error. For example, content types such as applets, movies and certain types of images may not be acceptable. Alternatively, when possible, computer 31 may convert the content into a form that is acceptable. For example, computer 31 may be able to convert one type of image, say JPEG, into an acceptable form, say GIF.
  • An HDTP session can have a very long life, extending beyond the time remote device 11 is turned off.
  • a session can also be interrupted by some other function remote device 11 is required to perform such as, for example, a wireless telephone initiating or receiving a voice telephone call.
  • Remote device 11 can resume a suspended session with computer 31 by preserving session-related information in persistent storage. This information includes the session identifier and any information required to identify computer 31 .
  • the saved information can include encryption keys, flags indicating the type of encryption method, block-chaining values, or other information needed to resume encryption.
  • encryption can be initiated anew as is done at time of session creation.
  • remote device 11 when turned on, determines whether a session was suspended. If it was, remote device 11 sends a request to computer 31 using the session-related information stored in persistent storage. Computer 31 receives the request, validates the session and determines whether the session has expired. If the session is valid, computer 31 services the request. If the session is not valid, computer 31 returns an error indication to remote device 11 which can then initiate a request to create a new session.
  • remote device 11 establishes session parameters used to construct HDTP headers. These parameters can be set according to values provided by remote device 11 and/or computer 31 . These parameters may include HTTP related values such as Accept, Accept-Charset and Accept-Language, and they may include values not related to the HTTP such as a timeout interval between sending retries, maximum packet length remote device 11 can accept and the encryption algorithm to use. Preferably, in subsequent exchanges between remote device 11 and computer 31 after these parameters are established, headers include only parameters that the receiving device does not already know.
  • headers are formed in a manner that simplifies the processing required to parse and interpret the embedded information.
  • Headers for the HDTP contain pairs of ASCII text strings, each string terminated by a null or zero-valued byte. The first string in each pair specifies a key or parameter name and the second string provides the key's value.
  • Most headers contain a single byte that specifies the header type. Frequently used keys and values can be encoded into single bytes having a value from 128 to 255.
  • remote device 11 also checks during initialization for anything relevant that is pending in computer 31 . For example, responses or message entities may have queued up in computer 31 while the session with remote device 11 was suspended.
  • remote device 11 can obtain the current time from computer 31 by a request.
  • Various network services including electronic mail have the ability to notify a user when some asynchronous or unsolicited event has occurred or is about to occur.
  • the term “unsolicited” refers to an event that is not a direct result of some user request.
  • a notification of the arrival of one or more pieces of electronic mail or data from other users or from services providing periodic stock price quotations are examples of unsolicited events.
  • a user can request delivery of the mail, the data, or some other message from the network server that provided the notification.
  • the network service providing the notification may reside on server 51 , for example, or it may reside on computer 31 .
  • the time required to obtain the unsolicited information is at least as great as the total time it takes to convey the request to the server and to convey the reply from the server to the user's terminal or workstation.
  • the communication time is usually not a factor; however, as mentioned above, signal propagation time between remote device 11 and computer 31 can be significant in systems where the communication path has a low bandwidth. For example, data communication via wireless telephones is sometimes restricted to as little as a few hundred bits per sec.
  • the primary source of user dissatisfaction in such applications is how much time is spent waiting for return of the reply, not when the reply actually arrives. For example, if electronic mail were to arrive in a user mail box at 3:00 p.m., most users would not be concerned whether the mail reached their terminal at 3:02 p.m. or 3:05 p.m. What is of concern, however, is the perceived delay, the time spent waiting for requested information to arrive. The perceived delay can be greatly reduced by delivering at least a portion of the unsolicited information to remote device 11 before notifying the user.
  • a network service receives messages representing one or more instances of unsolicited information for remote device 11 .
  • That network service causes computer 31 to generate one or more message entities representing at least a portion of the unsolicited information and to send those message entities to remote device 11 .
  • the message entities are assembled into one or more HDML decks that are contained in a digest.
  • a message entity that specifies an operation, or type of operation, that remote device 11 is to perform to notify the user.
  • the notification may be a visual presentation on screen 12 , or it may be an aural or tactile presentation by some other suitable transducer.
  • the notification may also be accompanied by text, presented on display 12 , explaining the nature of the notification.
  • the message entity specifying the notification can also contain the URL of any related hypermedia entity such as the fulltext of electronic mail, embedded files, an “entry” card for preparing an immediate reply, etc.
  • the digest preferably includes cards representing a portion of each piece of mail, say the first 100 characters, one or more cards containing a list of all mail in the user's mail box, and a card with one or more URLs that causes the network service to deliver the text of one or more messages.
  • Remote device 11 should process the cards, decks and other message entities included in the digest in strict order.
  • the notification or alert message entity should be processed after the preceding message entities have been stored in storage 14 and are available for display or other processing.
  • Prefetch notifications specify a deck or digest which an application executing in remote device 11 requests and stores in storage 14 before notifying a user.
  • notification or alert message entities are stored in persistent storage and a card is provided that displays a list of alert message entities that have been sent to remote device 11 .
  • An indication of whether a user has acted on a notification is stored and displayed for each respective alert message entity.
  • remote device 11 determines if a duplicate entity is already stored. If a duplicate entity is stored, the older entity is deleted and the new entity is stored, clearing any indication that the user has acted on the corresponding notification.
  • bookmark server a network server
  • the URL of this server is sent to remote device 11 during initialization of the device.
  • remote device 11 uses the bookmark server URL to construct a request to save the bookmark of the deck containing the currently displayed card. This may be done by appending the bookmark server URL with an argument specifying the deck bookmark and submitting the request to computer 31 .
  • Computer 31 passes the request to the bookmark server.
  • the bookmark server services the request by saving the bookmark specified in the argument in a list uniquely associated with remote device 11 .
  • an entry card can be used to prompt the user for a name or description of the bookmark.
  • the name and bookmark URL are sent to the bookmark server which saves the bookmark and accompanying name in the list.
  • the bookmark server can also store one or more state variables used by remote device 11 to display or process the associated deck. For example, a state variable may be used to save information that a user entered through an entry card. These state variables can be conveyed to the bookmark server by additional arguments appended to the server URL.
  • decks and specified cards within decks may contain indications that they cannot be bookmarked. If a user attempts to save a bookmark for such a card or for any card with such a deck, remote device 11 is caused to display an appropriate message informing the user that the current card cannot be marked.
  • Remote device 11 can request all or part of the stored list by sending an appropriate request to the bookmark server.
  • the request comprises the URL of the bookmark server appended with an argument specifying the first entry in the list to send.
  • an initial request would specify the first entry in the list.
  • the bookmark server would build a response representing entries one through N and a value referencing entry number N+1.
  • a subsequent retrieval request from remote device 11 would include the URL of the bookmark server appended with an argument specifying the N+1 entry.
  • the deck and cards in the reply received from the bookmark server can also contain methods for modifying or deleting bookmarks in the stored list.
  • a request to modify a bookmark can be made by appending the bookmark server URL with arguments specifying a change to the -selected bookmark and the desired change.
  • a request to delete a bookmark can be made by appending the bookmark server URL with arguments specifying a deletion of the selected bookmark.
  • the bookmark server By implementing the bookmark server as a standard HTTP server, the bookmark list for a user can be accessed and maintained by any standard HTTP client. This feature allows a user to setup and maintain the list more easily using a conventional computer.

Abstract

Access to hypermedia servers connected to networks such as the Internet can be provided through mobile devices such as wireless telephones. Unfortunately, limitations in processing power and memory space of the mobile device and limitations bandwidth of the communication channels connecting the mobile devices to the rest of the network cause long wait times for many types of requests to be serviced. In one application, a user is notified that unsolicited electronic mail has arrived in the user's mail box on a computer connected directly a network and, in response, the user requests the mail to be sent to the mobile device. The perceived latency in servicing such a request can be reduced by delivering at least a portion of the unsolicited electronic mail to mobile device before notifying the user that the mail has arrived in the mail box. In this manner, at least a portion of that mail can be presented to the user in response to a request with little delay.

Description

    CROSS-REFERENCE TO A RELATED APPLICATION
  • This application is a continuation of U.S. non-provisional application Ser. No. 09/995,683 filed Dec. 22, 1997, which claimed the priority of U.S. provisional application No. 60/052,394 filed Jul. 11, 1997. The contents of those applications, including a microfiche appendix, are incorporated herein by reference in their entirety. [0001]
  • TECHNICAL FIELD
  • The present invention relates generally to devices and methods for interacting with hypermedia servers connected to networks. More particularly, the present invention pertains to structures and methods of system interactions arranged such that practical access to hypermedia servers is available to a wider range of devices such as wireless telephones. [0002]
  • BACKGROUND ART
  • Although networks like the Internet have been in existence for years, they have not been a popular medium of information exchange until very recently. The recent explosive growth in usage of the Internet, for example, is due in large part to the development of devices and methods that simplify the actions a user must take to access multimedia information stored by network servers. One significant development is the use of hyperlinks which allows disparate pieces of information to be organized in nonsequential ways and which allows a user to easily navigate among the linked information. By assigning a unique identifier to each distinct piece of multimedia information available throughout a network, information can be readily accessed without regard to where it is stored. Network clients and servers participating in such a “hypermedia” network are referred to herein as hypermedia clients and hypermedia servers, respectively. [0003]
  • The Hypertext Transfer Protocol (HTTP) is one example of a method that implements hyperlinks and is probably the most widely used method for accessing the Internet today. A unique identifier, known as a Uniform Resource Locator (URL), specifies the location of a resource that can be accessed from the network. [0004]
  • HTTP clients and HTTP servers typically communicate with one another using any one of a family of communication protocols known collectively as Transmission Control Protocol/Internet Protocol (TCP/IP). One commonly used member of the family, known as Transmission Control Protocol (TCP), provides for a very reliable delivery of an information stream. According to the TCP, a sender establishes a “connection” with a receiver, transmits an information stream in basic units known as packets, and retransmits any packets that are either lost or corrupted during transmission. One advantage of the TCP is that it guarantees the receiver will receive the bits and bytes in the information stream in the correct order. Unfortunately, the TCP requires considerable computing and network bandwidth resources. The establishment of a connection, for example, may require an exchange of more than ten packets between sender and receiver. [0005]
  • In addition to the resources required to implement the TCP, the HTTP itself also requires considerable resources to format, process and display information. This is not a significant disadvantage in many situations because personal computers and other workstations with sufficient computing power, memory and display capabilities are readily available to implement the HTTP client function. [0006]
  • There is, however, a growing interest to provide access to hypermedia servers connected to networks such as the Internet through mobile devices, particularly handheld devices like wireless telephones. These devices are characterized by severe limitations in processing power, memory space, display size, and buttons or keys by which a user can request, view and manipulate information obtained from a hypermedia server. Furthermore, the bandwidth of the communication channels connecting the mobile devices to the rest of the network is also severely limited. [0007]
  • A wireless telephone has only a small fraction of the resources provided by a typical desktop or portable computer. Typically, the processing power is less than one percent of the processing power in many computers, the memory space is generally much less than 150 kilobytes (kB), and the display is perhaps four lines high and twelve or twenty characters wide. Graphics capabilities are very limited or nonexistent. The communication path is often in the range of 400 to 19,200 bits per sec. and the cost using that communication path is measured in terms of United States dollars per 100 kB or more. [0008]
  • Attempts to implement HTTP client functions in portable devices have not been very successful. Attempts that have used mobile devices providing facilities which are comparable to conventional computers are unattractive because the cost of the device is very high. Other attempts using less expensive devices are also unattractive because the client functions are severely limited. In either case, the communication delays and costs in exchanging packets with the network just to establish a connection, for example, are intolerable. The delays are particularly annoying in situations where a user is notified that electronic mail or other information has been received in the user's “mail box” somewhere on the network and the user must wait during the roundtrip delay required to request and receive that mail from the mail box. The usability of the device is further impaired because there is insufficient memory space to store lists of frequently used hyperlinks. For HTTP clients, these hyperlink identifiers are URLs that are often difficult to remember and difficult to enter into the device due to limited data entry capabilities. Two popular software products used in conventional computers refer to these stored hyperlinks as “bookmarks” and “favorites.”[0009]
  • DISCLOSURE OF INVENTION
  • It is an object of the present invention to provide structures and methods required by devices to interact with hypermedia servers connected to networks so that practical access to such servers is available to a wider range of devices such as wireless telephones. [0010]
  • According to the teachings of the present invention in one embodiment of a system for reducing perceived latency in servicing user requests made from remote devices communicating on low-bandwidth communication channels, where the system comprises a computer that is coupled to a transmitter and to a hypermedia server, comprises first storage, the computer executes a first program that causes the computer to receive unsolicited information from the hypermedia server and an identification of an intended recipient of the unsolicited information and, in response thereto, to store in the first storage one or more first records representing contents of the unsolicited information, to generate a plurality of messages in response to the first records, to send the messages via the transmitter so as to be received by a respective remote device associated with the intended recipient, and to send a notification via the transmitter so as to be received by the respective remote device, where the notification indicates the plurality of messages have been sent to the respective remote device. [0011]
  • The various features of the present invention and its preferred embodiments may be better understood by referring to the following discussion and the accompanying drawing. The contents of the following discussion and the drawing are set forth as examples only and should not be understood to represent limitations upon the scope of the present invention. [0012]
  • BRIEF DESCRIPTION OF DRAWING
  • The FIGURE illustrates in schematic form the major components of a system in which a device such as a wireless telephone can access the resources provided by a hypermedia server connected to a network. [0013]
  • MODES FOR CARRYING OUT THE INVENTION Overview
  • The FIGURE illustrates a system in which various aspects of the present invention may be practiced. As will be explained below, some of the components illustrated in the FIGURE may be omitted in various embodiments. As shown, [0014] client 1 uses network 40 to access resources provided by server 51 and server 52. Although it is contemplated that server 51 and server 52 are hypermedia servers, perhaps operating in conformity with the Hypertext Transfer Protocol (HTTP), this is not necessary to practice the present invention.
  • [0015] Client 1 comprises computer 31 and device 11, which is remotely located with respect to computer 31. Remote device 11 and computer 31 perform functions that implement client 1. Remote device 11 provides a user interface through which information can be presented to a user and input can be received from a user. Computer 31 exchanges information with network 40 in a manner that is consistent with a conventional network client.
  • [0016] Computer 31 stores parameters and information in storage 32 that typically is a combination of random access memory (RAM), read-only memory (ROM) and long-term storage devices such as magnetic and optical disk drives. Computer 31 communicates with remote device 11 through receiver 21 and transmitter 22. Information that is sent by computer 31 through transmitter 22 is received by remote device 11 through receiver 16. Information that is sent by remote device 11 through transmitter 15 is received by computer 31 through receiver 21.
  • In the embodiment shown in the FIGURE, [0017] remote device 11 comprises display 12, one or more buttons 13, storage 14, transmitter 15 and receiver 16. For example, device 11 may be a wireless telephone such as a MobileAccess™ telephone by Mitsubishi Wireless Communications, Inc., or a Duette telephone by Samsung Electronics Corporation. In typical wireless telephones, the display 12 is a liquid crystal display (LCD) panel. Buttons 13 represent one or more data entry devices such as switches, keys or buttons. Storage 14 represents memory circuits or other devices that are capable of storing digital information. Preferably, at least part of storage 14 is persistent storage, meaning that information is retained when device 11 is turned off. In some embodiments, a portion of storage 14 is organized into a unified push/pull cache. It is also contemplated that a portion of storage 14 will store program instructions, either in persistent memory or in ROM, and that device 11 will comprise a microprocessor or other type of processing circuitry capable of executing the program instructions.
  • The nature of the communication paths shown between [0018] computer 31, server 51 server 52, receiver 21 and transmitter 22 are not critical to the practice of the present invention. Such paths may be implemented as switched and/or non-switched paths using private and/or public facilities. Similarly, the topology of network 40 is not critical and may be implemented in a variety of ways including hierarchical and peer-to-peer networks. Computer 31 and server 51, for example, may be locally located with respect to one another and may be implemented on the same hardware.
  • In concept, the nature of the communication paths between [0019] computer 31 and device 11 is also not critical to the practice of the present invention; however, in many applications device 11 is a wireless device that uses a communication technology such as electromagnetic transmission in the radio-frequency to infrared portions of the spectrum. In applications where device 11 is a wireless telephone, a cellular telephone for example, transmitter 15, receiver 16, receiver 21 and transmitter 22 represent communication facilities used for normal telephone calls.
  • Examples of devices and methods that may be used to practice various aspects of the present invention are discussed below. The following discussion describes variations of a preferred embodiment that implements [0020] client 1 according to the HTTP; however, it should be understood that the present invention is not so limited.
  • Remote Device
  • In applications where [0021] client 1 is implemented as a HTTP client, device 11 provides at least three basic functions. A navigation function allows a user to navigate or traverse HTTP Uniform Resource Locator (URL) hyperlinks. A communication function exchanges information with computer 31. An interface function provides a user interface through which information may be presented to the user and through which input may be received from the user.
  • Preferably, these functions are implemented by a software-controlled process using an event-driven architecture. Events may be initiated by a user through [0022] buttons 13, for example, or may be initiated by signals received through receiver 16. The navigation function operates in either of two states. In the “ready” state the device awaits user input specifying a hyperlink to traverse. In the “pending” state the communication function has submitted a request to computer 31 and the device is waiting for a reply from computer 31. In terms of the HTTP, the ready state waits for user input specifying the URL of a hypermedia entity to display or process and the pending state waits for computer 31 to provide a requested hypermedia entity.
  • In one embodiment, hypermedia information is exchanged with [0023] computer 31 according to the Handheld Device Transfer Protocol (HDTP). A specification for a version of this protocol, sometimes referred to as Secure UPLink Gateway Protocol (SUGP), is provided in an Annex. The HDTP resembles the HTTP but is optimized for use with remote devices like wireless telephones and preferably is conveyed using the User Datagram Protocol/IP (UDP/IP). The UDP/IP is generally regarded as being less reliable than TCP/IP, for example, because it does not guarantee that packets will be received, nor does it guarantee that packets will be received in the same order that they are sent. Datagram protocols like the UDP/IP are attractive in practicing the present invention, however, because it does not require a “connection” to be established between a sender and a receiver before information can be exchanged. This eliminates the need to exchange a large number of packets during session creation.
  • In a preferred embodiment, hypermedia information is organized according to a Handheld Device Markup Language (HDML) into cards and decks. Multiple decks and other types of message entities can be organized into information structures called digests. A specification for a version of HDML is provided in the Annex. [0024]
  • A “deck” is the smallest unit of HDML information that can be exchanged with [0025] computer 31. Each deck has a unique identifier or URL. A user may navigate from one deck to another by traversing hyperlinks that reference the desired deck. If remote device 11 has a cache for received decks, the device first consults the cache to determine if the requested deck is available. Remote device 11 may also be implemented to determine if a desired deck found in cache is also current, that is, not out of date. If so, that deck is accessed without requiring any communication with computer 31. If the requested deck is not in the cache or is out of date, however, a request for that deck is sent to computer 31. This is discussed in more detail below.
  • Because the display on remote device may be too small to show all the information in a deck at one time, each deck may be organized into one or more cards. A “card” is a unit of information that can be displayed and/or can define how a user may interact with the device. [0026]
  • There are several types of cards. A “display” card conveys information that is to be displayed. An “entry” card conveys a method that permits a user to enter information and typically also conveys information to display. A “choice” card presents alternatives for selection by a user. Entry and choice cards also convey methods to be performed by [0027] device 11 that carry out functions necessary to receive input or recognize the chosen alternative. Typically, entry and choice cards cause one or more state variables to be set according to the information that is entered or the alternative that is chosen. A display card can also set one or more variables. A special form of the display card does not cause any visible display but can be used to set one or more variables.
  • A “digest” is an optional information structure that may be used to facilitate the transmission and processing of multiple message entities including HDML decks. In particular, each message entity in a digest is processed in sequence according to entity type. In one embodiment, message entity types include HDML decks, images and alerts. One important use of the digest and the alert entity is discussed below. [0028]
  • The current state of the three basic functions, navigation, communication and interface, can be expressed in terms of the deck and card in that deck that is currently displayed and one or more variables needed to process the card. By saving this information in persistent storage, [0029] remote device 11 can restore the current state at a future time. A cache of decks, a navigation history of hyperlink traversals and a history of user activity can also be used to improve performance, provide additional functions to the user, and provide additional facilities for use by system developers.
  • Handheld devices like telephones have severely limited facilities for entering information. The input facilities of these devices are often limited to the familiar twelve keys of a pushbutton telephone. One common method for entering text is to assign letters to various numeric keys according to normal telephone conventions. For example, the letters ABC are assigned to the “2” key and the letters DEF are assigned to the “3” key. The letters Q and Z could be assigned to the “0” key, for example. According to this method, the letter A is entered by pressing the “2” key once and the letter B is entered by pressing the key twice. In preferred embodiments of [0030] remote device 11, a form of letter prediction is used to make text entry more efficient.
  • This prediction can be based on the statistics of letter combinations. For example, after entering the letters T and H, it is much more likely that a user will enter the letter E than the letters D or F. Accordingly, after entering T and H, in response to a user pressing the “3” key, [0031] remote device 11 will present the letter E first rather than the letter D. The prediction can be based on a table of probabilities for various three-letter combinations stored in storage 14.
  • Intermediate Computer
  • [0032] Computer 31, together with remote device 11, provides the functions of a conventional hypermedia client. In the embodiment discussed above, computer 31 receives information from remote device 11 according to the HDTP, translates the HDTP information into corresponding HTTP information as necessary, and sends the result to server 51. Similarly, computer 31 receives information from server 51 according to the HTTP, translates the HTTP information into corresponding HDTP information as necessary, and sends the result to remote device 11. Preferably, HDTP information exchanged with remote device 11 is compiled from a textual form into a binary form that reduces the bandwidth requirements of the communication channel and reduces the processing required by remote device 11 to parse and interpret the information. Alternatively or in addition, the information may be subjected to other types of data compression to reduce bandwidth requirements.
  • Basic Exchange of Messages
  • By using the UDP/IP, a session can be created more efficiently than is possible using the more common TCP/IP. The exchange of information needed to create a session is similar to the exchange carried out for other types of requests. An exchange can be initiated by [0033] remote device 11 sending a request to computer 31. Subsequently, computer 31 returns a reply to the request and remote device 11 acknowledges receipt of the reply. The reply may either be expected results of the request or it may be an indication of some error encountered while attempting to service the request. If remote device 11 does not receive a reply within some timeout interval, it will send the request to computer 31 again. Remote device 11 will send the request repeatedly until either it receives a reply message, or a standby or “HoldOn” message from computer 31. The length of the timeout interval can be user configurable or it can be established by information previously received from computer 31. Similarly, computer 31 will send the reply repeatedly until it receives the acknowledgement from remote device 11.
  • For example, [0034] remote device 11 may initiate the creation of a session by sending a session-creation request to computer 31. The request includes any necessary authentication information, one or more session parameters, and information describing the device and version of software in use. Computer 31 receives the request, validates the authentication information, checks that the user is entitled to initiate a session, assigns an identifier to the new session, builds a message containing the session identifier and any information that computer 31 wishes to pass to remote device 11, and sends the message to remote device 11. Preferably, this message also includes the URL of a “home page” associated with the device. Remote device 11 acknowledges receipt of the message and the session is established.
  • Get Request
  • As another example, when a user traverses a hyperlink, [0035] remote device 11 consults its cache, if any, and determines if the cache already has the requested hypermedia entity (HDTP deck). If it does and the deck in the cache is not out of date, remote device 11 can process the requested deck and no further action is required. If the requested deck is not available or is out of date, however, remote device 11 builds a message including a HDTP “Service Request” and the URL of the requested deck and sends the message to computer 31. According to the HDTP, the message also includes a header with information that is unique to the request. Remote device 11 then waits for a reply from computer 31. The reply may be the requested deck or it may be an indication that an error occurred while attempting to service the request.
  • [0036] Computer 31 receives the request, checks its validity and attempts to establish a connection with the appropriate network server, say server 51. If the connection fails, remote device 11 is notified. Otherwise, computer 31 builds a message that includes a HTTP “GET” method and the URL of the desired hypermedia entity. In one embodiment, the header of the message is constructed from “common” parameters that are common to all users, from “session” parameters that are unique to the session with remote device 11, and any “request” parameters that were passed in the header of the HDTP request. Preferably, any conflicts in the three sets of parameters are resolved in favor of request parameters first, session parameters second, and common parameters last. Alternatively, the HTTP header may be constructed from just common parameters, just session parameters, just request parameters, or any combination of these parameters.
  • After constructing the HTTP get request, [0037] computer 31 sends it through the established connection to server 51. Server 51 attempts to service the HTTP “GET” request and sends the result to computer 31 in a HTTP response. Computer 31 checks a result code contained in the header of the HTTP response. If the result code indicates an error occurred, computer 31 may take any of several possible actions explained below. If the result code indicates the request was serviced successfully, computer 31 builds an appropriate HDTP response containing the results of the get request and sends the HDTP response to remote device 11. Computer 31 may compress, encrypt or convert the result as desired. If server 51 does not respond with a complete result within a reasonable period of time, the connection is dropped and an error indication is returned to remote device 11.
  • [0038] Remote device 11 acknowledges receipt of the HDTP response and displays and/or processes message entities included in the response. If computer 31 does not receive an acknowledgement within a reasonable period of time, it sends the HDTP response again. Computer 31 may repeat the transmission one or more times until an acknowledgment is received. If an acknowledgement is not received after a desired number of attempts, computer 31 may discard the result and abandon the attempt to send it, save the result in storage 32 for a future attempt, or save a message for future transmission indicating the result was discarded.
  • Variations on the Get Request
  • [0039] Computer 31 may respond with error indications for a variety of circumstances. For example, computer 31 may notify remote device 11 that the requested URL is for a scheme or protocol that is not supported, or that the requested URL designates a network server that cannot be resolved using the Domain Name Service (DNS).
  • HTTP result codes are numerical codes of the form XXX. If the result code in a HTTP response is [0040] 301 or 302, a “redirection error,” it indicates the requested resource has been moved. The new URL may be returned to remote device 11. Alternatively, computer 31 may respond to the redirection error by using the new URL to establish a connection with the new server, say server 52, construct a new HTTP get request and submit it to server 52. The response from server 52 and the new URL are returned to remote device 11.
  • If the result code in a HTTP response is [0041] 401, it indicates the user is not authorized access to a particular “realm.” Computer 31 may check storage 32 to determine if there is a user name and password for the realm that generated the error. If an appropriate user name and password are available, computer 31 can resubmit the request with the authorizing information. If a user name and password are not available, or if the resubmitted request results in a another unauthorized error, computer 31 may construct a HDTP deck with an entry card by which the user can enter the correct user name and password for the realm generating the error.
  • Generally, client errors (4xx), server errors (5xx) and other types of errors may be handled by [0042] computer 31 returning a deck with one or more display cards explaining the nature of the error and what course of action the user may consider taking.
  • Additional Functions and Features
  • [0043] Remote device 11 can use a post request to send data to a server. In one embodiment, remote device 11 builds a HDTP “Post” request including the URL of the intended network server and a block of data. Computer 31 constructs and sends a corresponding HTTP “POST” method in a manner similar to that described above for the get request.
  • Although many client functions do not need to be implemented to realize the benefits of the present invention, some client functions are important in many applications. These functions include creating and managing sessions with a hypermedia server, handling a variety of error conditions like those discussed above, authenticating a user to the server, establishing a private session and managing user certificates and encryption keys, managing a first level cache, handling redirection errors and validating hypermedia content. [0044]
  • The operational characteristics of [0045] client 1 are affected by parameters and other information stored in storage 32. Examples of operational characteristics include a list of authorized subscribers or users, resources that are available to each respective user, and timeout values for respective remote devices 11 and computer 31. In preferred embodiments, these parameters and information are maintained by a facility on computer 31 that operates as a network server, perhaps a HTTP server. In this manner, the operational characteristics of client 1 can be administered locally or remotely by an authorized network client.
  • The headers for each HTTP request can include a parameter that specifies what type of content for the response is acceptable. As mentioned above, in some embodiments this parameter can be obtained from common parameters, session parameters or request parameters. [0046] Computer 31 can check the content of any reply from a server and determine whether the content is acceptable to remote device 11. If the content is not acceptable, computer 31 may notify remote device 11 of the error. For example, content types such as applets, movies and certain types of images may not be acceptable. Alternatively, when possible, computer 31 may convert the content into a form that is acceptable. For example, computer 31 may be able to convert one type of image, say JPEG, into an acceptable form, say GIF.
  • Remote Device Initialization
  • An HDTP session can have a very long life, extending beyond the time [0047] remote device 11 is turned off. A session can also be interrupted by some other function remote device 11 is required to perform such as, for example, a wireless telephone initiating or receiving a voice telephone call. Remote device 11 can resume a suspended session with computer 31 by preserving session-related information in persistent storage. This information includes the session identifier and any information required to identify computer 31. In addition, if encryption has been in use for this session, the saved information can include encryption keys, flags indicating the type of encryption method, block-chaining values, or other information needed to resume encryption. Alternatively, encryption can be initiated anew as is done at time of session creation.
  • In an embodiment allowing resumption of a suspended session, [0048] remote device 11, when turned on, determines whether a session was suspended. If it was, remote device 11 sends a request to computer 31 using the session-related information stored in persistent storage. Computer 31 receives the request, validates the session and determines whether the session has expired. If the session is valid, computer 31 services the request. If the session is not valid, computer 31 returns an error indication to remote device 11 which can then initiate a request to create a new session.
  • At the time of session creation, [0049] remote device 11 establishes session parameters used to construct HDTP headers. These parameters can be set according to values provided by remote device 11 and/or computer 31. These parameters may include HTTP related values such as Accept, Accept-Charset and Accept-Language, and they may include values not related to the HTTP such as a timeout interval between sending retries, maximum packet length remote device 11 can accept and the encryption algorithm to use. Preferably, in subsequent exchanges between remote device 11 and computer 31 after these parameters are established, headers include only parameters that the receiving device does not already know.
  • Preferably, headers are formed in a manner that simplifies the processing required to parse and interpret the embedded information. Headers for the HDTP contain pairs of ASCII text strings, each string terminated by a null or zero-valued byte. The first string in each pair specifies a key or parameter name and the second string provides the key's value. Most headers contain a single byte that specifies the header type. Frequently used keys and values can be encoded into single bytes having a value from 128 to 255. [0050]
  • In preferred embodiments, [0051] remote device 11 also checks during initialization for anything relevant that is pending in computer 31. For example, responses or message entities may have queued up in computer 31 while the session with remote device 11 was suspended.
  • Most practical implementations of [0052] remote device 11 do not maintain accurate time. In preferred embodiments, during initialization or at any time thereafter, remote device 11 can obtain the current time from computer 31 by a request.
  • Reducing Perceived Latency
  • Various network services including electronic mail have the ability to notify a user when some asynchronous or unsolicited event has occurred or is about to occur. In this context, the term “unsolicited” refers to an event that is not a direct result of some user request. A notification of the arrival of one or more pieces of electronic mail or data from other users or from services providing periodic stock price quotations are examples of unsolicited events. In response to the notification, a user can request delivery of the mail, the data, or some other message from the network server that provided the notification. Referring to the FIGURE, the network service providing the notification may reside on [0053] server 51, for example, or it may reside on computer 31.
  • The time required to obtain the unsolicited information is at least as great as the total time it takes to convey the request to the server and to convey the reply from the server to the user's terminal or workstation. In conventional systems, the communication time is usually not a factor; however, as mentioned above, signal propagation time between [0054] remote device 11 and computer 31 can be significant in systems where the communication path has a low bandwidth. For example, data communication via wireless telephones is sometimes restricted to as little as a few hundred bits per sec.
  • Significantly, the primary source of user dissatisfaction in such applications is how much time is spent waiting for return of the reply, not when the reply actually arrives. For example, if electronic mail were to arrive in a user mail box at 3:00 p.m., most users would not be concerned whether the mail reached their terminal at 3:02 p.m. or 3:05 p.m. What is of concern, however, is the perceived delay, the time spent waiting for requested information to arrive. The perceived delay can be greatly reduced by delivering at least a portion of the unsolicited information to [0055] remote device 11 before notifying the user.
  • In one embodiment, a network service receives messages representing one or more instances of unsolicited information for [0056] remote device 11. That network service causes computer 31 to generate one or more message entities representing at least a portion of the unsolicited information and to send those message entities to remote device 11. Preferably, the message entities are assembled into one or more HDML decks that are contained in a digest. Also included in the digest is a message entity that specifies an operation, or type of operation, that remote device 11 is to perform to notify the user. The notification may be a visual presentation on screen 12, or it may be an aural or tactile presentation by some other suitable transducer. The notification may also be accompanied by text, presented on display 12, explaining the nature of the notification. The message entity specifying the notification can also contain the URL of any related hypermedia entity such as the fulltext of electronic mail, embedded files, an “entry” card for preparing an immediate reply, etc.
  • In electronic mail applications, the digest preferably includes cards representing a portion of each piece of mail, say the first 100 characters, one or more cards containing a list of all mail in the user's mail box, and a card with one or more URLs that causes the network service to deliver the text of one or more messages. [0057] Remote device 11 should process the cards, decks and other message entities included in the digest in strict order. Significantly, the notification or alert message entity should be processed after the preceding message entities have been stored in storage 14 and are available for display or other processing.
  • In practice, notification or alert message entities are often used with “prefetch notifications.” Prefetch notifications specify a deck or digest which an application executing in [0058] remote device 11 requests and stores in storage 14 before notifying a user.
  • In preferred embodiments of [0059] remote device 11, notification or alert message entities are stored in persistent storage and a card is provided that displays a list of alert message entities that have been sent to remote device 11. An indication of whether a user has acted on a notification is stored and displayed for each respective alert message entity. When a new alert message entity arrives, remote device 11 determines if a duplicate entity is already stored. If a duplicate entity is stored, the older entity is deleted and the new entity is stored, clearing any indication that the user has acted on the corresponding notification.
  • Saving Lists of Bookmarks
  • In devices like wireless telephones, there is usually insufficient storage to save lists of frequently used hypermedia links, e.g., URLs. This limitation reduces the usefulness of these devices because hypermedia links are usually difficult to remember and especially difficult to enter into the device. Software products for conventional computers provide facilities to save lists of these links. Two popular products refer to these stored links as “bookmarks” and “favorites.”[0060]
  • This limitation is overcome by storing designated hypermedia links or bookmarks on a network server, referred to herein as a bookmark server. In one embodiment, the URL of this server is sent to [0061] remote device 11 during initialization of the device.
  • In response to the activation of a [0062] particular button 13, remote device 11 uses the bookmark server URL to construct a request to save the bookmark of the deck containing the currently displayed card. This may be done by appending the bookmark server URL with an argument specifying the deck bookmark and submitting the request to computer 31. Computer 31 passes the request to the bookmark server. The bookmark server services the request by saving the bookmark specified in the argument in a list uniquely associated with remote device 11. In addition, an entry card can be used to prompt the user for a name or description of the bookmark. The name and bookmark URL are sent to the bookmark server which saves the bookmark and accompanying name in the list. Preferably, the bookmark server can also store one or more state variables used by remote device 11 to display or process the associated deck. For example, a state variable may be used to save information that a user entered through an entry card. These state variables can be conveyed to the bookmark server by additional arguments appended to the server URL.
  • In preferred embodiments, decks and specified cards within decks may contain indications that they cannot be bookmarked. If a user attempts to save a bookmark for such a card or for any card with such a deck, [0063] remote device 11 is caused to display an appropriate message informing the user that the current card cannot be marked.
  • [0064] Remote device 11 can request all or part of the stored list by sending an appropriate request to the bookmark server. In one embodiment, the request comprises the URL of the bookmark server appended with an argument specifying the first entry in the list to send. For example, an initial request would specify the first entry in the list. In reply, the bookmark server would build a response representing entries one through N and a value referencing entry number N+1. A subsequent retrieval request from remote device 11 would include the URL of the bookmark server appended with an argument specifying the N+1 entry. By continuing in this manner, the user is able to retrieve and display all entries in the stored list of bookmarks.
  • The deck and cards in the reply received from the bookmark server can also contain methods for modifying or deleting bookmarks in the stored list. A request to modify a bookmark can be made by appending the bookmark server URL with arguments specifying a change to the -selected bookmark and the desired change. Similarly, a request to delete a bookmark can be made by appending the bookmark server URL with arguments specifying a deletion of the selected bookmark. [0065]
  • By implementing the bookmark server as a standard HTTP server, the bookmark list for a user can be accessed and maintained by any standard HTTP client. This feature allows a user to setup and maintain the list more easily using a conventional computer. [0066]
  • Annex
  • Documents in a microfiche appendix to parent application Ser. No. 09/995,683 filed Dec. 22, 1997 are incorporated herein by reference as an Annex to this main disclosure. The Annex includes computer program listings, specifications, proposals, specific implementations and features of particular products that describe and embody various aspects of the present invention. Terms such as “required,” “must,” “significant,” “necessary,” “minimum” and “maximum” refer to particular embodiments disclosed therein and do not represent limitations on the scope of the present invention. Because these documents describe several versions of specific products, specifications and proposals, some features and terminology may differ among the several documents and this main disclosure. Not all features described therein are required to practice the present invention; the various features may be used in essentially any combination. These documents describe some features that are either omitted or are not discussed in as much detail in this main disclosure. To this extent, these documents augment the main disclosure. To the extent that these documents disclose or suggest limitations that are not described in the main disclosure, those inconsistencies are to be resolved in favor of the main disclosure. [0067]

Claims (33)

1. A system for reducing perceived latency in servicing user requests for unsolicited information made from remote devices, the system comprising a computer that is coupled to a transmitter and to a hypermedia server, wherein the computer comprises first storage and executes a first program that causes the computer to
(a) receive from the hypermedia server the unsolicited information and an identification of an intended recipient of the unsolicited information, wherein the unsolicited information is received according to a first transmission protocol in a first form, and
(b) in response to the receipt of the unsolicited information and recipient identification, to cause the computer:
(1) to generate a plurality of message entities that convey at least a portion of the contents of the unsolicited information in a second form that differs from the first form,
(2) to send the message entities via the transmitter according to a second transmission protocol that differs from the first transmission protocol so as to be received by a respective remote device associated with the intended recipient, wherein the second transmission protocol is optimized for use with a wireless device, and
(3) to send a notification via the transmitter so as to be received by the respective remote device, wherein the notification indicates the plurality of message entities have been sent to the respective remote device.
2. A system according to
claim 1
wherein the message entities in the second form preserve the order of the unsolicited information in the first form.
3. A system according to
claim 1
wherein the first transmission protocol conforms to a hypertext transfer protocol and the second transmission protocol conforms to a handheld device transfter protocol.
4. A system according to
claim 1
wherein the first form conforms to a first (hypertext) markup language specification and the second form conforms to a second (handheld device) markup language.
5. A system according to
claim 1
wherein the first program causes the computer to:
determine type of content conveyed by the message entities,
check whether the type of content is acceptable to the respective remote device, and
if not acceptable, convert the content into another type before sending it to the respective remote device.
6. A system for reducing perceived latency in servicing user requests for unsolicited information made from remote devices, the system comprising a computer that is coupled to a transmitter and to a hypermedia server, wherein the computer comprises first storage and executes a first program that causes the computer to
(a) receive from the hypermedia server the unsolicited information and an identification of an intended recipient of the unsolicited information, and
(b) in response to the receipt of the unsolicited information and recipient identification, to cause the computer:
(1) to generate a plurality of message entities that convey at least a portion of the contents of the unsolicited information, wherein the plurality of message entities are represented by one or more cards arranged in a deck of information, at least one of the cards conveying a link to another deck or to a resource available by way of the hypermedia server,
(2) to send the deck via the transmitter so as to be received by a respective remote device associated with the intended recipient, and
(3) to send a notification via the transmitter so as to be received by the respective remote device, wherein the notification indicates the plurality of message entities have been sent to the respective remote device.
7. A system according to
claim 6
wherein each of the cards has a respective type within a set of types including a type that is to be displayed by the respective remote device, a type that is not to be displayed, a type that offers a choice to a user, and a type that allows a user to enter information.
8. A system according to
claim 6
wherein a respective card includes access control information that indicates whether information conveyed in the respective card has access restricted to specific decks.
9. A system according to
claim 6
wherein the deck has a unique identifier in the form of a Uniform Resource Locator (URL).
10. A system according to
claim 6
wherein the notification includes a link to a service in any of the remote device, the computer or the hypermedia server that, when invoked, acts on the notification.
11. A system for reducing perceived latency in servicing user requests for unsolicited information made from remote devices, the system comprising a computer that is coupled to a transmitter and to a hypermedia server, wherein the computer comprises first storage and executes a first program that causes the computer to
(a) receive from the hypermedia server the unsolicited information and an identification of an intended recipient of the unsolicited information,
(b) in response to the receipt of the unsolicited information and recipient identification, to cause the computer:
(1) to generate a plurality of message entities that convey at least a portion of the contents of the unsolicited information,
(2) to send the message entities via the transmitter so as to be received by a respective remote device associated with the intended recipient, and
(3) to send a notification via the transmitter so as to be received by the respective remote device, wherein the notification indicates the plurality of message entities have been sent to the respective remote device,
(c) establish a communication session with the respective remote device, wherein a set of session parameters are established that is unique to the communication session,
(d) receive a request for services from the respective remote device during the communication session, wherein the request includes a set of request parameters that is unique to the request, and
(e) build a get-request to send to the hypermedia server, whrerein the get-request includes one or more parameters from each of the set of session parameters and the set of request parameters.
12. A system according to
claim 11
wherein the first program causes the computer to:
detect a conflict between a parameter in the set of session parameters and a parameter in the set of request parameters, and
include a parameter in the get request that represents a resolution of the conflict in favor of the parameter in the set of request parameters.
13. A system according to
claim 11
wherein the first program causes the computer to establish a set of common parameters that are shared by multiple users and sessions.
14. A system according to
claim 13
wherein the first program causes the computer to:
detect a conflict in respective parameters in the set of common parameters, the set of session parameters and the set of request parameters, and
include a parameter in the get request that represents a resolution of the conflict in favor of the parameter in the set of request parameters first, the parameter in the set of ssession parameters second, and the parameter in the set of common parameters last.
15. A system according to
claim 1
,
6
or 11 that further comprises the respective remote device, wherein the respective remote device is remotely located with respect to the computer and comprises a display, a receiver and second storage, and executes a second program that causes the respective remote device
to receive via the receiver the plurality of message entities and, in response thereto, to store in the second storage one or more first records representing contents of the message entities, and
to receive via the receiver the notification and, in response thereto, to present an alert notifying the intended recipient that the first records are stored in the second storage.
16. A system according to
claim 15
wherein the respective remote device is a wireless telephone.
17. A system according to
claim 15
wherein the respective remote device is a handheld device.
18. A system according to
claim 15
wherein the second program causes the remote device
store the notification in persistent storage, and
to display a list of notifications that have been received by the remote device.
19. A system according to
claim 18
wherein the second program causes the remote device to display an indication of which notifications in the list have been acted upon by an operator of the remote device.
20. A system according to
claim 18
wherein the second program causes the remote device to determine whether a received notification is a duplicate of another notification already stored.
21. A device for use in a system for reducing perceived latency in servicing one or more user requests for unsolicited information made from the device, wherein the device is remotely located with respect to a computer and communicates with the computer, and wherein the device comprises a receiver, display, input device, storage and processor executing a program that provides:
communication facilities that receive information by the receiver from the computer,
interface facilities that present information by the display and receive input by the input device, and
navigation facilities that traverse Uniform Resource Locator (URL) links;
and wherein:
the communication facilities receive a plurality of message entities representing the unsolicited information and, in response thereto, the storage records the message entities,
the communication facilities receive a notification and, in response thereto, the interface facilities present a notification that the message entities are recorded in the storage, and
the interface facilities receive a user request and, in response thereto, present the unsolicited information, wherein the unsolicited information is obtained for presentation by the navigation facilities traversing a URL link conveyed by a message entity.
22. A device according to
claim 21
wherein the navigation facility traverses the URL link to obtain unsolicited information from the storage.
23. A device according to
claim 21
wherein the navigation facility traverses the URL link to obtain unsolicited information from the computer.
24. A device according to
claim 21
wherein the message entities are represented by one or more cards arranged in a deck of information, at least one of the cards conveying a link to another deck or to a resource available by way of the computer.
25. A device according to
claim 24
wherein each of the cards has a respective type within a set of types including a type that is to be presented by the display, a type that is not to be presented, and a type that allows entry of information through the input device.
26. A device according to
claim 24
wherein a respective card includes access control information that indicates whether information conveyed in the respective card has access restricted to specific decks.
27. A device according to
claim 24
wherein the deck has a unique identifier in the form of a Uniform Resource Locator (URL).
28. A device according to
claim 24
wherein the notification includes a link to a service provided by the device or the computer that, when invoked, acts on the notification.
29. A device according to
claim 21
that is a wireless telephone.
30. A device according to
claim 21
that is a handheld device.
31. A device according to
claim 21
that comprises persistent storage, wherein the program causes the device:
to store the notification in persistent storage, and
to present a list of notifications that have been received by the device.
32. A device according to
claim 31
that presents an indication of which notifications in the list have been acted upon by a user.
33. A device according to
claim 31
wherein the program causes the device to determine whether a received notification is a duplicate of another notification already stored in persistent storage and to delete from persistent storage one of the duplicate notifications.
US09/839,858 1997-07-11 2001-04-20 Reducing perceived latency in servicing user requests on low-bandwidth communication channels Abandoned US20010016875A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US09/839,858 US20010016875A1 (en) 1997-07-11 2001-04-20 Reducing perceived latency in servicing user requests on low-bandwidth communication channels

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US5239497P 1997-07-11 1997-07-11
US08/995,683 US6243739B1 (en) 1997-07-11 1997-12-22 Reducing perceived latency in servicing user requests on low-bandwidth communication channels
US09/839,858 US20010016875A1 (en) 1997-07-11 2001-04-20 Reducing perceived latency in servicing user requests on low-bandwidth communication channels

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US08/995,683 Continuation US6243739B1 (en) 1997-07-11 1997-12-22 Reducing perceived latency in servicing user requests on low-bandwidth communication channels

Publications (1)

Publication Number Publication Date
US20010016875A1 true US20010016875A1 (en) 2001-08-23

Family

ID=26730554

Family Applications (2)

Application Number Title Priority Date Filing Date
US08/995,683 Expired - Lifetime US6243739B1 (en) 1997-07-11 1997-12-22 Reducing perceived latency in servicing user requests on low-bandwidth communication channels
US09/839,858 Abandoned US20010016875A1 (en) 1997-07-11 2001-04-20 Reducing perceived latency in servicing user requests on low-bandwidth communication channels

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US08/995,683 Expired - Lifetime US6243739B1 (en) 1997-07-11 1997-12-22 Reducing perceived latency in servicing user requests on low-bandwidth communication channels

Country Status (1)

Country Link
US (2) US6243739B1 (en)

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040030916A1 (en) * 2002-08-07 2004-02-12 Karamchedu Murali M. Preemptive and interactive data solicitation for electronic messaging
WO2004056067A1 (en) * 2002-12-17 2004-07-01 Koninklijke Philips Electronics N.V. Method and system for multimedia messaging service
US20040248558A1 (en) * 2003-06-04 2004-12-09 Chandhok Ravinder Paul Method and apparatus for translating resource names in a wireless environment
US20060136339A1 (en) * 2004-11-09 2006-06-22 Lg Electronics Inc. System and method for protecting unprotected digital contents
US20060239449A1 (en) * 2004-12-21 2006-10-26 Michael Holtzman Memory system with in stream data encryption / decryption and error correction
US20060242429A1 (en) * 2004-12-21 2006-10-26 Michael Holtzman In stream data encryption / decryption method
US20080065891A1 (en) * 2002-08-07 2008-03-13 Kryptiq Corporation Opaque message archives
US7444410B1 (en) * 2002-02-15 2008-10-28 Oracle International Corporation Application platform execution environment
US20110197093A1 (en) * 2002-12-06 2011-08-11 Stuart Cain Reduced wireless internet connect time
US20120215841A1 (en) * 2010-03-18 2012-08-23 Tencent Technology (Shenzhen) Company Limited Method and system for synchronizing operations of multiple groups
US8862676B1 (en) * 2012-06-22 2014-10-14 Google Inc. User notification digestion
US8886620B1 (en) * 2005-08-16 2014-11-11 F5 Networks, Inc. Enabling ordered page flow browsing using HTTP cookies

Families Citing this family (57)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7035914B1 (en) 1996-01-26 2006-04-25 Simpleair Holdings, Inc. System and method for transmission of data
US5895471A (en) 1997-07-11 1999-04-20 Unwired Planet, Inc. Providing a directory of frequently used hyperlinks on a remote server
US6243739B1 (en) * 1997-07-11 2001-06-05 Phone.Com, Inc. Reducing perceived latency in servicing user requests on low-bandwidth communication channels
US6268857B1 (en) * 1997-08-29 2001-07-31 Xerox Corporation Computer user interface using a physical manipulatory grammar
US6636733B1 (en) 1997-09-19 2003-10-21 Thompson Trust Wireless messaging method
US6253061B1 (en) 1997-09-19 2001-06-26 Richard J. Helferich Systems and methods for delivering information to a transmitting and receiving device
US20040107208A1 (en) * 1997-12-09 2004-06-03 Seet Siew Shon Method and apparatus for bookmarking telephone numbers for efficient access by wireless phone devices
US6343318B1 (en) 1998-05-29 2002-01-29 Palm, Inc. Method and apparatus for communicating information over low bandwidth communications networks
US7025209B2 (en) * 1998-05-29 2006-04-11 Palmsource, Inc. Method and apparatus for wireless internet access
US20030120775A1 (en) * 1998-06-15 2003-06-26 Compaq Computer Corporation Method and apparatus for sending address in the message for an e-mail notification action to facilitate remote management of network devices
JP3225926B2 (en) * 1998-07-14 2001-11-05 日本電気株式会社 E-mail transmission / reception method and system, and machine-readable recording medium recording program
JP3704533B2 (en) * 1998-11-10 2005-10-12 株式会社東芝 COMMUNICATION METHOD, PORTABLE TERMINAL DEVICE, AND COMPUTER DEVICE
US6697844B1 (en) * 1998-12-08 2004-02-24 Lucent Technologies, Inc. Internet browsing using cache-based compaction
US6560640B2 (en) 1999-01-22 2003-05-06 Openwave Systems, Inc. Remote bookmarking for wireless client devices
GB2346985B (en) * 1999-02-19 2003-07-09 Ibm Client/server transaction data processing system with optimum selection of last agent
US6684087B1 (en) * 1999-05-07 2004-01-27 Openwave Systems Inc. Method and apparatus for displaying images on mobile devices
US6704788B1 (en) * 1999-07-06 2004-03-09 General Instrument Corporation Method and apparatus for transmitting and reassembling packetized data in large scale networks
US8448059B1 (en) * 1999-09-03 2013-05-21 Cisco Technology, Inc. Apparatus and method for providing browser audio control for voice enabled web applications
DE19956023B4 (en) * 1999-10-01 2019-10-02 Ipcom Gmbh & Co. Kg Method for transmitting messages between at least one center and a terminal and adaptation device therefor
US7194520B1 (en) * 2000-02-25 2007-03-20 Cypress Semiconductor Corp. Content player for broadcasting to information appliances
US7240100B1 (en) * 2000-04-14 2007-07-03 Akamai Technologies, Inc. Content delivery network (CDN) content server request handling mechanism with metadata framework support
NL1017189C1 (en) * 2000-08-30 2002-03-01 Koninkl Kpn Nv Method and system for activation of a local terminal.
US20020042815A1 (en) * 2000-09-22 2002-04-11 Arthur Salzfass Automated system and method for routing undeliverable e-mail messages and otherwise managing e-mail
GB2372175B (en) * 2001-02-13 2004-06-23 Vodafone Ltd Provision of services via a mobile telecommunications network
GB2375004A (en) * 2001-02-22 2002-10-30 Nokia Networks Oy Collecting, storing and using information associated with user equipment
US7941313B2 (en) * 2001-05-17 2011-05-10 Qualcomm Incorporated System and method for transmitting speech activity information ahead of speech features in a distributed voice recognition system
US7801959B1 (en) * 2001-05-31 2010-09-21 Palmsource, Inc. Method and system for pushing electronic messages to a wireless portable device using a standard mail server interface
US7203643B2 (en) * 2001-06-14 2007-04-10 Qualcomm Incorporated Method and apparatus for transmitting speech activity in distributed voice recognition systems
US20030135574A1 (en) * 2001-12-20 2003-07-17 Burg Frederick Murray Independent notification of urgent messages
US20030208524A1 (en) * 2002-05-02 2003-11-06 Morman Daniel N. System for routing data in a communication network
CN100562022C (en) * 2002-11-25 2009-11-18 诺基亚有限公司 Use the conversation managing method and the system of client sessions sign
US7395048B2 (en) * 2002-12-26 2008-07-01 Motorola, Inc. Unsolicited wireless content delivery and billing apparatus and method
FI20030881A (en) * 2003-06-12 2004-12-13 Nokia Corp Method, Device Arrangement, Cellular Network Terminal, and Software Application within the Terminal to Provide a Location-Based Alarm
DE10353117B3 (en) * 2003-11-12 2005-07-14 Vodafone Holding Gmbh Method for transmitting data to a mobile terminal in mobile networks
US8406341B2 (en) 2004-01-23 2013-03-26 The Nielsen Company (Us), Llc Variable encoding and detection apparatus and methods
US20050208930A1 (en) * 2004-03-05 2005-09-22 Robert Zmrzli Method and apparatus for arranging network content on mobile devices
US20050208929A1 (en) * 2004-03-05 2005-09-22 Robert Zmrzli Method and apparatus for providing updated network content to target devices
US20050198353A1 (en) * 2004-03-05 2005-09-08 Robert Zmrzli Method and apparatus for providing dynamic network content to target devices
US7437169B2 (en) 2004-06-07 2008-10-14 Microsoft Corporation System and method for optimizing network communication in response to network conditions
WO2006037014A2 (en) * 2004-09-27 2006-04-06 Nielsen Media Research, Inc. Methods and apparatus for using location information to manage spillover in an audience monitoring system
KR100617775B1 (en) * 2004-11-08 2006-08-28 삼성전자주식회사 Method for managing duplicated message notification in multimedia messaging service
MX2007011471A (en) * 2005-03-17 2007-12-05 Nielsen Media Res Inc Methods and apparatus for using audience member behavior information to determine compliance with audience measurement system usage requirements.
JP2007318245A (en) * 2006-05-23 2007-12-06 Nec Corp Cellular phone system, cellular phone terminal, personal information protecting method, personal information protecting program and program recording medium
US10885543B1 (en) 2006-12-29 2021-01-05 The Nielsen Company (Us), Llc Systems and methods to pre-scale media content to facilitate audience measurement
US8606862B2 (en) * 2007-08-21 2013-12-10 Microsoft Corporation Electronic mail delay adaptation
US8909714B2 (en) * 2007-08-21 2014-12-09 Microsoft Corporation Electronic mail delay adaptation
US8706819B2 (en) * 2007-08-21 2014-04-22 Microsoft Corporation Electronic mail delay adaptation
US8855101B2 (en) 2010-03-09 2014-10-07 The Nielsen Company (Us), Llc Methods, systems, and apparatus to synchronize actions of audio source monitors
US8885842B2 (en) 2010-12-14 2014-11-11 The Nielsen Company (Us), Llc Methods and apparatus to determine locations of audience members
US9304711B2 (en) 2012-10-10 2016-04-05 Apple Inc. Latency reduction in read operations from data storage in a host device
US9021516B2 (en) 2013-03-01 2015-04-28 The Nielsen Company (Us), Llc Methods and systems for reducing spillover by measuring a crest factor
US9118960B2 (en) 2013-03-08 2015-08-25 The Nielsen Company (Us), Llc Methods and systems for reducing spillover by detecting signal distortion
US9219969B2 (en) 2013-03-13 2015-12-22 The Nielsen Company (Us), Llc Methods and systems for reducing spillover by analyzing sound pressure levels
US9191704B2 (en) 2013-03-14 2015-11-17 The Nielsen Company (Us), Llc Methods and systems for reducing crediting errors due to spillover using audio codes and/or signatures
US9219928B2 (en) 2013-06-25 2015-12-22 The Nielsen Company (Us), Llc Methods and apparatus to characterize households with media meter data
US9924224B2 (en) 2015-04-03 2018-03-20 The Nielsen Company (Us), Llc Methods and apparatus to determine a state of a media presentation device
US9848222B2 (en) 2015-07-15 2017-12-19 The Nielsen Company (Us), Llc Methods and apparatus to detect spillover

Citations (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5265033A (en) * 1991-09-23 1993-11-23 Atm Communications International, Inc. ATM/POS based electronic mail system
US5479472A (en) * 1991-05-20 1995-12-26 Ntp Incorporated System for interconnecting electronic mail systems by RF communications and method of operation thereof
US5487100A (en) * 1992-09-30 1996-01-23 Motorola, Inc. Electronic mail message delivery system
US5493692A (en) * 1993-12-03 1996-02-20 Xerox Corporation Selective delivery of electronic messages in a multiple computer system based on context and environment of a user
US5561703A (en) * 1994-07-06 1996-10-01 Rolm Company System and method for integration of a paging server into a private branch exchange environment
US5675507A (en) * 1995-04-28 1997-10-07 Bobo, Ii; Charles R. Message storage and delivery system
US5732074A (en) * 1996-01-16 1998-03-24 Cellport Labs, Inc. Mobile portable wireless communication system
US5745689A (en) * 1996-05-23 1998-04-28 Electronic Data Systems Corporation System and method for providing pager services to users of a computer network
US5754772A (en) * 1996-03-26 1998-05-19 Unisys Corporation Transaction service independent HTTP server-to-transaction gateway
US5790790A (en) * 1996-10-24 1998-08-04 Tumbleweed Software Corporation Electronic document delivery system in which notification of said electronic document is sent to a recipient thereof
US5809415A (en) * 1995-12-11 1998-09-15 Unwired Planet, Inc. Method and architecture for an interactive two-way data communication network
US5822539A (en) * 1995-12-08 1998-10-13 Sun Microsystems, Inc. System for adding requested document cross references to a document by annotation proxy configured to merge and a directory generator and annotation server
US5822405A (en) * 1996-09-16 1998-10-13 Toshiba America Information Systems, Inc. Automated retrieval of voice mail using speech recognition
US5872926A (en) * 1996-05-31 1999-02-16 Adaptive Micro Systems, Inc. Integrated message system
US5895471A (en) * 1997-07-11 1999-04-20 Unwired Planet, Inc. Providing a directory of frequently used hyperlinks on a remote server
US5903723A (en) * 1995-12-21 1999-05-11 Intel Corporation Method and apparatus for transmitting electronic mail attachments with attachment references
US5905777A (en) * 1996-09-27 1999-05-18 At&T Corp. E-mail paging system
US5907598A (en) * 1997-02-20 1999-05-25 International Business Machines Corporation Multimedia web page applications for AIN telephony
US5937041A (en) * 1997-03-10 1999-08-10 Northern Telecom, Limited System and method for retrieving internet data files using a screen-display telephone terminal
US5943399A (en) * 1995-09-29 1999-08-24 Northern Telecom Limited Methods and apparatus for providing communications to telecommunications terminals
US5944786A (en) * 1996-12-04 1999-08-31 Quinn; Ken Automatic notification of receipt of electronic mail (e-mail) via telephone system without requiring log-on to e-mail server
US5974443A (en) * 1997-09-26 1999-10-26 Intervoice Limited Partnership Combined internet and data access system
US6006260A (en) * 1997-06-03 1999-12-21 Keynote Systems, Inc. Method and apparatus for evalutating service to a user over the internet
US6049291A (en) * 1996-09-09 2000-04-11 Datalink Net, Inc. Interactive two-way pager systems
US6067561A (en) * 1997-02-07 2000-05-23 Hughes Electronics Corporation Electronic mail notification system and method within a hybrid network that transmits notifications via a continuous, high-speed channel
US6181935B1 (en) * 1996-09-27 2001-01-30 Software.Com, Inc. Mobility extended telephone application programming interface and method of use
US6182129B1 (en) * 1997-09-11 2001-01-30 International Business Machines Corporation Apparatus, methods and computer program products for managing sessions with host-based application using session vectors
US6202060B1 (en) * 1996-10-29 2001-03-13 Bao Q. Tran Data management system
US6208839B1 (en) * 1996-12-19 2001-03-27 Motorola, Inc. Remote token based information acquistion system
US6209036B1 (en) * 1997-06-06 2001-03-27 International Business Machines Corporation Management of and access to information and other material via the world wide web in an LDAP environment
US6237027B1 (en) * 1996-06-20 2001-05-22 Sony Corporation Electronic mail system, computer device, and remote notification method
US6243739B1 (en) * 1997-07-11 2001-06-05 Phone.Com, Inc. Reducing perceived latency in servicing user requests on low-bandwidth communication channels
US6289389B1 (en) * 1997-06-03 2001-09-11 Lextron Systems, Inc. Enhanced integrated data delivery system
US6393014B1 (en) * 1997-06-03 2002-05-21 At&T Wireless Services, Inc. Method and system for providing data communication with a mobile station
US6594481B1 (en) * 1992-11-12 2003-07-15 Lightbridge, Inc. Apparatus and method for detecting potentially fradulent telecommunication
US6823361B2 (en) * 2001-01-08 2004-11-23 International Business Machines Corporation Computationally efficient, platform-independent data transfer protocol

Patent Citations (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5479472A (en) * 1991-05-20 1995-12-26 Ntp Incorporated System for interconnecting electronic mail systems by RF communications and method of operation thereof
US5265033A (en) * 1991-09-23 1993-11-23 Atm Communications International, Inc. ATM/POS based electronic mail system
US5487100A (en) * 1992-09-30 1996-01-23 Motorola, Inc. Electronic mail message delivery system
US6594481B1 (en) * 1992-11-12 2003-07-15 Lightbridge, Inc. Apparatus and method for detecting potentially fradulent telecommunication
US5493692A (en) * 1993-12-03 1996-02-20 Xerox Corporation Selective delivery of electronic messages in a multiple computer system based on context and environment of a user
US5561703A (en) * 1994-07-06 1996-10-01 Rolm Company System and method for integration of a paging server into a private branch exchange environment
US5675507A (en) * 1995-04-28 1997-10-07 Bobo, Ii; Charles R. Message storage and delivery system
US5943399A (en) * 1995-09-29 1999-08-24 Northern Telecom Limited Methods and apparatus for providing communications to telecommunications terminals
US5822539A (en) * 1995-12-08 1998-10-13 Sun Microsystems, Inc. System for adding requested document cross references to a document by annotation proxy configured to merge and a directory generator and annotation server
US5809415A (en) * 1995-12-11 1998-09-15 Unwired Planet, Inc. Method and architecture for an interactive two-way data communication network
US5903723A (en) * 1995-12-21 1999-05-11 Intel Corporation Method and apparatus for transmitting electronic mail attachments with attachment references
US5732074A (en) * 1996-01-16 1998-03-24 Cellport Labs, Inc. Mobile portable wireless communication system
US5754772A (en) * 1996-03-26 1998-05-19 Unisys Corporation Transaction service independent HTTP server-to-transaction gateway
US5745689A (en) * 1996-05-23 1998-04-28 Electronic Data Systems Corporation System and method for providing pager services to users of a computer network
US5872926A (en) * 1996-05-31 1999-02-16 Adaptive Micro Systems, Inc. Integrated message system
US6237027B1 (en) * 1996-06-20 2001-05-22 Sony Corporation Electronic mail system, computer device, and remote notification method
US6049291A (en) * 1996-09-09 2000-04-11 Datalink Net, Inc. Interactive two-way pager systems
US5822405A (en) * 1996-09-16 1998-10-13 Toshiba America Information Systems, Inc. Automated retrieval of voice mail using speech recognition
US5905777A (en) * 1996-09-27 1999-05-18 At&T Corp. E-mail paging system
US6181935B1 (en) * 1996-09-27 2001-01-30 Software.Com, Inc. Mobility extended telephone application programming interface and method of use
US5790790A (en) * 1996-10-24 1998-08-04 Tumbleweed Software Corporation Electronic document delivery system in which notification of said electronic document is sent to a recipient thereof
US6202060B1 (en) * 1996-10-29 2001-03-13 Bao Q. Tran Data management system
US5944786A (en) * 1996-12-04 1999-08-31 Quinn; Ken Automatic notification of receipt of electronic mail (e-mail) via telephone system without requiring log-on to e-mail server
US6208839B1 (en) * 1996-12-19 2001-03-27 Motorola, Inc. Remote token based information acquistion system
US6067561A (en) * 1997-02-07 2000-05-23 Hughes Electronics Corporation Electronic mail notification system and method within a hybrid network that transmits notifications via a continuous, high-speed channel
US5907598A (en) * 1997-02-20 1999-05-25 International Business Machines Corporation Multimedia web page applications for AIN telephony
US5937041A (en) * 1997-03-10 1999-08-10 Northern Telecom, Limited System and method for retrieving internet data files using a screen-display telephone terminal
US6006260A (en) * 1997-06-03 1999-12-21 Keynote Systems, Inc. Method and apparatus for evalutating service to a user over the internet
US6289389B1 (en) * 1997-06-03 2001-09-11 Lextron Systems, Inc. Enhanced integrated data delivery system
US6393014B1 (en) * 1997-06-03 2002-05-21 At&T Wireless Services, Inc. Method and system for providing data communication with a mobile station
US6209036B1 (en) * 1997-06-06 2001-03-27 International Business Machines Corporation Management of and access to information and other material via the world wide web in an LDAP environment
US6243739B1 (en) * 1997-07-11 2001-06-05 Phone.Com, Inc. Reducing perceived latency in servicing user requests on low-bandwidth communication channels
US5895471A (en) * 1997-07-11 1999-04-20 Unwired Planet, Inc. Providing a directory of frequently used hyperlinks on a remote server
US6182129B1 (en) * 1997-09-11 2001-01-30 International Business Machines Corporation Apparatus, methods and computer program products for managing sessions with host-based application using session vectors
US5974443A (en) * 1997-09-26 1999-10-26 Intervoice Limited Partnership Combined internet and data access system
US6823361B2 (en) * 2001-01-08 2004-11-23 International Business Machines Corporation Computationally efficient, platform-independent data transfer protocol

Cited By (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7444410B1 (en) * 2002-02-15 2008-10-28 Oracle International Corporation Application platform execution environment
US20040030916A1 (en) * 2002-08-07 2004-02-12 Karamchedu Murali M. Preemptive and interactive data solicitation for electronic messaging
US8230517B2 (en) 2002-08-07 2012-07-24 Kryptiq Corporation Opaque message archives
US20080065891A1 (en) * 2002-08-07 2008-03-13 Kryptiq Corporation Opaque message archives
US20110197093A1 (en) * 2002-12-06 2011-08-11 Stuart Cain Reduced wireless internet connect time
WO2004056067A1 (en) * 2002-12-17 2004-07-01 Koninklijke Philips Electronics N.V. Method and system for multimedia messaging service
US20040248558A1 (en) * 2003-06-04 2004-12-09 Chandhok Ravinder Paul Method and apparatus for translating resource names in a wireless environment
US7333801B2 (en) * 2003-06-04 2008-02-19 Qualcomm Incorporated Method and apparatus for translating resource names in a wireless environment
US20060136339A1 (en) * 2004-11-09 2006-06-22 Lg Electronics Inc. System and method for protecting unprotected digital contents
US20060239449A1 (en) * 2004-12-21 2006-10-26 Michael Holtzman Memory system with in stream data encryption / decryption and error correction
US20060242429A1 (en) * 2004-12-21 2006-10-26 Michael Holtzman In stream data encryption / decryption method
US8396208B2 (en) * 2004-12-21 2013-03-12 Sandisk Technologies Inc. Memory system with in stream data encryption/decryption and error correction
US8886620B1 (en) * 2005-08-16 2014-11-11 F5 Networks, Inc. Enabling ordered page flow browsing using HTTP cookies
US20120215841A1 (en) * 2010-03-18 2012-08-23 Tencent Technology (Shenzhen) Company Limited Method and system for synchronizing operations of multiple groups
US8954494B2 (en) * 2010-03-18 2015-02-10 Tencent Technology (Shenzhen) Company Limited Method and system for synchronizing operations of multiple groups
US8862676B1 (en) * 2012-06-22 2014-10-14 Google Inc. User notification digestion
US9325655B1 (en) 2012-06-22 2016-04-26 Google Inc. User notification digestion

Also Published As

Publication number Publication date
US6243739B1 (en) 2001-06-05

Similar Documents

Publication Publication Date Title
US6243739B1 (en) Reducing perceived latency in servicing user requests on low-bandwidth communication channels
US5895471A (en) Providing a directory of frequently used hyperlinks on a remote server
US7269405B2 (en) System and method for proxy-enabling a wireless device to an existing IP-based service
CN1653783B (en) System and method of mobile lightweight directory access
Rao et al. iMobile: a proxy-based platform for mobile services
US6775291B1 (en) Wireless internet service method in gateway system
US6938076B2 (en) System, computer product and method for interfacing with a private communication portal from a wireless device
EP1030244B1 (en) A multimedia direct communication system linked with http protocol
US6119167A (en) Pushing and pulling data in networks
US6810405B1 (en) System and methods for synchronizing data between multiple datasets
US6941149B2 (en) Method and apparatus for providing instant messaging in a wireless communication system
CN1732701B (en) Apparatus for restricted browser access within a wireless communication device and method therefor
US7577741B2 (en) Network communication apparatus for providing a user with a paging message
US20030231207A1 (en) Personal e-mail system and method
JP2002251333A (en) Mobile device server
CN1145286C (en) Wireless protocol method and apparatus supporting transaction requests with variable length responses
US20040107208A1 (en) Method and apparatus for bookmarking telephone numbers for efficient access by wireless phone devices
US20030074432A1 (en) State data management method and system
KR100514359B1 (en) System for Mutimedia Message Service and thereof method
US9525653B2 (en) Enhanced wireless short message service
JP3226855B2 (en) E-mail sending and receiving device system
JP2002359646A (en) Transmission reception system for electronic mail
KR100574885B1 (en) Method for receiving electronic data message of enormous
KR20030022123A (en) Method and System for Providing a Wireless Terminal Communication Session Integrated with Data and Voice Services
KR100617779B1 (en) Method and system for transmitting and receiving file between terminals

Legal Events

Date Code Title Description
AS Assignment

Owner name: PHONE.COM, INC., CALIFORNIA

Free format text: CHANGE OF NAME;ASSIGNOR:UNWIRED PLANET, INC.;REEL/FRAME:012410/0339

Effective date: 19990412

Owner name: OPENWAVE SYSTEMS, INC., CALIFORNIA

Free format text: MERGER/CHANGE OF NAME;ASSIGNOR:PHONE.COM, INC.;REEL/FRAME:012410/0668

Effective date: 20001117

Owner name: UNWIRED PLANET, INC., CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:SCHWARTZ, BRUCE V.;BOYLE, STEPHEN S.;KING, PETER F.;AND OTHERS;REEL/FRAME:012410/0436

Effective date: 19971212

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION