Store and forward architecture

A store and forward (S&F) architecture is provided that supports multiple applications within an extensible network to direct information of various formats to any of multiple destinations. In the presently preferred embodiment of the invention, Java applications running on a client send non-priority data to any server on the application network or, alternatively, anywhere on a global telecommunications network such as the Internet, at some time in the future. In the preferred embodiment, S&F allows a client application to send usage statistics to a database on the application network. It also enables T-commerce purchases to be made by the user, where the purchase and other relevant information is sent to a destination web server as if the purchase had taken place on the web via a full web browser on an Internet-connected PC.

BACKGROUND OF THE INVENTION

1. Technical Field

The invention generally relates to communications systems. More particularly, the invention generally relates to store and forward architecture.

2. Description of the Prior Art

The term “store and forward architecture” pertains to communications systems in which messages are received at intermediate routing points and recorded (i.e., stored) and then transmitted (i.e., forwarded) to the next routing point or to the ultimate recipient. Such systems are commonly used in the cable and satellite television industry. For example, DirecTV operates a satellite television system that offers such services as Pay-Per-View. In Pay-Per-View mode, a subscriber to DirecTV selects a program to be purchased and viewed. The subscriber typically has a set top box (e.g., a satellite receiver in the case of DirecTV) that contains information about the subscriber's privileges and, if the subscriber is authorized to purchase Pay-Per-View broadcasts, the set top box decodes the program selected by the subscriber for viewing when it is broadcast (e.g., via the DirecTV satellite). The set top box captures information with regard to the purchase (i.e., it stores purchase information for billing purposes). At an appropriate time, (e.g., during a regularly scheduled upstream communication from the set top box to DirecTV, such as a telephone call) the set top box sends this purchase information to the Pay-Per-View service (i.e., it forwards this stored information to DirecTV to allow the subscriber's account to be billed for their purchase of the program which they selected and viewed).

While such systems provide an effective approach to a dedicated application, (e.g., Pay-Per-View services) they are not useful or readily configurable for execution of multiple applications (e.g., Pay-Per-View and messaging and shopping). Further, such known systems operate within the confines of a well-defined network architecture (e.g. the Pay-Per-View server and associated network elements). Thus, they are not easily reconfigured to provide disparate services over an extended or extensible network. They cannot discern whether one destination within the network is more appropriate than another, because they are set to communicate with a specified destination for a dedicated purpose. They are, therefore, not agile at routing information among multiple destinations. Finally, such known systems operate within specified parameters that treat all communications in a similar fashion because all communications relate to the same thing, (e.g., Pay-Per-View). Thus, there is no notion of scheduling events, such as upward communication, based upon the nature of information to be communicated, nor are different information formats or protocols handled well within such known systems.

It would be advantageous to provide a store and forward system that supported multiple applications within an extensible network to direct information of various formats to any of multiple destinations.

SUMMARY OF THE INVENTION

Exemplary embodiments include methods and systems for a store and forward (S&F) architecture that supports multiple applications within an extensible network to direct information of various formats to any of multiple destinations. In one embodiment of the invention, Java applications running on a client send non-priority data to any server on the application network or, alternatively, anywhere on a global telecommunications network (e.g., the Internet), at some time in the future.

One embodiment is a method for an S&F system that allows a client application to send usage statistics to a database on the application network. It also enables television-based commerce (T-commerce) purchases of products via interaction with the T.V. to be made by the user, where the purchase and other relevant information is sent to a destination web server as if the purchase had taken place on the web via a full web browser on an Internet-connected personal computer (PC).

One exemplary embodiment is an S&F system, including: client-side code in a micro Java virtual machine, a Java byte code execution engine (i.e., a user space virtual machine, (UVM)), and a server-side proxy server process, communications networks, and a server-side Application server process. One communications network transports information from the client to the S&F proxy (e.g., a real-time two-way radio frequency (RF) network). Another communications network transports information from the S&F proxy to the Application Server process (e.g., an Internet protocol (IP) network).

DETAILED DESCRIPTION OF THE INVENTION

Exemplary embodiments of the invention provide a store and forward (S&F) system and methods to support multiple applications within an extensible network to direct information of various formats to any of multiple destinations. In one embodiment, Java applications running on a client send non-priority data to any server on the application network or, alternatively, anywhere on a global telecommunications network such as the Internet, at some time in the future. The S&F system has many applications, including collecting statistics and T-commerce.

In one embodiment, the S&F system allows a client application to send usage statistics to a database on the application network. It also enables T-commerce purchases to be made by the user, where the purchase and other relevant information is sent to a destination web server as if the purchase had taken place on the web via a full web browser on an Internet-connected PC. This embodiment includes two distinct parts: client-side code in the UVM; and a server-side proxy server process.

Architectural Overview

FIG. 1Ais a block schematic diagram showing an exemplary embodiment100of a store and forward logical architecture and data flow, according to the invention. In this exemplary embodiment100, a client102(e.g., a set top box (STB)) sends cable signals to an RF distribution network104. The RF distribution network104sends client messages, (e.g., user datagram protocol (UDP) messages) to an S&F proxy106at a headend. The S&F proxy106sends forwarded messages (e.g., UDP, TCP/IP or HTTP messages) to an IP network108. The IP network108sends data to an application server110. The application server110sends data to a fetcher112to further process messages. The fetcher112uses the data to generate a report114. While only one client102and application server110are shown inFIG. 1A, this exemplary embodiment may include any number of clients102, and/or application servers110.

FIG. 1Bis a block schematic diagram showing the client102ofFIG. 1Ain more detail. The client102includes client software116and an operating system118. The client software116includes a client application120, a statistics (stats) application program interface (API)122, an S&F API124, and a UVM native S&F layer126.

In this exemplary embodiment, the client application120is a Java applet running on the client102. The client application120uses the services provided by the stats API122and the S&F API124to send statistics or application-specific data to the application server110.

In this exemplary embodiment, the stats API122is middleware that resides on the client102. It facilitates the gathering of user events from client applications120on different clients102. For example, when a user starts an application from the main navigation screen (NavShell), the stats API122records the time and the application that was started. The stats API122then uses the S&F API124to send the statistics data to the S&F proxy106and ultimately to an application server110to collect usage statistics.

In this exemplary embodiment, the stats API122provides to the S&F API124the IP address and port number of the application server110to which the statistics data is sent to the S&F API124. In one embodiment, the client software116can be configured with default values for the application server110.

In one embodiment, each client102can be configured to send statistics without identifying the sender. This allows statistics to be collected anonymously, which protects individual subscribers' privacy. In addition, the client102can be configured with the amount of memory to use for storing statistics. Configuration can also specify that statistics are sent after a fixed period of time or after a certain amount of data has been collected.

In one embodiment, the S&F API124is used by the stats API122, but the S&F API124can also be used by the client application120directly. The S&F API124allows the user to specify several attributes that affect how, when and where the data is sent. The user of the S&F API124is required to provide the IP address and port number of the application server110that receives the data. The user also provides the transmission protocol that the S&F proxy106uses to send the data to the application server110. Internet protocols are supported, e.g., UDP, transmission control protocol (TCP) and hypertext transfer protocol (HTTP). When the S&F API124receives a request to send, the data and all optional and required parameters are passed to the UVM native S&F layer126.

In one embodiment, the S&F API124allows the user to specify when the initial attempt to send the data occurs, how long this transaction has to complete and how many times to retry sending the data to the S&F proxy106.

In one embodiment, when the UVM native S&F layer126receives data to send, it formats a message that contains the address of the application server110as well as the data. For more information about the structure of the message, seeFIGS. 5 and 6.

In one embodiment, the UVM native S&F layer126stores data in non-volatile read-only memory (NVRAM) to ensure that the data will be saved if the power is lost. In one embodiment, the S&F proxy106can be configured to not send S&F data during certain times of the day, called blackout periods. These blackout periods are used when the client102is being polled to retrieve PPV purchase information. Any additional traffic during these times would affect the reliability of retrieving this information. Alternatively, data can be sent from the client102to the S&F proxy106and stored in a database.

One exemplary embodiment is a scheduling algorithm that includes transaction lifetime, initial send delay, and the blackout schedule. In order to avoid having all the clients102on a network attempt to send at the same time (which would result in severe data loss), a random element is also added to the scheduling algorithm.

In one embodiment, each client102is also configured with the amount of memory to use for S&F data, the maximum number of messages to store before sending, and the IP address and port of the S&F proxy106to send to.

The operating system118provides access for sending and receiving data over the RF Distribution Network104.

In one embodiment, the RF Distribution Network104is a two-way real-time RF network. Data delivery over this network is unreliable. One exemplary embodiment of the S&F system implements additional levels of reliability. The S&F API124allows a caller to determine which level of reliability is required.

In one embodiment, the S&F proxy106is a server-side process that facilitates upstream communication for the client102via an NC1500, which is an upstream communications router (manufactured by Motorola). It is specifically used for delivering messages sent by clients102(via the RF distribution network104) to a headend communications network (not shown). When user event data is received by the S&F proxy106, the S&F proxy106tries to deliver the data to the application server110specified in the data, via UDP, TCP or HTTP as specified in the data. The S&F proxy106can send data to any of a number of application servers that are reachable via the IP network108. The S&F proxy106sends data to the application server110across the IP network108. The S&F proxy106and the application server110can communicate via any standard Internet Protocols, such as UDP, TCP or HTTP.

In one embodiment, the application server110is an entity connected to the IP network108that can receive data from the client application120via at least one of UDP, TCP and HTTP. The application server110is responsible for parsing and processing the data sent by the client application120. The S&F proxy106can be used to communicate to any application server110via the UDP, TCP/IP, or HTTP protocols.

In one embodiment, the S&F API124is used by the client application120to send raw data to a third party server using UDP, TCP, or HTTP. In one embodiment, the S&F API124interfaces with the UVM native S&F layer126, which is part of the UVM. In one embodiment, the UVM native S&F layer126stores data either in dynamic RAM or in non-volatile memory, until it is received by the S&F proxy106. One embodiment is a scheduling algorithm that takes into account blackout periods to determine when to send (i.e., forward) data to the S&F proxy106. The scheduling algorithm attempts to minimize data loss in the upstream direction by sharing the upstream communications resource across all clients102so as not to overload the upstream channel. One embodiment includes formatting data according to an S&F protocol.

Store And Forward Client-Proxy Protocol

One exemplary embodiment is a store and forward client-proxy protocol that allows for varying levels of reliability, which is achieved through the use of messages passed from the client102to the S&F proxy106and from the S&F proxy106to the client102. The client102can specify the level of messaging required by setting flags in each request message to the S&F proxy106.

In one embodiment, there are three flags that can be set: ACK, RESULT, and DONE. They can be set individually or in combination, but some combinations are invalid. Other flags may be provided as well in alternative embodiments of the invention. The first flag (ACK) tells the S&F proxy106whether or not to send the client102an acknowledgement when it has received the client's request. The purpose of this flag is to let the client102know that it is safe to purge the request data from NVRAM. The second flag (RESULT) tells the S&F proxy106whether or not the client102wants to be informed of the result of the request. Low-priority requests may not require a result to be sent back to the client. The third flag (DONE) tells the S&F proxy106whether or not to hold the result of the request until the client102sends the S&F proxy106a message acknowledging the receipt of the request result. This is important if the client102must know the result of the request. Without this flag, the S&F proxy106sends the result only once before purging the request. If that message gets lost, the client102is not able to determine the result. With this flag set, the S&F proxy106holds onto the request and the result until the client102indicates that it has successfully received the result.

Delayed Ack

In this exemplary embodiment, if the ACK flag is set or the RESULT flag is set, then the client102implements a delayed ACK scheme. This means that when the S&F proxy106receives a request, the S&F proxy106does not send the acknowledgement message right away if the ACK flag is set, but tries to complete the transaction first. If the request completes within a few seconds, e.g., ten seconds, the request result is sent instead of the acknowledgement. If the request cannot be completed in that time, the request is written to the database and, then, the acknowledgement is sent to the client102. When the request result is determined later, the result is sent if the RESULT flag is set. If the ACK flag is set and the S&F proxy106receives a duplicate request, it sends back an ACK immediately. A likely reason for the S&F proxy106to receive a duplicate is because the client102never received the first ACK, probably due to a lost message.

One exemplary embodiment is a method of operating flags. This method describes the effects of the various combinations of flags.

In this exemplary embodiment, for the combination {ACK-0, RESULT-0, DONE-0}, the client102sends the request, but the S&F proxy106does not store this in a database. The S&F proxy106does not send any message to the client102about this request. The S&F proxy106purges all information about this request as soon as it completes or times out.

In this exemplary embodiment, for the combination {ACK-1, RESULT-0, DONE-0}, when the S&F proxy106receives this message, it sends either an ACK or the result, but not both. See the discussion of DELAYED ACK for more details. The S&F proxy106writes this request to the database, if the request cannot be completed immediately. The S&F proxy106purges this request as soon as the result is known or the request timeout occurs.

In this exemplary embodiment, for the combination {ACK-0, RESULT-1, DONE-0}, when the S&F proxy106receives this message, the S&F proxy106attempts to carry out the request. See the discussion of DELAYED ACK for more details. The S&F proxy106writes this request to the database, if the request cannot be completed immediately. When the result of the request is known, the S&F proxy106sends the result once to the client102and immediately purges this request.

In this exemplary embodiment, for the combination {ACK-0, RESULT-0, DONE-1}, which is an invalid combination, if the S&F proxy106receives a request with this combination set, it turns off the DONE flag and treats it as if the flags were (0,0,0).

In this exemplary embodiment, for the combination {ACK-1, RESULT-1, DONE-0}, when the S&F proxy106receives this message, the S&F proxy106attempts to carry out the request. See the discussion of DELAYED ACK for more details. The S&F proxy106writes this request to the database, if the request cannot be completed immediately. When the result of the request is known, the S&F proxy106sends the result once to the client102and immediately purges this request.

In this exemplary embodiment, for the combination {ACK-1, RESULT-0, DONE-1}, which is an invalid combination, if the S&F proxy106receives a request with this combination set, it turns off the DONE flag and treats it as if the flags were (1,0,0).

In this exemplary embodiment, for the combination {ACK-0, RESULT-1, DONE-1}, the S&F proxy106processes the request immediately, but only writes it to the database, if the request cannot be completed in a certain period of time. No ACK is sent to the client102, once the request has been written to the database. Once the result of the request is known, the result is sent back to the client102. The S&F proxy106does not purge this result until it receives the DONE message from the client102or until the request expiry time elapses.

In this exemplary embodiment, for the combination {ACK-1, RESULT-1, DONE-1}, the S&F proxy106processes the request immediately, but only writes it to the database, if the request cannot be completed in a certain period of time and an ACK is sent to the client102. Once the result of the request is known, the result is sent back to the client102. If the result is known before the ACK has been sent, the request is not written to the database and the result is sent to the client102instead of the ACK. See the DELAYED ACK discussion for more details. The S&F proxy106does not purge this result until it receives the DONE message from the client102or until the request expiry time elapses.

Communication Session (Result)

FIG. 2shows an exemplary embodiment200of a method of providing communication sessions between the client102and the application server110via the S&F proxy106. The specifics of these communication sessions are configurable by using the three bit flags entry in a data_send packet. Setting the flags bits to 010 (-, RESULT, -) produces the communication session shown inFIG. 2. At202, the client102sends data to the S&F proxy106. At204, the S&F proxy106transfers the data from to the application server110from memory. At206, the S&F proxy106sends a RESULT message to the client102to inform it of the status of the data send to the application server110so that it may purge the majority of the transaction from memory. In the event that the initial data does not reach the S&F proxy106or the S&F proxy106goes down between the time the data is received and is sent to the application server110, a RESULT message is not sent and the client102assumes that the data did not reach the S&F proxy106, thereby causing a retransmit from the client.

FIGS. 3A-3Cshow an exemplary embodiment300of a method of providing communication sessions.FIG. 3Ashows a scenario in which the application server110cannot be contacted within a prescribed (short) period of time. At302, the client102sends data to the S&F proxy106. At304, the S&F proxy106then attempts to transfer the data to the application server110from memory. After a predetermined number of seconds the S&F proxy106assumes the application server110is down and, at306, writes the transaction to the database308.FIG. 3Bshows a scenario in which the transfer is successful. The S&F proxy106sends an ACK message, when the S&F proxy106has been able to deliver the message to the specified final destination.FIG. 3Cshows a scenario in which the S&F proxy106sends the data to the application server110at a later date. At314, the S&F proxy106then sends a RESULT message to the client102so that it may purge the majority of the transaction from NVRAM.FIG. 3Dshows a scenario in which the initial data does not reach the S&F proxy106or the S&F proxy106goes down between the time the data is received and it is sent to the application server110, an ACK message is not sent and the client102assumes that the data did not reach the S&F proxy106causing a retransmit at316.

Store And Forward Summary

Table C shows pseudo code for an exemplary embodiment of a method for providing a store and forward architecture in the client102that includes Java features, such as asynchronous application layer APIs, e.g., http APIs, and a Java API.

TABLE Cpublic class StoreAndForward{/* * Used to store and forward data to the 3rd party application* server identified by <addr:port> using the specified protocol.* The same instance can be used to forward multiple sets* of data.*/public StoreAndForward (InetAddress addr, int port, int protocol);/* Returns the IP address of the 3rd party application server. */public InetAddress getInetAddress ( );/* Returns the port of the 3rd party application server.*/public int getPort ( );/* Returns the protocol used to communicate with the app. server */public int getProtocol ( );/* Returns the current timeout value. */public int getTimeout ( );/* Returns the current maximum retry count.*/public int getMaxRetryCount ( );/* isTransaction*/public boolean isTransaction ( );/* Sets the number of retries for forwarding data.* After this limit is reached, no more retries are attempted* but the transaction state is stored until the expiry time.*/public void setMaxRetryCount (int count);/* Sets the time in seconds after which transaction is abandoned.*/public void setTimeout (int timeout);/* setTransaction */public void setTransaction(boolean isTransaction);/* Sets the minimum time (in seconds) after which the first* attempt to send data is to be made.*/public void setInitialSendTime (int time);/* Add listener to get status on all unfinished transactions */public void addNotify (SFNotifyListener nl);/* Removes a listener from the list of listeners. */public void removeNotify (SFNotifyListener nl);/* Submits data to be forwarded to the 3rd party server. *//* The transaction-id is returned. */public native int forwardData (byte [ ] data, int offset, it len);/* Cancels the transaction. */public native int cancelTransaction(int transactionID);}

One exemplary embodiment is a method for conducting a store and forward transaction that has the following steps.

1. The Java applet creates an instance of a StoreAndForward object.

2. The applet fills in the required data and invokes the send ( ) method.

3. The code in the JVM optionally stores the request in NVRAM to guard against power outages.

4. At some point in the future, the JVM sends a copy of this request to the proxy server, keeping the original in NVRAM (the flags field directs what the S&F proxy106does).

5. The S&F proxy106receives the message from the client102and tries to forward the message before it stores a copy in a database308to prevent data loss.

6. If the ACK flag is set, the S&F proxy106sends an acknowledgement back to the client102, which tells the client102that the S&F proxy106has successfully received the data, and the S&F proxy106attempts to deliver it to the application server110specified in the data.

7. The client102receives this acknowledgement and can then remove the payload part of this transaction from NVRAM because the S&F proxy106has it. It must keep some information about the transaction in NVRAM until it has completed.

8. The S&F proxy106attempts to contact the application server110at the IP address and port given in the request data via the protocol that the client102requested. In one embodiment, UDP, TCP, and HTTP POST requests are supported.

9. The S&F proxy106continues to try to send the data until the retry count or time limit to send the data has expired.

10. The S&F proxy106creates a transaction status message with the final result. If the original request was stored in the database308, the final result is modified in the database record. If the request was not stored, it is not added in this phase. The S&F proxy106only sends the final result if the RESULTS flag is set. If the DONE flag is set, the S&F proxy106resends the result message until the time limit is reached, or it gets a DONE message.

11. When the client102receives the transaction result, it can notify the original applet if it is still running.

12. The client102purges the transaction:

a) immediately after sending, if both the ACK and RESULTS are not flags are set (i.e., they are clear);

b) after receiving an ACK, or after the transaction expires, if the RESULTS flag is set.

13. When the S&F proxy106receives this DONE status message from the client102, the S&F proxy106purges all records of this transaction from the database308.

Protocol Summary

One exemplary embodiment is an S&F protocol that can be configured on each request to control the level of reliability to make the protocol flexible to handle different client requirements. The S&F protocol does this by setting up to three bit flags in the store and forward protocol header. Each of these flags adds more reliability. The S&F protocol does this by indicating the messages that are exchanged between the client102and the S&F proxy106.

In this exemplary embodiment, the three possible flags are: SEND_DATA_ACK, SEND_RESULT, and SEND_DONE. The SEND_DATA_ACK flag indicates that the client102wants the S&F proxy106to send an acknowledgement that the S&F proxy106received the client's request successfully. The client102keeps retransmitting the request until this acknowledgement is received. The SEND_RESULT flag indicates that the client102wants to have the result of the transaction sent back to it when the transaction has either completed successfully, failed, or that the lifetime has expired before the transaction could be completed. This flag can be used with the SEND_DATA_ACK flag or can be used on its own. The SEND_DONE flag indicates that the client102sends a TRANSACTION_DONE message to the proxy after it receives the transaction result. This flag is only valid if the SEND_RESULT flag is also on. Setting this flag allows the S&F proxy106to know when the client102is done with the transaction so that the S&F proxy106can purge all data associated with this transaction.

FIG. 4Ashows the messages that are exchanged when no flags are set, in this exemplary embodiment. The client102sends the data send message at400to the S&F proxy106, which sends the data to the application server110at402.

FIG. 4Bshows the messages that are exchanged when the SEND_DATA_ACK flag is set, in this exemplary embodiment. The client102sends the data send message at400to the S&F proxy106. The S&F proxy106sends a transaction status message with data acknowledgement to the client102at404.

FIG. 4Cshows the messages that are exchanged when the SEND_RESULT flag is set, in this exemplary embodiment. The client102sends the data send message at400to the S&F proxy106. The S&F proxy106sends the data to the application serer110at402. The S&F proxy106sends a transaction status message with data acknowledgement to the client102at404. The application server110sends a response to the S&F proxy106, if HTTP at406.

FIGS. 4D and 4Eshow exemplary embodiments400,402for a method that the messages that are exchanged when the DATA_ACK, SEND_RESULT and SEND_DONE flags are set, in this exemplary embodiment. This sequence provides the most reliability, but as a consequence requires the most amount of messages to be exchanged. InFIG. 4D, the data is sent successfully, but inFIG. 4E, the send is unsuccessful and times out after retrying.

InFIG. 4D, at404, a data send message is sent from the client102to the S&F proxy106. At406, the data is sent from the S&F proxy106to the application server110. At408, a transmit status message with data ACK is sent from the S&F proxy106to the client102. At410, the result is sent from the S&F proxy106to the client102with the status of the client data send request. At412, a transmit status message with DONE is sent from the client102to the S&F proxy106.

InFIG. 4E, at412, a data send message is sent from the client102to the S&F proxy106. At414, the data is unsuccessfully sent from the S&F proxy106to the application server110. At416, the S&F proxy106retries sending the data and, then, times out at418. At420, the transmit status message with result is sent from the S&F proxy106to the client102, because the request did not complete in the allowed time interval. At422, the client102send the transmit status message with done to the S&F proxy106.

Transport Protocol Details

Common Store And Forward Header

FIG. 5shows one exemplary embodiment500of a header that is sent at the start of every message both from the client102to the S&F proxy106and from the S&F proxy106down to the client102. In this exemplary embodiment500, the header includes the following fields: client media access control (MAC) address502, flags (byte)504, and transaction ID506. The client MAC502address field is the five-byte identifier for the set top box. The flags field504is a one-byte field that consists of three bits for the message type508, three bits for flags510, and two bits for the transport protocol512. The message type field508can be one of TRANS_DATA, TRANS_STATUS, or TRANS_CANCEL. The flags510can be any OR-ed combination of TRANS_SEND_DATA_ACK, TRANS_SEND_RESULT, and TRANS_SEND_DONE. The protocol field512can be one of PROTO_UDP, PROTO_TCP, or PROTO_HTTP. The transaction ID field506is a two-byte field that uniquely identifies the transaction from this client.

Data Request Message

FIG. 6shows one exemplary embodiment600of a data request message, which is included after the common data header500ofFIG. 5. In this exemplary embodiment600, the data request message includes the following fields: destination IP address602, destination port604, and send expiry604. The send expiry field604is the number of minutes, relative to the time the S&F proxy106receives the data to send to the application server110. If this time elapses without a completed send to the application server110, either a success or the application server110returned a failure (only for HTTP in one embodiment), then the transaction is considered to have timed out. No further attempts are made to send the data to the application server110. The S&F proxy106then changes transaction expiry to a value within the range of send expiry604seconds to a fixed period of time, such as 60 seconds in one embodiment, to send this TIMEDOUT result back to the client102, if RESULT was requested by the client102. The destination IP address602is the four-byte IPv4 address of the application server110to which to send the data. In another embodiment, this could be a host name of the application server, rather than an IP address. The destination port604is the two-byte port number on the application server110to which to send the data. The protocol to use to send the data is specified in the common header500.

Transaction Status Message

FIG. 7shows one exemplary embodiment700of a transaction status message. This exemplary embodiment700of the transaction status message includes the following fields: result702, state704, and padding706. This message is sent by the S&F proxy106to the client102for the purposes of acknowledgement and for sending the result of the transaction. It is sent from the client102to the S&F proxy106to indicate that the client102has finished with the transaction. This is appended after the common data header500. The result field702is the last known result of this request, which is one of the following results: INVALID, INPROGRESS, SUCCEEDED, FAILED, TIMEDOUT, CANCELLED, or TOO_MANY_TRIES. The state field704is the current state of the transaction, if the result702was INPROGRESS. Otherwise, the state field704may be one of the following states: DATA_RCVD, DATA_ACKED, SENDING_DATA, and SENT_DATA.

FIG. 8shows an exemplary embodiment800of a method of implementing a no delayed acknowledgement (ACK) scheme. (Compare the delayed ACK scheme ofFIG. 9.) In this exemplary embodiment800, messages are exchanged between the client102and the S&F proxy106. At802, the client102creates and prepares an S&F object. At804, the client102calls the S&F API124. At806, the client102stores a message in NVRAM. At808, the client102sends a copy of the message or messages to the S&F proxy106.

At810, the S&F proxy106determines whether the ACK flag is set in the message. If the ACK flag is set, at812the S&F proxy106sends an ACK message to the client102. If the ACK flag is not set, control flows to820.

At814, the client102receives the ACK message, terminates retries at816, and purges stored messages at818.

At820, after determining that the ACK flag is not set, the S&F proxy106sends the message to the destination (i.e., the application server110). At822, the S&F proxy106determines whether the message was sent successfully. If the message was not sent successfully at822, the S&F proxy106copies the message to the database308at824and retries sending the message to the destination at826. If it is determined at828that the retry was not successful, the S&F proxy106retries sending the message, until the retry limits are exceeded at830. If the retry was successful, the message is purged from the database308at832. If the message was sent successfully at822, or if a retry was successful at828, the S&F proxy106determines whether the RESULT flag is set at834. If the RESULT flag is set, the S&F proxy106sends the result to the client102at836.

At838, the client102receives the result from the S&F proxy106and, at840, returns the result to the client application120through the S&F object.

At842, after sending the result to the client at836, the S&F proxy106determines whether the DONE flag is set. If the DONE flag is set, the S&F proxy106waits for a done message or a timeout at844.

At846, after receiving the result at838, the client102determines whether the DONE flag is set. If the DONE flag is set, the client102sends a done message to the S&F proxy106at848.

At850, after determining that the DONE flag was not set at842or the RESULT flag was not set at834, the S&F proxy purges the transaction.

FIG. 9shows an exemplary embodiment900of a method of implementing a delayed acknowledgement (ACK) scheme. In this exemplary embodiment800, some of the steps are the same as the no-delay ACK scheme ofFIG. 8, but some steps are new, missing, or re-ordered in the delayed ACK scheme ofFIG. 9. The steps performed by the client102are the same as in the no-delay ACK scheme ofFIG. 8. However, inFIG. 9, the S&F proxy106does not determine whether the ACK flag is set or send the ACK message if it is. Instead, inFIG. 9, the S&F proxy simply attempts to send the message to the destination at820, without checking the ACK flag. If the message is sent successfully at822, the result is sent to the client102, without checking the RESULT flag at834. If the message is not sent successfully at822, it is copied to the database308at824and the ACK message is sent at812. This is different from the no delayed ACK scheme ofFIG. 8, where the ACK message is sent only if the ACK flag is set.

S&F Proxy Details

The S&F proxy106receives data sent from the client102and passes it on to the host specified in the data. The client102also specifies the transport mechanism to be used, e.g., TCP, UDP or HTTP. If the S&F proxy106cannot send the data to the final destination (i.e., the application server110) within a given period of time (e.g., ten seconds), then the S&F proxy106saves the client data to a database308, and sends an acknowledgement to the client102(in some embodiments) to tell the client102that the S&F proxy106has successfully received the request and is responsible for ensuring its delivery. The S&F server106continues to try to deliver the data to the destination application server110until a timeout for that request has expired, the client102cancels the request, or it has been successfully delivered.

Running The S&F Proxy

One exemplary embodiment of the S&F proxy106has the following command-line options: p, c, d, u, and w. The command-line option p specifies the UDP port number that the S&F proxy 1-6 listens on to receive requests from clients102. In one embodiment, if this option is not specified, a default of1022is used and the proxy is run with a EUID of 0. The command-line option c specifies the path to a configuration file. The default is “./.proxyrc”. This configuration file specifies the debugging level to use, as well as the name of the debugging output file to use. The configuration file can be changed at run-time and is reread by sending the S&F proxy106process a SIGHUP. The command-line option d specifies the data source name (DSN) to use. This name must refer to an entry in the odbc.ini configuration file that the S&F proxy106reads. It uses this to determine on which host the database308resides and which open database connectivity (ODBC) driver to use to communicate with it. The command-line option u specifies the username the S&F proxy106uses when logging into the database. The command-line option w specifies the password, if any, to use with the given username to log in to the database308.

In this exemplary embodiment, the data the S&F proxy106sends to the client102(e.g., set top box (STB)) is sent as a UDP packet. This UDP packet is received by the network controller (NC) and sent downstream to the client102via the out of band channel (OOB). There is a route or routes for the client IP addresses to the NC, which is the gateway to the operation, administration, management and provisioning (OAM&P) network. OAM&P is the network between the S&F proxy106and the network controller in the RF distribution network104.

APPLICATION SERVER EXAMPLE

In one embodiment, the application server110is a statistics server. When contacted by the S&F proxy106, the application server110breaks down the received information into single events and saves them, for example, in a flat text file. In one embodiment, the fetcher112is daemon that runs in a central point of the headend (not shown). The fetcher112collects data from one or more application servers110and saves the collected data to, for example, a central log file. In one embodiment, the data bridge (not shown) is a software utility that can be used to import a flat text file into an Oracle database. The fetcher112output files are used by the data bridge to store data in the database. In one embodiment, a third party tool, such as BrioQuery, can be used to create graphical representations of the collected data.

Statistics Gathering & Transmission

One exemplary embodiment is a method of statistics gathering and transmission. As events are triggered by user interaction with the client102, statistics are gathered in a buffer. At the client level, the fields are shown below in Table A.

In this exemplary embodiment, the typical size of the MENU event is approximately 34 bytes. Because of the variable “data” field, a micro browser application (μ Browser) statistic can be as large as a visited URL. The events are approximately 90 bytes in this embodiment. When the client buffer is filled and additional statistics are generated, before the current ones are removed, the oldest statistics are removed to create space. Currently, there is no operator indication when this occurs. When an upstream statistic transmission is triggered, a single, or group of statistics is sent to the S&F proxy106in a single upstream packet. The packet payload is limited to a maximum of approximately 1000 bytes in this embodiment. In this exemplary embodiment, a packet is to be sent up to a maximum of ten times between the first transmission and the maximum expiry time, currently twenty four hours. Once an ACK is received from the S&F proxy106, the client102assumes the statistic was successfully sent and removes it from memory. If, after ten attempts to send the statistic, an ACK is not received, the statistic is cleared from memory.

Log File Format—Server

In one embodiment, the log file format includes a single user event per line, with the following four tab delimited fields: date, event, user, and data. In addition, the following log file parameters may be included: server, date, and time. The date and time are measured, for example, in seconds since Jan. 1, 1970, (the UNIX Epoch) that the event reached the server in Greenwich Mean Time (GMT). This allows for the use of standard UNIX function calls for the decoding of time. The event is a four character user event code that describes a single user action. The user is an identification of the user that caused the event. In one embodiment, identification is made only at the set-top level, not at the user level. The data is any optional data associated with an event.

Current User Event Codes

Table B below outlines the event codes used in one embodiment. Each event is accompanied by a time stamp and the set-top/username. Some events also include additional data in the optional data field. For example, the TVCH event contains the numeric value of the channel that was tuned.

Additional User Event Codes

Table C below outlines the additional codes that are added to the existing set to facilitate user interaction with the Guide, μ Browser, TV Ticker, and Games, in one embodiment. Each event is accompanied by a time stamp and the set-top name. Some events also include additional data in the optional data field. For example, the APDN contains an application identifier.

TABLE CAdditional User Event CodesEventCodeDescriptionWhen Event is TriggeredData FieldGDONGuide OnUser enters the GuideThe menu in Guide that isselected. At this time, only themain menu is identified instatistics gathering; example:main.GDDNGuideUser exists a menu fromThe menu identifier and theDurationthe Guideduration using that menu inseconds; example: main; 16.APDNApplicationUser exits the applicationThe application ID and theDurationduration in the application inseconds example:μ Browser;23UWWWMicroUser leaves a URLThe URL visited and theBrowserduration spent at the URL inURLseconds example:www.liberate.com;300TKCVTVTickerUser cursors to a categoryThe category identifier that theCategoryto view available storiesuser is viewing and durationViewexample: business;5TKSTTVTickerUser selects a storyThe story identifier that theStoryuser selected and the durationSelectionspent reading story example:Sports;tc.jsp?11751;47

Example Event Entries Of Data

Some examples of typical user events are as follows, each has the following form: {timestamp, event code, client address, timestamp, application-specific data field}: (1) 996588616 APDN 0010304ead 996521265 Menu:0;3; (2) 996588616 APDN 0010304ead 996521427/interactive/Golfjar;328; (3) 996588616 APDN 0010304ead 996521530 Menu:1;8; and (4) 996588616 APDN 0010304ead 996521710/interactive/Spadesjar;175. All events arrived at the Server on Tue Jul 31 10:10:16 2001. These events can be interpreted as: (1) user displayed the menu for 3 seconds and then exited on Jul 30 15:27:45 2001; (2) user played Golf game for 328 seconds and exited on Jul 30 15:30:27 2001; (3) user displayed the menu #1 for 8 seconds and then exited on Jul 30 15:32:10 2001; and (4) user played Spades game for 175 seconds and exited on Jul 30 15:35:10 2001.

Client Configuration

One exemplary embodiment is a method for client-side provisioning for statistics gathering, which is facilitated through a configuration file. For example, a config.props file is uploaded using a carousel user interface utility to a /etc directory of an out of band file carousel, which is being transmitted to the clients102. The carousel user interface is a way to put a configuration file or other information onto a carousel server, which is at the headend and sends carouselled data files continuously to clients, e.g., set top boxes. The configuration file may include information such as configuration for the S&F system, the number of messages to store, how frequently to send them, and the like.

In this exemplary embodiment, SFProxyAddress defines the IP address of the S&F proxy106and must be in the dotted-decimal format and cannot be a hostname. Also, the IP address must be one that is connected to the IP network108. There is no default value. Therefore, if it is not provided, messages are not sent from the client102to the S&F proxy106. For example, this exemplary embodiment may set SFProxyAddress=192.168.14.215.

In this exemplary embodiment, SFProxyPort defines the port on which the S&F proxy106server is providing the S&F service. For example, this exemplary embodiment may set a default value of 1022 or SFProxyPort=10010.

In this exemplary embodiment, SFSchedDelay is used in calculating the time at which an upstream message is sent. An upstream message is sent at a random time between blackout periods. The SFSchedDelay determines the window of time within which a random value is chosen. The unit of measure for SFSchedDelay is seconds.

In this exemplary embodiment, SFMaxConcMsgs defines the maximum number of S&F messages held in memory. A value of zero is valid, but pending messages are not purged. An exemplary default value is 100.

In this exemplary embodiment, a recommended setting for SFMaxMemSize is 8192, which is the maximum amount of memory that the S&F system can use when storing messages. The unit of measure is bytes. An exemplary default value is 8192.

In this exemplary embodiment, a recommended setting for SFBlackoutScheduleis 6 AM-12 PM Daily. This defines the a times when the client102is not allowed to send upstream messages to the S&F proxy106and includes a list of start-time end-time combinations separated by commas, e.g., SFBlackoutSchedule=M 12:30 T 13:30, W 14:00 W 18:00. The schedule spans for a week. The start-times for a blackout period must be smaller than the end-time. The days of the week are abbreviated by one letter and are ordered as follows: S (Sunday)<M (Monday)<T (Tuesday)<W (Wednesday)<H (Thursday)<F (Friday)<A (Saturday). The time is specified on a 24 hour clock starting at time 0 and ending and hour 23. The separators are space (‘ ’) and comma (‘,’). Currently, the accepted blackout period for field deployments is 6 PM to 12 AM daily:

In this exemplary embodiment, StatsAnonymous specifies whether or not the statistics gathered are anonymous. In other words, if it is anonymous, then the user names are marked with an ‘X’ when they are recorded. A value of “false” results in user names being recorded. The default is to be anonymous. An exemplary value is StatsAnonymous=false.

In this exemplary embodiment, the recommended setting for StatsMaxBufferSize is 8192. This specifies the amount of S&F memory that can be used for statistics. Once the limit is reached and a new statistic is recorded, pending statistics are cancelled, starting with the oldest. The unit of measure is bytes and default value is 8192.

In this exemplary embodiment, the recommended setting for StatsBufferSize is 880. This specifies the amount of statistics data that is buffered before it is sent to the application server110. The values supported are in the range 15-880. The unit of measure is bytes.

In this exemplary embodiment, the recommended setting for StatsFlushTime is 1800. This specifies the amount of time statistics are buffered before they are flushed. The value must be greater than zero and the unit of measure is seconds.

In this exemplary embodiment, the Address variable specifies the address of the application server110and must be in the dotted-decimal format. It cannot be a hostname. There is no default value. Therefore, if it is not provided, statistics are not sent from the client to the proxy. An exemplary value is Address=192.168.14.206.

In this exemplary embodiment, Port defines the port on which the application server110servicing requests and the default value is 89.

In this exemplary embodiment, to disable the gathering and transmission of stats, set the following variables to 0: SFMaxMemSize and StatsMaxBufferSize.

Statistics Gathering

One exemplary embodiment is a method of formatting, collecting, and providing a presentation of statistics that are gathered from user interaction. Some areas in which statistics are gathered include: NavShell use, web browsing, TV viewing, TVTicker, μ Browser, ETV, and Games. In this exemplary embodiment, the default configuration sets the user identification field to anonymous. There is, however, a configuration option that allows the client102(e.g., the set-top box) to include the actual user name. The duration and exit time of all applications, including games and enhanced TV (ETV) are collected. The duration and exit time of menus displayed by the NavShell menu display. The duration and exit time of ETV icon display events are collected. The manual selection of a category view that lasts for at least five seconds for TVTicker is collected. The category selected to view a complete story and the length of time that a story is viewed is collected. For μ Browser, the URL and the duration at the URL is collected.

One exemplary embodiment is an S&F system100that supports multiple applications within an extensible network108to direct information of various formats to any of multiple destinations, including a client application120resident at a client102location for storing non-priority data and for sending said data to any one or more application servers110on the network108at some future time and a server-side proxy server process106. In one embodiment of the S&F system100, the client application120allows any of sending usage statistics to a database308on the network108and enabling T-commerce purchases to be made by a user, where purchase and other relevant information is sent to a destination server110.

Another exemplary embodiment is an S&F system100that includes a client module116, an S&F proxy106, and a server110. The client module116resides on a digital terminal102for facilitating the gathering of user events from different applications, and for sending the user events to a store and forward proxy106in a message batch. The S&F proxy106includes a server-side construct for facilitating upstream communication for the digital terminal102. The S&F proxy106converts user event data received by the S&F proxy106to a standardized format and sends the converted data to a server110. The server110facilitates communications from both the client102and a fetcher112. The server110breaks down received information into single events and saves them in a file114when contacted by the S&F proxy106. The fetcher112collects data from at least one server110and saves the data to a central log file114.

In one embodiment, the system also includes a data bridge for importing the fetcher central log file114into a database308.

In one embodiment, the client module116includes a configuration file.

In one embodiment, the configuration file includes any of the following variables: SFProxyAddress, SFProxyPort, SFschedDelay, SFMaxConcMsgs, SFMaxMemSize, SFBlackoutSchedule, StatsAnonymous, StatsMaxBufferSize, StatsBufferSize, StatsFlushTime, address, and port. SFProxyAddress defines an IP address of the S&F proxy106. SFProxyPort defines a port on which the S&F proxy106provides store and forward service. SFschedDelay is used in calculating a time at which an up stream message is sent. An upstream message is sent at a random time between blackout periods and SFSchedDelay determines a window of time within which a random value is chosen. SFMaxConcMsgs defines a maximum number of store and forward messages held in memory. SFMaxMemSize is a maximum amount of memory that the S&F system100can use when storing messages. SFBlackoutSchedule defines a time when the client module116is not allowed to send upstream messages to the S&F proxy106and includes a list of start-time and end-time combinations. StatsAnonymous specifies whether or not statistics gathered are anonymous. StatsMaxBufferSize specifies an amount of store and forward memory that can be used for statistics. Once a limit is reached and a new statistic is recorded, pending statistics are cancelled, starting with an oldest. StatsBufferSize specifies an amount of statistics data that is buffered before it is sent to a statistics server. StatsFlushTime specifies an amount of time statistics are buffered before they are flushed. Address specifies an address of a statistics server. Port defines a port on which a server is servicing requests.

In one embodiment of the system100, the S&F proxy106facilitates communication between the client module116and the application server110as follows. The client module116sends data to the S&F proxy106. The S&F proxy106then transfers the data from to the application server110from memory. The S&F proxy106then sends a result message to the client module116to inform it that the data was sent to the application server110so that the client module116may purge at least a majority of a transaction from client memory. In the event that initial data does not reach the S&&F proxy106or the S&F proxy106goes down between a time the data are received and the data are sent to the application server110, a result message is not sent and the client module116assumes that the data did not reach the S&F proxy106, thereby causing a retransmit of the data.

In one embodiment of the S&F system100, the S&F proxy106facilitates communication between the client module116and the application server110when the application server110cannot be contacted within a prescribed period of time as follows. The client module116sends data to the S&F proxy106. The S&F proxy106then attempts to transfer the data to the application server110from memory. After a predetermined interval, the S&F proxy106assumes the application server110is down and writes a transaction to a database308. The S&F proxy106then sends a result message to the client module116to inform it that data was written to the database308, so that the client module116knows a packet was received and does not require a retransmit. The S&F proxy106sends the data to the application server110at a later date and the S&F proxy106then sends a result message to the client module116so that the client module116may purge at least a majority of a transaction from client memory.

In one embodiment of the S&F system100, the client module116further includes a buffer for gathering statistics as events are triggered by user interaction. In one embodiment, the client module buffer is filled and additional statistics are generated. Before current statistics are removed, the oldest statistics are removed to create space. In one embodiment, when an upstream statistic transmission is triggered, a single, or group of statistics is sent to the S&F proxy106in a single upstream packet. In one embodiment, once an acknowledgement is received from the S&F proxy106, the client module116assumes a statistic was successfully sent and removes it from memory.

Another embodiment is a method for performing a store and forward transaction. At a client102, an applet is used to create an instance of a StoreAndForward object. The required data is filled in and a send method is invoked. A request is stored in non-volatile memory to guard against power outages. At some point in time, a copy of the request is sent to an S&F proxy106, while keeping an original in non-volatile memory. At the S&F proxy106, the message is received from the client102and a copy is stored in a database308to prevent data loss. An acknowledgement is sent back to the client102telling the client102that it has successfully received the data. The S&F proxy106attempts to deliver the data to an application server110that is specified in the data. The client receives the acknowledgement and then removes a payload part of a transaction from non-volatile memory, because the S&F proxy106has the payload. The client102keeps some information about the transaction in non-volatile memory, until the transaction is completed. The S&F proxy106attempts to contact the application server110at an address and port given in the request data via a protocol that the client102requested. The S&F proxy106continues to try to send the data up to a number of request attempts given in the request or until a time limit to send the data is expired. The S&F proxy106creates a transaction status message with the final result and stores this message in the database308. The S&F proxy106sends the message back to the client102and waits for a done message from the client102. When the client102receives the transaction result, the client102can notify an original applet, if the applet is still running. The client102sends a transaction status message to the S&F proxy106indicating that said transaction is done. When the S&F proxy106receives the done status message from the client102, the S&F proxy106purges all records of the transaction from the database308.

Another embodiment is an S&F system100that includes a client application120, a server-side proxy server process, a store and forward protocol header, and means for setting at least one flag. The client application120is resident at a client102location for storing data and for sending the data to any one or more servers110on a network108at some future time. A store and forward header is sent at the start of every message both from the client102to the S&F proxy106and from the S&F proxy106down to the client102.

In one embodiment, the at least one flag is any of the following flags: SEND_DATA_ACK, SEND_RESULT, and SEND_DONE. The SEND_DATA_ACK flag indicates that the client102wants the S&F proxy106to send an acknowledgement that the S&F proxy106received the client's102request successfully and the client102keeps retransmitting the request, until an acknowledgement is received. The SEND_RESULT flag indicates that the client102wants to have a result of a transaction sent back to it when the transaction has either completed successfully, failed, or a lifetime has expired before the transaction could be completed. The SEND_DONE flag indicates that the client102sends a TRANSACTION_DONE message to the S&F proxy106after it receives a transaction result. Setting this flag allows the S&F proxy106to know when the client102is done with the transaction so that it can purge all data associated with the transaction.

In one embodiment, the store and forward header includes any of the following fields: a client MAC address and one or more flags. The client MAC address is an identifier for a client appliance. The Flags indicate any of the following: a message type, a flag, and a transport protocol, a transaction ID, and a data request message. The transaction ID uniquely identifies a transaction from a particular client.

In one embodiment, the data request message is included after a common data header and includes any of the following: a transaction expiry, a send expiry, a destination address, a destination port number, a number of retransmits, and one or more optional flags. The transaction expiry set a time by which a transaction must complete. The send expiry sets a time the S&F proxy106has to send data to an application server110. The destination address is the address of an application server to which to send the data. The destination port number is the port on an application server to which to send the data. The number of retransmits sets a maximum number of times the S&F proxy106attempts to send the data to an application server. The optional flags are set by the client102and can specify additional options for a request.

In one embodiment, the S&F system100also includes a transaction status message appended after a common data header. The transaction status message is sent by the S&F proxy106to the client102as an acknowledgement and to send a result of a transaction. The transaction status message is sent from the client102to the S&F proxy106to indicate that the client has finished with a transaction. The transaction status message includes any of the following: a result and a state. The result is a last known result of a request and can include any of the following results: INVALID, INPROGRESS, SUCCEEDED, FAILED, TIMEDOUT, CANCELLED, or TOO_MANY_TRIES. If a result is INPROGRESS, then the state is a current state of a transaction, and can include any of the following: DATA_RCVD, DATA_ACKED, SENDING_DATA, and SENT_DATA.

Another embodiment is a store and forward system100that allows for varying levels of reliability. This system includes a client102an S&F proxy106and a plurality of messages passed from the client102to the S&F proxy106and from the S&F proxy106to the client102. The client102can specify a level of messaging required by setting flags in each request message to the S&F proxy106. The flags can be set individually or in combination.

In one embodiment, a flag tells the S&F proxy106whether or not to send the client102an acknowledgement, when the S&F proxy106has received a client's102request. The flag lets the client102know that it is safe to purge a request data from memory.

In one embodiment, a flag tells the S&F proxy106whether or not the client102wants to be informed of a result of a request. Low-priority requests may not require a result to be sent back to the client102.

In one embodiment, a flag tells the S&F proxy106whether or not to hold a result of a request, until the client102sends the S&F proxy106a message acknowledging receipt of the request result. The S&F proxy106holds onto a request and a result, until the client102indicates that it has successfully received the result.