Store and forward architecture

• US 20030212739A1
• Filed: 05/09/2002
• Published: 11/13/2003
• Est. Priority Date: 05/09/2002
• Status: Abandoned Application

• Current Assignee: TVWorks LLC (Comcast Corporation)
• Original Assignee: TVWorks LLC (Comcast Corporation)
• Inventors: Boucher, Antoine, Gunaratnam, Vasanthan, Coumans, Peter, Scheyen, Peter, Elphick, Brent, Lodberg, Allan
• Application Number:
  US10/142,553
• Publication Number:
  US 20030212739A1
• Time in Patent Office: Days
• US Class Current: 709/203
• CPC Class Codes: H04L 67/61 taking into account QoS or priority requirements
• CPC Class Codes: H04L 67/62 Establishing a time schedule for servicing the requests
• CPC Class Codes: H04L 69/329 in the application layer [OSI layer 7]
• CPC Class Codes: H04L 9/40 Network security protocols

Abstract

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.

Claims

1. A store and forward (S&

F) system that supports multiple applications within an extensible network to direct information of various formats to any of multiple destinations, comprising;

a client application resident at a client location for storing non-priority data and for sending said data to any one or more servers on said network at some future time; and

a server-side proxy server process.

2. The system of claim 1, wherein said client application allows any of sending usage statistics to a database on said network;

and enabling T-commerce purchases to be made by a user, where purchase and other relevant information is sent to a destination server.

3. A store and forward (S&

F) system, comprising;

a client module resides on a digital terminal for facilitating gathering of user events from different applications, and for sending said user events to a store and forward proxy in batch;

a store and forward proxy comprising a server-side construct for facilitating upstream communication for said digital terminal;

for converting user event data received by said proxy to a standardized format; and

for sending said converted data to a server;

a server for facilitating communications from both said client and a fetcher, wherein said server breaks down received information into single events and saves them in a file when contacted by said store and forward proxy; and

a fetcher for collecting data from at least one server and saving said data to a central log file.

4. The system of claim 3, further comprising:

a data bridge for importing said fetcher central log file into a database.

5. The system of claim 3, said client module further comprising:

a configuration file.

6. The system of claim 5, said configuration file comprising any of the following variables:

SFProxyAddress which defines an IP address of said store and forward proxy;

SFProxyPort which defines a port on which said store and forward proxy server is providing store and forward service;

SFschedDelay which is used in calculating a time at which an up stream message is sent, wherein an upstream message is sent at a random time between blackout periods, and wherein SFSchedDelay determines a window of time within which a random value is chosen;

SFMaxConcMsgs which defines a maximum number of store and forward messages held in memory;

.

SFMaxMemSize which is a maximum amount of memory that said store and forward system can use when storing messages;

SFBlackoutSchedule which defines a time when said client module is not allowed to send upstream messages to said store and forward proxy, and which consists of a list of start-time end-time combinations;

SFBlackoutSchedule;

StatsAnonymous which specifies whether or not statistics gathered are anonymous;

StatsMaxBufferSize which specifies an amount of store and forward memory that can be used for statistics, wherein once a limit is reached and a new statistic is recorded, pending statistics are cancelled, starting with an oldest;

StatsBufferSize which specifies an amount of statistics data that is buffered before it is sent to a statistics server;

StatsFlushTime which specifies an amount of time statistics are buffered before they are flushed;

Address which specifies an address of a statistics server; and

Port which defines a port on which a server is servicing requests.

7. The system of claim 3, wherein said store and forward proxy facilitates communication between said client module and said server as follows:

said client module sends data to said store and forward proxy;

said store and forward proxy then transfers said data from to said server from memory; and

said store and forward proxy then sends a result message to said client module to inform it that said data was sent to said server so that said client module may purge at least a majority of a transaction from client memory.

8. The system of claim 7, wherein in the event that initial data does not reach said store and forward proxy or said store and forward proxy goes down between a time said data are received and said data are sent to said server, a result message is not sent and said client module assumes that said data did not reach said store and forward proxy, thereby causing a retransmit of said data.

9. The system of claim 3, wherein said store and forward proxy facilitates communication between said client module and said server when said server cannot be contacted within a prescribed period of time as follows:

said client module sends data to said store and forward proxy;

said store and forward proxy then attempts to transfer said data to said server from memory;

after a predetermined interval, said store and forward proxy assumes said server is down and writes a transaction to a database;

said store and forward proxy then sends a result message to said client module to inform it that data was written to said database, so that said client module knows a packet was received and does not require a retransmit;

said store and forward proxy sends said data to said server at a later date; and

said store and forward proxy then sends a result message to said client module so that said client module may purge at least a majority of a transaction from client memory.

10. The system of claim 3, said client module further comprising:

a buffer for gathering statistics as events are triggered by user interaction.

11. The system of claim 10, wherein when said client module buffer is filled and additional statistics are generated before current statistics are removed, oldest statistics are removed to create space.

12. The system of claim 10, wherein when an upstream statistic transmission is triggered, a single, or group of statistics is sent to said store and forward proxy in a single upstream packet.

13. The system of claim 10, wherein when once an acknowledgement is received from said store and forward proxy, said client module assumes a statistic was successfully sent and removes it from memory.

14. A method for performing a store and forward transaction, comprising the steps of:

at a client, using an applet for;

creating an instance of a StoreAndForward object;

filling in required data and invoking a send method;

storing a request in non-volatile memory to guard against power outages; and

at some point in time, sending a copy of said request to a proxy server, while keeping an original in non-volatile memory;

at a proxy server;

receiving said message from said client and storing a copy in a database to prevent data loss;

sending an acknowledgement back to said client telling it that it has successfully received said data; and

attempting to deliver said data to an application server specified in said data.

said client;

receiving said acknowledgement and then removing a payload part of a transaction from non-volatile memory because said proxy server has said payload, said client keeping some information about said transaction in non-volatile memory until said transaction is completed;

said proxy;

attempting to contact said application server at an address and port given in said request data via a protocol that said client requested;

continuing to try to send said data up to a number of request attempts given in said request or until a time limit to send said data is expired;

creating a transaction status message with the final result and stores this message in the database.

sending said message back to said client and waiting for a done message from said client.

wherein, when said client receives said transaction result, it can notify an original applet if said applet is still running;

said client;

sending a transaction status message to said proxy indicating that said transaction is done;

where, when said proxy receives said done status message from said client, said proxy purges all records of said transaction from said database.

15. A store and forward system, comprising:

a client application resident at a client location for storing data and for sending said data to any one or more servers on said network at some future time; and

a server-side proxy server process;

a store and forward header that is sent at the start of every message both from said client to said proxy and from said proxy down to said client; and

means for setting at least one flag in said store and forward protocol header.

16. The system of claim 15, wherein said at least one flag comprises any of:

a SEND_DATA_ACK flag which indicates that said client wants said proxy to send an acknowledgement that said proxy received said client'"'"'s request successfully, wherein said client keeps retransmitting said request until an acknowledgement is received;

a SEND_RESULT flag which indicates that said client wants to have a result of a transaction sent back to it when said transaction has either completed successfully, failed, or a lifetime has expired before said transaction could be completed; and

a SEND_DONE flag which indicates that said client sends a transaction_done message to said proxy after it receives a transaction result, wherein setting this flag allows said proxy to know when said client is done with said transaction so that it can purge all data associated with said transaction.

17. The system of claim 15, wherein said store and forward header comprises any of:

a Client MAC address which is an identifier for a client appliance;

one or more Flags which indicate any of a message type, a flag, and a transport protocol;

a Transaction ID that uniquely identifies a transaction from a particular client; and

a Data Request Message.

18. The system of claim 17, wherein said data request message is included after a common data header and comprises any of:

a Transaction Expiry which set a time by which a transaction must complete;

a Send Expiry which sets a time said proxy server has to send data to an application server;

a Destination address of an application server to which to send said data;

a Destination Port number on an application server to which to send said data;

a Number of Retransmits which sets a maximum number of times said proxy should attempt to send said data to an application server; and

one or more optional Flags by said client can specify additional options for a request.

19. The system of claim 15, further comprising:

a transaction status message appended after a common data header, which is sent by said proxy to said client as an acknowledgement and to send a result of a transaction; and

which is sent from said client to said proxy to indicate that said client has finished with a transaction;

wherein said transaction status message comprises any of;

a Result which is a last known result of a request, and which can comprise any of INVALID, INPROGRESS, SUCCEEDED, FAILED, TIMEDOUT, CANCELLED, or TOO_MANY_TRIES; and

a State wherein, if a Result is INPROGRESS, then this field is a current state of a transaction, and which can comprise any of DATA_RCVD, DATA_ACKED, SENDING_DATA, SENT_DATA.

21. The system of claim 19, comprising:

a flag that tells said proxy whether or not to send said client an acknowledgement when it has received a client'"'"'s request, wherein said flag lets said client know that it is safe to purge a request data from memory.

22. The system of claim 19, comprising:

a flag that tells said proxy whether or not said client wants to be informed of a result of a request, wherein low-priority requests may not require a result to be sent back to said client.

23. The system of claim 19, comprising:

a flag that tells said proxy whether or not to hold a result of a request until said client sends the proxy a message acknowledging receipt of said request result, wherein said proxy holds onto a request and a result until said client indicates that it has successfully received said result.

20. A store and forward system that allows for varying levels of reliability, comprising:

a client;

a proxy; and

a plurality of messages passed from said client to said proxy and from said proxy to said client;

wherein said client can specify a level of messaging required by setting flags in each request message to said proxy, wherein said flags can be set individually or in combination.