US007577703B2
`
`(12)
`
`United States Patent
`Boucher et al.
`
`(10) Patent No.:
`(45) Date of Patent:
`
`US 7,577,703 B2
`Aug. 18, 2009
`
`(54) STORE AND FORWARD ARCHITECTURE
`
`(75) Inventors: Antoine Boucher, London (CA); Peter
`Coumans, London (CA); Peter
`s
`Shetly Sh E. Eglish
`OCO
`Yanna unaratnam,
`iro (CA); Allan Lodberg, London
`
`(73) Assignee. TVWorks, LLC, Philadelphia, PA (US)
`(*) Notice:
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 115 days.
`
`6,622,925 B2 * 9/2003 Carner et al. ............. 236,46R
`6,704,768 B1* 3/2004 Zombek et al. ...
`... 709,201
`2002fOO19848 A1* 2, 2002 Sugawara et al. .
`... 709,206
`2002/0052968 A1* 5/2002 Bonefas et al. .............. 709/231
`2002/0147645 A1 * 10, 2002 Alao et al. .................... TO5/14
`2002/0152299 A1 * 10, 2002 Traversat et al. ............ 709,223
`2002/0169885 A1* 11/2002 Alao et al. ........
`... 709/230
`2003/0172181 A1* 9, 2003 Sharma ...................... TO9,238
`OTHER PUBLICATIONS
`Qayyum H. Using IVDS and VBI for Interactive Television, Con
`Sumer Electronic, IEEE Transactions on vol. 42, issue 3, Aug. 1996,
`pp. 657-666.*
`Sermersheim, J. Lightweight Directory Access Protocol (v3). Jan.
`2001.*
`
`(21) Appl. No.: 11/318,892
`
`22) Filed:
`(22) File
`(65)
`
`Dec. 27, 2005
`eC. Af
`Prior Publication Data
`US 2006/O1 O1153 A1
`May 11, 2006
`
`* cited by examiner
`Primary Examiner—Andrew Caldwell
`y
`Assistant Examiner—John M MacIlwinen
`(74) Attorney, Agent, or Firm Banner & Witcoff
`(57)
`ABSTRACT
`
`Related U.S. Application Data
`(63) Continuation of application No. 10/142.553, filed on
`May 9, 2002, now abandoned.
`s
`s
`(51) Int. Cl.
`(2006.01)
`G6F 5/6
`709/203: 725768: 72.5/110
`(52) U.S. Cl
`(58) Field O f Classification search
`s
`709f2O3
`709/230.72 5/68. 11 o
`See application file for complete search histo
`s
`ry.
`pp
`p
`References Cited
`U.S. PATENT DOCUMENTS
`6,327.625 B1* 12/2001 Wang et al. ................. 709,235
`6,529,932 B1* 3/2003 Dadiomov et al. .......... T18, 101
`
`(56)
`
`A store and forward (S&F) architecture is provided that sup
`ports multiple applications within an extensible network tO
`direct information of various formats to any of multiple des
`tinations. In the presently preferred embodiment of the inven
`tion, 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 des
`tination web server as if the purchase had taken place on the
`web via a full web browser on an Internet-connected PC.
`
`21 Claims, 11 Drawing Sheets
`
`Return Result to
`App through S&F Object
`-84
`
`Purge Stored
`Messages
`
`Create and prepare-802
`S&F OBJEC
`804
`CALLS&FAP
`-806
`Store message in
`NWRAN
`f
`Send copy of misgs
`to Proxy
`
`838
`818
`Terminate Retries | Rese Result
`816
`Receive ACK
`814
`
`- 820
`Sendmessage to
`8stination
`r
`822
`Y
`<i> Send ACK
`message - 82
`
`Ss.Rest
`Client
`
`838
`
`
`
`icopy to database - 824
`
`Retry Send to
`3ESTINATION
`
`--826
`
`CLIENT
`102
`
`846
`
`Y-846
`Send DONE
`
`I
`I
`
`S&F
`Roxy
`tO6
`
`844
`Wait for ONE
`message or timeout
`-850
`Purge Transaction
`
`EX1068
`Roku V. Media Chain
`U.S. Patent No. 9,715,581
`
`

`

`U.S. Patent
`
`Aug. 18, 2009
`
`Sheet 1 of 11
`
`US 7,577,703 B2
`
`100
`
`
`
`
`
`
`
`
`
`
`
`
`
`CLIENT
`
`
`
`CABLE SIGNALS
`
`RF DISTRIBUTION
`NETWORK
`
`CLIENT
`
`
`
`102
`
`104
`
`S&F PROXY
`
`
`
`106
`
`FORWARD
`
`108
`
`110
`
`112
`
`114
`
`
`
`
`
`
`
`APPLICATION
`SERVER
`
`
`
`DATA
`
`FETCHER
`
`
`
`DATA
`
`REPORT
`
`FIG. 1A
`
`

`

`U.S. Patent
`
`Aug. 18, 2009
`
`Sheet 2 of 11
`
`US 7,577,703 B2
`
`
`
`CLIENT
`
`102
`
`CLIENT SOFTWARE
`116
`
`CLIENT APPLICATION
`120
`
`STATS API 122
`
`S8F AP
`
`124
`
`UVM NATIVE S&F LAYER
`126
`
`OPERATING SYSTEM
`118
`
`FIG. 1B
`
`

`

`U.S. Patent
`
`Aug. 18, 2009
`
`Sheet 3 of 11
`
`US 7,577,703 B2
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`200
`
`110
`APPLICATION
`SERVER
`
`
`
`102
`
`
`
`CLIENT
`
`202
`
`
`
`
`
`
`
`RESULT MESSAGE
`
`FIG. 2
`
`102
`
`CLIENT
`
`
`
`APPLICATION
`SERVER
`
`DATA (UNSUCCESSFUL)
`
`FIG. 3A
`
`

`

`U.S. Patent
`
`Aug. 18, 2009
`
`Sheet 4 of 11
`
`US 7,577,703 B2
`
`
`
`
`
`
`
`
`
`
`
`
`
`102
`
`CLIENT
`
`300
`
`11
`APPLICATION
`SERVER
`
`FIG. 3B
`
`102
`
`CLIENT
`
`
`
`
`
`
`
`
`
`RESULT MESSAGE
`
`APPLICATION
`SERVER
`
`(AFTER DELAY) DATA
`
`FIG. 3C
`
`

`

`U.S. Patent
`
`Aug. 18, 2009
`
`Sheet 5 of 11
`
`US 7,577,703 B2
`
`
`
`
`
`
`
`
`
`102
`
`
`
`
`
`CLENT
`
`
`
`
`
`
`
`DATA (RETRANSMIT)
`
`110
`APPLICATION
`SERVER
`
`DATA (UNSUCCESFUL)
`
`FG. 3D
`
`

`

`U.S. Patent
`
`Aug. 18, 2009
`
`Sheet 6 of 11
`
`US 7,577,703 B2
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`102
`
`CLIENT
`
`11
`APPLICATION
`SERVER
`
`
`
`
`
`DATA SEND MESSAGE
`
`400
`
`FIG. 4A
`
`SEND DATA
`
`402
`
`
`
`11
`APPLICATION
`SERVER
`
`10
`
`CLIENT
`
`
`
`
`
`
`
`
`
`DATA SEND MESSAGE
`400
`TRANSSTATUS MESSAGE
`WITH DATAACK
`
`FIG. 4B
`
`102
`
`CLIENT
`
`11
`APPLICATION
`SERVER
`
`
`
`
`
`
`
`
`
`
`
`DATA SEND MESSAGE
`
`400
`TRANSSTATUS MESSAGE
`WITH DATAACK
`
`SEND DATA
`
`402
`RESPONSE IF HTTP
`TN406
`
`
`
`FIG. 4C
`
`

`

`U.S. Patent
`
`Aug. 18, 2009
`
`Sheet 7 of 11
`
`US 7,577,703 B2
`
`400
`
`110
`APPLICATION
`SERVER
`
`
`
`
`
`
`
`102
`
`
`
`CLIENT
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`DATA SEND MESSAGE
`
`404
`
`TRANSSTATUS MESSAGE
`WITH DATAACK
`
`SEND DATA
`
`ADDRESULT IF REQUEST
`COMPLETED
`
`410
`
`TRANSSTATUS WITH DONE
`
`FIG. 4D
`
`

`

`U.S. Patent
`
`Aug. 18, 2009
`
`Sheet 8 of 11
`
`US 7,577,703 B2
`
`402
`
`110
`APPLICATION
`SERVER
`
`SEND DATA (UNSUCCESSFUL)
`414
`
`SEND DATA (RETRY)
`(TIME OUT)
`N418
`
`
`
`102
`CLIENT
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`DATA SEND MESSAGE
`
`412
`
`
`
`TRANSSTATUS MESSAGE
`WITH RESULT SENT REQUEST
`DD NOT COMPLETE IN
`ALLOWED TIME INTERVAL
`
`
`
`420
`
`TRANSSTATUS MESSAGE
`WITH DONE
`
`FIG. 4E
`
`

`

`U.S. Patent
`
`Aug. 18, 2009
`
`Sheet 9 of 11
`
`US 7,577,703 B2
`
`
`
`502
`
`504
`
`506
`
`CLIENTMAC
`
`FLAGS
`
`TRANSACTION ID
`
`500
`
`
`
`BITS: 1
`
`MSGTYPE
`
`8
`6 7
`3 4
`FLAGS PROTOCOL.
`
`508
`FIG. 5
`
`510
`
`512
`
`600
`
`- - -
`
`-
`
`-
`
`-
`
`2
`- -am m r
`-
`2 -- ("------4
`DESTINATION IP(4Bytes)
`DESTINATION PORT
`SENDEXPIRY (MINUTES)
`V 604
`606
`
`FIG. 6
`
`700
`
`1
`
`2
`
`4
`
`RESULT
`
`STATE
`
`PADDING
`
`702
`
`704
`
`706
`
`FIG. 7
`
`

`

`U.S. Patent
`
`Aug. 18, 2009
`
`Sheet 10 of 11
`
`US 7,577,703 B2
`
`
`
`Create and prepare
`S&F Object
`
`Return Result to
`App through S&F Object
`
`CLIENT
`102
`
`Purge Stored
`
`St
`Ore message in
`NVRAM
`
`818
`Terminate Retries
`
`838
`Receive Result
`
`814
`
`12
`
`Retry Limits
`Exceeded?
`
`

`

`U.S. Patent
`
`Aug. 18, 2009
`
`Sheet 11 of 11
`
`US 7,577,703 B2
`
`
`
`
`
`Return Result to
`App through S&F Object
`840
`
`CLIENT
`102
`
`
`
`
`
`Purge Stored
`Messages
`
`818
`y
`Terminate Retries
`816
`Receive ACK
`
`814
`
`838
`Receive Result
`
`846
`
`846
`
`Send DONE
`
`836
`Send Result to
`Client
`
`Create and prepare
`S&F OBJECT
`804
`
`CALL S&F API
`
`806
`St
`Ore message in
`NVRAM
`
`808
`Send Copy of msg(s)
`to Proxy
`
`
`
`
`
`
`
`
`
`
`
`Send message to
`Destination
`
`
`
`
`
`830
`
`Retry Limits
`ExCeeded?
`
`
`
`

`

`US 7,577,703 B2
`
`1.
`STORE AND FORWARD ARCHITECTURE
`
`CROSS REFERENCE TO RELATED
`APPLICATIONS
`
`This application is a continuation of U.S. patent applica
`tion Ser. No. 10/142,553, filed May, 9, 2002 now abandoned.
`
`BACKGROUND OF THE INVENTION
`
`10
`
`2
`It would be advantageous to provide a store and forward
`system that Supported multiple applications within an exten
`sible 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 informa
`tion 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 telecommu
`nications 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 data
`base 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 destina
`tion 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, communi
`cations networks, and a server-side Application server pro
`cess. 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).
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`FIG. 1A is a block schematic diagram that shows an exem
`plary embodiment of a store and forward logical architecture
`and data flow, according to the invention;
`FIG.1B is a block schematic diagram showing the client of
`FIG. 1A in more detail;
`FIG. 2 is a flow diagram showing an exemplary embodi
`ment of a method of providing communication sessions
`between the client and the application server via the S&F
`proxy:
`FIGS. 3A-3D are flow diagrams showing an exemplary
`embodiment of a method of providing communication ses
`S1OnS,
`FIG. 4A is a flow diagram showing the messages that are
`exchanged when no flags are set, in an exemplary embodi
`ment;
`FIG. 4B is a flow diagram showing the messages that are
`exchanged when the SEND DATA ACK flag is set, in an
`exemplary embodiment;
`FIG. 4C is a flow diagram showing the messages that are
`exchanged when the SEND RESULT flag is set, in an exem
`plary embodiment;
`FIG. 4D is a flow diagram showing the messages that are
`exchanged with the DATA ACK, SEND RESULT, and
`SEND DONE flags are set, in an exemplary embodiment;
`FIG. 4E is a flow diagram showing the messages that are
`exchanged with the DATA ACK, SEND RESULT, and
`SEND DONE flags are set when the send is unsuccessful and
`times out after retrying, in an exemplary embodiment;
`
`1. Technical Field
`The invention generally relates to communications sys
`tems. 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 com
`munications systems in which messages are received at inter
`mediate 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 communi
`cation 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 shop
`ping). Further, Such known systems operate within the con
`fines 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 param
`eters 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 informa
`tion formats or protocols handled well within such known
`systems.
`
`15
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`

`

`US 7,577,703 B2
`
`3
`FIG. 5 is a block schematic diagram that shows an exem
`plary embodiment of a header that is sent at the start of every
`message, both from the client to the proxy and from the proxy
`down to the client, according to the invention;
`FIG. 6 is a block schematic diagram that shows an exem
`plary embodiment of a data request message that is included
`after the common data header, according to the invention;
`FIG. 7 is a block schematic diagram that shows an exem
`plary embodiment of a message that is sent by the proxy to the
`client for the purposes of an acknowledgement and to send the
`result of the transaction;
`FIG. 8 is a block schematic diagram that shows an exem
`plary embodiment of a method of implementing a no delayed
`acknowledgement (ACK) scheme; and
`FIG. 9 is a block schematic diagram that shows an exem
`plary embodiment 900 of a method of implementing a
`delayed acknowledgement (ACK) scheme.
`
`10
`
`15
`
`4
`In this exemplary embodiment, the stats API 122 is middle
`ware that resides on the client 102. It facilitates the gathering
`ofuser events from client applications 120 on different clients
`102. For example, when a user starts an application from the
`main navigation screen (NavShell), the stats API 122 records
`the time and the application that was started. The stats API
`122 then uses the S&F API 124 to send the statistics data to the
`S&F proxy 106 and ultimately to an application server 110 to
`collect usage statistics.
`In this exemplary embodiment, the stats API 122 provides
`to the S&F API 124 the IP address and port number of the
`application server 110 to which the statistics data is sent to the
`S&F API 124. In one embodiment, the client software 116 can
`be configured with default values for the application server
`110.
`In one embodiment, each client 102 can be configured to
`send statistics without identifying the sender. This allows
`statistics to be collected anonymously, which protects indi
`vidual subscribers privacy. In addition, the client 102 can 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 API 124 is used by the stats
`API 122, but the S&F API 124 can also be used by the client
`application 120 directly. The S&F API 124 allows the user to
`specify several attributes that affect how, when and where the
`data is sent. The user of the S&F API 124 is required to
`provide the IP address and port number of the application
`server 110 that receives the data. The user also provides the
`transmission protocol that the S&F proxy 106 uses to send the
`data to the application server 110. Internet protocols are Sup
`ported, e.g., UDP, transmission control protocol (TCP) and
`hypertext transfer protocol (HTTP). When the S&F API 124
`receives a request to send, the data and all optional and
`required parameters are passed to the UVM native S&F layer
`126.
`In one embodiment, the S&F API 124 allows 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 proxy 106.
`In one embodiment, when the UVM native S&F layer 126
`receives data to send, it formats a message that contains the
`address of the application server 110 as well as the data. For
`more information about the structure of the message, see
`FIGS. 5 and 6.
`In one embodiment, the UVM native S&F layer 126 stores
`data in non-volatile read-only memory (NVRAM) to ensure
`that the data will be saved if the power is lost. In one embodi
`ment, the S&F proxy 106 can be configured to not send S&F
`data during certain times of the day, called blackout periods.
`These blackout periods are used when the client 102 is 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 client 102 to the S&F proxy 106 and stored in a
`database.
`One exemplary embodiment is a scheduling algorithm that
`includes transaction lifetime, initial send delay, and the black
`out schedule. In order to avoid having all the clients 102 on 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 client 102 is 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 proxy 106 to send to.
`
`DETAILED DESCRIPTION OF THE INVENTION
`
`25
`
`30
`
`35
`
`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 informa
`tion 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 net
`work such as the Internet, at sometime 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 appli
`cation 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
`40
`FIG. 1A is a block schematic diagram showing an exem
`plary embodiment 100 of a store and forward logical archi
`tecture and data flow, according to the invention. In this
`exemplary embodiment 100, a client 102 (e.g., a set top box
`(STB)) sends cable signals to an RF distribution network 104.
`The RF distribution network 104 sends client messages, (e.g.,
`user datagram protocol (UDP) messages) to an S&F proxy
`106 at a headend. The S&F proxy 106 sends forwarded mes
`sages (e.g., UDP, TCP/IP or HTTP messages) to an IP net
`work 108. The IP network 108 sends data to an application
`server 110. The application server 110 sends data to a fetcher
`112 to further process messages. The fetcher 112 uses the data
`to generate a report 114. While only one client 102 and
`application server 110 are shown in FIG. 1A, this exemplary
`embodiment may include any number of clients 102, and/or
`application servers 110.
`FIG. 1B is a block schematic diagram showing the client
`102 of FIG. 1A in more detail. The client 102 includes client
`software 116 and an operating system 118. The client soft
`ware 116 includes a client application 120, a statistics (stats)
`application program interface (API) 122, an S&F API 124,
`and a UVM native S&F layer 126.
`In this exemplary embodiment, the client application 120 is
`a Java applet running on the client 102. The client application
`120 uses the services provided by the stats API 122 and the
`S&F API 124 to send statistics or application-specific data to
`the application server 110.
`
`50
`
`45
`
`55
`
`60
`
`65
`
`

`

`US 7,577,703 B2
`
`10
`
`15
`
`5
`The operating system 118 provides access for sending and
`receiving data over the RF Distribution Network 104.
`In one embodiment, the RF Distribution Network 104 is a
`two-way real-time RF network. Data delivery over this net
`work is unreliable. One exemplary embodiment of the S&F
`system implements additional levels of reliability. The S&F
`API 124 allows a caller to determine which level of reliability
`is required.
`In one embodiment, the S&F proxy 106 is a server-side
`process that facilitates upstream communication for the client
`102 via an NC1500, which is an upstream communications
`router (manufactured by Motorola). It is specifically used for
`delivering messages sent by clients 102 (via the RF distribu
`tion network 104) to a headend communications network (not
`shown). When user event data is received by the S&F proxy
`106, the S&F proxy 106 tries to deliver the data to the appli
`cation server 110 specified in the data, via UDP, TCP or HTTP
`as specified in the data. The S&F proxy 106 can send data to
`any of a number of application servers that are reachable via
`the IP network 108. The S&F proxy 106 sends data to the
`application server 110 across the IP network 108. The S&F
`proxy 106 and the application server 110 can communicate
`via any standard Internet Protocols, such as UDP, TCP or
`HTTP
`In one embodiment, the application server 110 is an entity
`connected to the IP network 108that can receive data from the
`client application 120 via at least one of UDP, TCP and HTTP.
`The application server 110 is responsible for parsing and
`processing the data sent by the client application 120. The
`S&F proxy 106 can be used to communicate to any applica
`tion server 110 via the UDP, TCP/IP or HTTP protocols.
`In one embodiment, the S&F API 124 is used by the client
`application 120 to send raw data to a third party server using
`UDP, TCP, or HTTP. In one embodiment, the S&F API 124
`interfaces with the UVM native S&F layer 126, which is part
`of the UVM. In one embodiment, the UVM native S&F layer
`126 stores data either in dynamic RAM or in non-volatile
`memory, until it is received by the S&F proxy 106. 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 proxy 106. The scheduling algorithm
`attempts to minimize data loss in the upstream direction by
`sharing the upstream communications resource across all
`clients 102 so as not to overload the upstream channel. One
`embodiment includes formatting data according to an S&F
`45
`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 client 102 to the S&F proxy 106 and from the S&F proxy
`106 to the client 102. The client 102 can specify the level of
`messaging required by setting flags in each request message
`to the S&F proxy 106.
`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 proxy 106
`whether or not to send the client 102 an acknowledgement
`when it has received the clients request. The purpose of this
`flag is to let the client 102 know that it is safe to purge the
`request data from NVRAM. The second flag (RESULT) tells
`the S&F proxy 106 whether or not the client 102 wants 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 proxy 106 whether or not to hold
`
`55
`
`6
`the result of the request until the client 102 sends the S&F
`proxy 106 a message acknowledging the receipt of the request
`result. This is important if the client 102 must know the result
`of the request. Without this flag, the S&F proxy 106 sends the
`result only once before purging the request. If that message
`gets lost, the client 102 is not able to determine the result.
`With this flag set, the S&F proxy 106 holds onto the request
`and the result until the client 102 indicates that it has success
`fully received the result.
`Delayed Ack
`In this exemplary embodiment, if the ACK flag is set or the
`RESULT flag is set, then the client 102 implements a delayed
`ACK scheme. This means that when the S&F proxy 106
`receives a request, the S&F proxy 106 does not send the
`acknowledgement message right away if the ACK flag is set,
`but tries to complete the transaction first. If the request com
`pletes 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 client
`102. 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 proxy 106 receives a duplicate request, it sends back an
`ACK immediately. A likely reason for the S&F proxy 106 to
`receive a duplicate is because the client 102 never 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 client 102 sends the
`request, but the S&F proxy 106 does not store this in a
`database. The S&F proxy 106 does not send any message to
`the client 102 about this request. The S&F proxy 106 purges
`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 proxy 106
`receives 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 proxy 106 writes this request to the data
`base, if the request cannot be completed immediately. The
`S&F proxy 106 purges 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 proxy 106
`receives this message, the S&F proxy 106 attempts to carry
`out the request. See the discussion of DELAYED ACK for
`more details. The S&F proxy 106 writes this request to the
`database, if the request cannot be completed immediately.
`When the result of the request is known, the S&F proxy 106
`sends the result once to the client 102 and immediately purges
`this request.
`In this exemplary embodiment, for the combination
`{ACK-0, RESULT-0, DONE-1}, which is an invalid combi
`nation, if the S&F proxy 106 receives 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 proxy 106
`receives this message, the S&F proxy 106 attempts to carry
`out the request. See the discussion of DELAYED ACK for
`more details. The S&F proxy 106 writes this request to the
`database, if the request cannot be completed immediately.
`When the result of the request is known, the S&F proxy 106
`sends the result once to the client 102 and immediately purges
`this request.
`
`25
`
`30
`
`35
`
`40
`
`50
`
`60
`
`65
`
`

`

`7
`In this exemplary embodiment, for the combination
`{ACK-1, RESULT-0, DONE-1}, which is an invalid combi
`nation, if the S&F proxy 106 receives 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 proxy 106 pro
`cesses the request immediately, but only writes it to the data
`base, if the request cannot be completed in a certain period of
`time. No ACK is sent to the client 102, once the request has
`been written to the database. Once the result of the request is
`known, the result is sent back to the client 102. The S&F
`proxy 106 does not purge this result until it receives the
`DONE message from the client 102 or until the request expiry
`time elapses.
`In this exemplary embodiment, for the combination
`{ACK-1, RESULT-1, DONE-1}, the S&F proxy 106 pro
`cesses the request immediately, but only writes it to the data
`base, if the request cannot be completed in a certain period of
`time and an ACK is sent to the client 102. Once the result of
`the request is known, the result is sent back to the client 102.
`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 client 102 instead of the ACK. See the DELAYED ACK
`discussion for more details. The S&F proxy 106 does not
`25
`purge this result until it receives the DONE message from the
`client 102 or until the request expiry time elapses.
`Communication Session (Result)
`FIG. 2 shows an exemplary embodiment 200 of a method
`of providing communication sessions between the client 102
`and the application server 110 via the S&F proxy 106. 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 communi
`cation session shown in FIG. 2. At 202, the client 102 sends
`data to the S&F proxy 106. At 204, the S&F proxy 106
`transfers the data from to the application server 110 from
`memory. At 206, the S&F proxy 106 sends a RESULT mes
`sage to the client 102 to informit of the status of the data send
`to the application server 110 So that it may purge the majority
`of the transaction from memory. In the event that the initial
`data does not reach the S&F proxy 106 or the S&F proxy 106
`goes down between the time the data is received and is sent to
`the application server 110, a RESULT message is not sent and
`the client 102 assumes that the data did not reach the S&F
`proxy 106, thereby causing a retransmit from the client.
`FIGS. 3A-3C show an exemplary embodiment 300 of a
`method of providing communication sessions. FIG. 3A
`shows a scenario in which the application server 110 cannot
`be contacted within a prescribed (short) period of time. At
`302, the client 102 sends data to the S&F proxy 106. At 304,
`the S&F proxy 106 then attempts to transfer the data to the
`application server 110 from memory. After a predetermined
`number of seconds the S&F proxy 106 assumes the applica
`tion server 110 is down and, at 306, writes the transaction to
`the database 308. FIG. 3B shows a scenario in which the
`transfer is successful. The S&F proxy 106 sends an ACK
`message, when the S&F proxy 106 has been able to deliver
`the message to the specified final destination. FIG. 3C shows
`a scenario in which the S&F proxy 106 sends the data to the
`application server 110 at a later date. At 314, the S&F proxy
`106 then sends a RESULT message to the client 102 so that it
`may purge the majority of the transaction from NVRAM.
`FIG. 3D shows a scenario in which the initial data does not
`reach the S&F proxy 106 or the S&F proxy 106 goes down
`between the time the data is received and it is sent to the
`application server 110, an ACK message is not sent and the
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`US 7,577,703 B2
`
`5
`
`10
`
`15
`
`8
`client 102 assumes that the data did not reach the S&F proxy
`106 causing a retransmit at 316.
`Store And Forward Summary
`Table C shows pseudo code for an exemplary embodiment
`of a method for providing a