Patent Application
20080061934
The present invention is directed to managing messages submitted by users of electronic devices, and more specifically to managing selections, such as votes, submitted by users and returning replies to users at a high rate and volume in a reliable and scalable manner.
Text messages, multimedia messages, and other messages have become an increasingly popular method of communication, especially with mobile devices such as cellular telephones, personal data assistants (PDAs), and the like. Such messages are generally inexpensive to send and receive relative to some voice communications, and can be communicated to multiple electronic devices at the same time. Messages can be exchanged across a variety of protocols, including those for telephones, email systems, web-based message portals, and other network systems. Some exemplary message protocols include short message service—peer to peer (SMS-PP), multimedia service (MMS), simple network paging protocol (SNPP), simple mail transport protocol (SMTP), post office protocol (POP), wireless content transport protocol (WCTP), hypertext transport protocol (HTTP), and the like.
Messages may also be more efficient to use than voice calls to submit a vote, a purchase choice, or another selection. Selections submitted in many messages can be recorded in a database for further processing. However, conventional databases are relatively slow for processing very large volumes of messages (e.g., 10,000 messages per second). Multi-threaded operation is often used to improve performance over single-threaded operation, but database operations are still relatively slow even with multi-threaded operations. A large volume of messages may be expected from a mass audience in limited time periods, such as during a voting campaign, an advertising campaign, a sweepstakes campaign, and the like. Each submitted message should be accurately accounted without missing any submission, and a reply should be returned on a near-real-time basis to confirm submissions to users. Accuracy, reliability, and fast turn-around are valuable for a successful campaign.
The present invention will now be described with reference to the accompanying drawings, which form a part hereof, and which show, by way of illustration, specific exemplary embodiments by which the invention may be practiced. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Among other things, the present invention may be embodied as methods or devices. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. The following detailed description is, therefore, not to be taken in a limiting sense.
Throughout the specification, the term “connected” means a direct connection between the things that are connected, without any intermediary devices or components. The term “coupled,” or “in communication with” means a direct connection between the things that are connected, or an indirect connection through one or more either passive or active intermediary devices or components. The meaning of “a,” “an,” and “the” include plural references. The meaning of “in” includes “in” and “on.” The term “or” is an inclusive “or” operator, and includes the term “and/or,” unless the context clearly dictates otherwise. The phrase “in one embodiment,” as used herein does not necessarily refer to the same embodiment, although it may. Similarly, the phrase “in another embodiment,” as used herein does not necessarily refer to a different embodiment, although it may. The term “based on” is not exclusive and provides for being based on additional factors not described, unless the context clearly dictates otherwise. The term “user” can include a mobile device user, an online service subscriber, a computer user, and/or other person using an electronic device. The term “message” can include a copy of a message.
Briefly stated, the invention is direct to a method and system for managing selections, such as votes, submitted by users and returning replies to users at a high rate and volume in a reliable and scalable manner. High performance and reliability can be achieved with a single-threaded operation.
The mass memory also includes computer-readable media, such as volatile, nonvolatile, removable, and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. Examples of computer-readable media include RAM, ROM, EEPROM, flash memory, or other memory technology, CD-ROM, digital versatile disks (DVD), or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage, or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by a computing device.
The mass memory also stores program code and data. One or more applications 24 are loaded into mass memory and run on operating system 20. Examples of application programs include database programs, schedulers, transcoders, calendars, web services, word processing programs, spreadsheet programs, email programs, and so forth. Mass storage may further include applications such as a message processing module 26 for managing communication to and from clients.
Server 1 also includes input/output interface 18 for communicating with external devices, such as a mouse, keyboard, scanner, or other input device 19. Server 1 can communicate with a local network, the Internet, a telephone network, or some other communications network via network interface units 30a and 30b, which are constructed for use with various communication protocols including transmission control protocol/Internet protocol (TCP/IP), user datagram protocol (UDP), code division multiple access (CDMA), time division multiple access (TDMA), global system for mobile communications (GSM), Institute for Electrical and Electronics Engineers (IEEE) 802.11, IEEE 802.16 (WiMax), SMS, general packet radio service (GPRS), Wireless Application Protocol (WAP), and the like. Network interface units 30a and 30b are sometimes known as transceivers, transceiving devices, network interface cards (NICs), and the like. The network interface units can facilitate communications between communication carriers and/or computing devices that conform to the same or differing communication protocols. For example, network interface units 30a and 30b are illustrated as communicating with networks 32a and 32b, which may comprise cellular telephone carrier networks, the Internet, and/or other networks. Networks 32a and 32b provide communication services for clients such as clients 40a and 40b.
Carrier 32 is in communication with at least two message processors 1a and 1b. The message processors may be separate servers in different locations that communicate through a wide area network such as the internet. In one alternative, the message processors may be separate software modules running on a single machine. In the event one message processor fails, the other(s) take over processing. One message processor is generally selected as a master message processor 1a. One or more slave message processor(s) 1b run in parallel, and can continue with message processing if the master message processor fails.
Vote messages submitted through carrier 32 are communicated to an inbound transport module of each message processor. In this embodiment, carrier 32 is in communication with inbound transport module 50a of master message processor 1a, and in communication with inbound transport module 50b of slave message processor 1b. Each related set of inbound transport modules, such as inbound transport modules 50a and 50b, may be preconfigured to be associated with a specific short code, so that incoming messages addressed to the specific short code are routed to the corresponding inbound transport modules in the master and slave(s). In addition, or alternatively, the area code, cellular tower identifier, or other identifier can be used to segment the voters and route the incoming messages to predefined inbound transport modules. Thus, master message processor 1a can have a number of master inbound transport modules (e.g., 1, 2, . . . , n) for various segments of traffic. Similarly, slave message processor 1b can have a number of slave inbound transport modules (e.g., 1, 2, . . . , n) for the various segments of traffic.
Mobile device identifiers and/or other message information may also be used by the inbound transport modules to generate a summary code, such as a hash value, to increase the speed of subsequent processing. Each inbound transport module includes, or is in communication with, an inbound log module 52a and 52b, respectively. The inbound log modules store information about incoming vote messages, such as a message identifier, a time stamp, a carrier identifier, a subscriber identifier, and the like. The incoming vote messages are also tagged with a transport identifier to indicate where a reply should be sent.
Each inbound transport module is in communication with a master decision module 54a and at least one slave decision module 54b. The decision modules are preconfigured to access incoming votes from preselected inbound transport modules. Accordingly, a number of decision modules (e.g., 1, 2, . . . , n) correspond to the segments of traffic. On system start-up, the inbound transport modules wait for the decision modules to connect to the inbound transport modules. When decision modules connect to inbound transport modules, the decision modules declare a particular segment of traffic for which the decision modules serve as destinations. For example, a decision module may indicate that it is pre-programmed to process messages from one or more particular area codes. The decision modules also indicate whether the decision modules believe they are the master decision module or a slave decision module for that segment of traffic. Once an inbound transport module has a master decision module for each traffic segment, the inbound transport module connects to the carrier. In this embodiment, a decision module may then access messages from master and slave inbound transport modules that are associated with a predefined hash value, which may result from a predefined area code and/or other traffic segment identifier(s).
In one embodiment, a decision module includes an incoming queue to buffer a number of incoming messages, or summaries of messages, from the inbound transport module. The decision modules evaluate the content of the messages, or summaries of the messages, to determine the vote, registration request, and/or other content of the messages. The decision modules also determine a corresponding reply to send back to the mobile device that submitted the message and/or other action to take. As discussed in further detail below, the action to take is indicated as a change in state associated with the submitting subscriber. A decision module includes an outgoing queue to buffer a number of outgoing reply instructions.
Master decision module 54a is also in communication with slave decision module 54b so that the slave processor(s) will know which messages were processed by the master decision module. If the slave processor(s) determine that the master decision module has not processed one or more messages, one of the slave processors may take over as the master. Each decision module includes, or is in communication with, a decision log module 56a and 56b, respectively. The decision log modules store information about a decision made for corresponding message, such as the message identifier, time stamp, state change, and the like.
Instructions for reply messages are communicated to outbound transport modules. In this embodiment, master decision module 54a is in communication with a master outbound transport module 58a. Similarly, slave decision module 54b is in communication with a slave outbound transport module 58b. A number of outbound transport modules (e.g., 1, 2, . . . , n) can be associated with the various segments of traffic. However, unlike the inbound transport modules, the decision modules do not communicate with both master and slave outbound transport modules. This embodiment presumes that master decision module 54a will instruct its corresponding outbound transport module 58a to send a reply message and confirm to slave decision module 54b that the instruction was sent. In this case, master processing module 1a is functioning properly, so there is no need for slave decision module 54b to send a reply using outbound transport module 58b. Conversely, if master processing module 1a fails, slave decision module 54b will not receive a confirmation from master decision module 54a. In that case, slave decision module 54b instructs its corresponding outbound transport module 58b to send a reply. Since the slave decision module presumes that the master outbound transport module has failed along with the master decision module, there is no need for the slave decision module to instruct the master outbound transport module to send a duplicate reply.
However, those skilled in the art will recognize that other embodiments may use independently controlled outbound transport modules, which may benefit from cross communication between the decision modules and multiple outbound transport modules. In another embodiment, each outbound transport module may be combined with the corresponding inbound transport module for a transceiver module. For instance, the transport mechanism may be implemented with characteristics of an SMPP transceiver bind. Transceiver modules will generally cross communicate with the master and slave decision modules.
The outbound transport modules are in communication with carrier 32 to send replies to corresponding mobile devices that submitted the votes. An outbound transport module generally connects to the carrier as soon as any decision module has connected to the outbound transport module. Each outbound transport module also includes, or is in communication with, an outbound log module 59a and 59b, respectively. The outbound log modules store information about replies made for a corresponding decision, such as the incoming message identifier, state change, outbound reply message identifier, time stamp, and the like.
The architecture described above enables a large volume of incoming messages (e.g., votes) to be recorded and processed reliably and quickly, based on producing a state change associated with the subscribers. A correspondingly large volume of replies are reliably returned to subscribers in near real-time response to their votes. However, there are other administrative operations that are generally needed in processing the messages. These operations include generating billing records, producing system performance reports, and the like. These administrative operations have generally been performed with a database at the time of processing the messages. However, such database operations significantly reduce the speed and volume of message and reply processing. Thus, embodiments of the present invention perform these operations separately from the message and reply processing. Post-processing modules buffer the message processing decisions and perform the administrative operations without slowing the message and reply processing. Accordingly, master decision module 54a is in communication with a master post-processing module 60a. Similarly, slave decision module 54b is in communication with a slave post-processing module 60b. The master post-processing module is also in communication with the slave post-processing module to indicate when the master post-processing module has completed its administrative operations associated with each message and reply. The slave post-processing module takes over the administrative processing if the master post-processing module fails. The post-processing modules may produce paper and/or electronic bills, reports, and/or other administrative data for campaign organizers, subscribers, service managers, advertisers, and the like. Thus, each post-processing module is in communication with an administrative data recipient 64, who may utilize the administrative data.
The master decision module evaluates the summary according to predefined rules of the campaign to update one or more states that are associated with the subscriber that submitted the message. For example, a user state may indicate that the subscriber is not yet registered to vote in the current campaign, that the subscriber is registered to vote, or that the subscriber already voted. A vote state may indicate which selection the subscriber voted for, such as which television performer the subscriber voted for. Other information may include a vote count, indicating the number of times a subscriber voted, a premium flag, indicating a priority level of the subscriber, and other data that the decision module may use to process the summary data. The master decision module also updates the incoming queue to indicate that the current message summary data has been processed.
The master decision module transmits the message summary data and state update data to the slave decision module to notify the slave decision module that the message summary data for a submitted message was processed, and that the slave decision module need not process the message summary data. If the slave decision module did not receive this notification within a predefined period, the slave decision module assumes that the master decision module failed. The slave decision module would then take over as the new master decision module and process the summary data.
The master decision module also transmits the message summary data and state data (decision results) to the master post-processor. The master post-processor relays the summary data and state data to the slave post-processor. The post processors perform their administrative operations using one or more databases, but without further delaying replies to the subscribers.
The master decision module transmits a response to the master outbound transport module. More specifically in this embodiment, the response is provided to the outgoing queue of the decision module for accessing a reply template based on the state values determined, and for delivery to the outgoing transport module that corresponds to the tag provided by the incoming transport module when the incoming message was received. The outgoing queue also ensures that the replies are delivered in priority order, and can retry to send the response if the outgoing transport module does not acknowledge receipt of the response. In this embodiment, the decision module also load-balances outgoing traffic across the available outbound transport modules that can pass traffic to the target carrier. In this embodiment, the decision module sends outgoing traffic to the outbound transport module with the fewest outstanding messages.
The outbound transport module transmits a mobile target (MT) reply to the carrier for delivery to the subscriber's mobile device. The reply includes text such as an indication that the subscriber has not yet registered, a confirmation of the subscriber's vote, an indication that the subscriber has voted too many times, and/or other reply information. The carrier acknowledges the reply to the outbound transport module, which acknowledges delivery of the reply to the master decision module. The master decision module can then update the outgoing queue to remove that reply from the list, as having been delivered. No further retries would be needed. The master decision module also notifies the slave decision module that the reply was delivered, so the slave decision module can remove that reply from the slave outgoing queue. Similarly, the master decision module notifies the master post-processor that the reply was delivered, so that the master post-processor can register a cost to the subscriber or campaign organizer, update campaign statistics, or otherwise perform other administrative processing. The master post-processor notifies the slave post-processor upon completion, so that the slave post-processor may remove the task from its queue.
Further detail is provided below with regard to exemplary logic flow diagrams shown in
At an operation 202, campaign short codes are associated with inbound transports for routing incoming messages. The decision modules are also associated with traffic identification codes, such as area codes, to segment the routing of incoming traffic to decision modules. The decision modules are also pre-assigned as a master decision module or a slave decision module. The campaign data rules are entered into the campaign system at an operation 204. This may comprise entering selection codes available to the subscribers, state change rules, and other campaign data discussed above. The campaign data may be programmed into the system with customized hard code and/or through a user interface that is available to the campaign coordinator. At an operation 206, any existing state data may be loaded for existing subscribers. For example, some subscribers may have participated in a prior campaign and indicated that they wish to participate in any future campaign. The state data and campaign data are generally loaded into memory, such as RAM for faster processing than disk-based databases.
At an operation 214, the inbound transport module tags the message summary with a transport identifier, so that the corresponding reply will be routed back through the outbound transport module that is associated with the inbound transport module. Alternatively, the transport identifier may indicate that the reply should be routed back through the inbound transport module if the inbound transport module is a transceiver module. In one embodiment, the transport identifier may be implemented as a message ID for processing within the campaign system. Transport modules have configuration data that provide bind information, as well as instructions regarding which message stream and carrier IDs to include in the message ID. Message IDs are intended to be unique even if the inbound transport module restarts. One mechanism by which this can be achieved is for the message ID to be 64 bits, with approximately the top 10 bits comprising the stream ID, the next 32 bits initialized on transport element startup to the number of seconds since 1 Jan. 1970, and the remainder initialized on startup to 0. This message ID is then incremented one value for each message handled by the stream. As long as the inbound transport module does not restart twice in the same second, and the stream does not process more than 4.2M messages/second, these IDs will be unique.
The inbound transport module routes the message summary to the associated master decision module and slave decision module(s), at an operation 216. In one embodiment, the inbound transport module does not acknowledge receipt of the message until all associated decision modules have been notified and one decision module has acknowledged receipt of the message summary. If all decision modules that declared themselves as destinations of the traffic segment have dropped their connections, the inbound transport element will save the message on disk, in two locations, to be processed when such a decision module destination is available.
The inbound transport module logs message data at an operation 218. For example, a packet ID, time stamp, message count, and/or other data may be logged. In one embodiment, two categories of count data is maintained by the inbound transport module; (i) messages received and message summaries sent, and (ii) acknowledgements sent or received. Examples include:
On the carrier-side interface, inbound transport modules may maintain the following counts:
At an operation 220, the decision module receives a message summary from the inbound transport module and performs input queuing and/or other pre-processing. The incoming queue may comprise a set of pending bytes that have been read from the network but have not yet been interpreted as messages, logged, or otherwise processed. Thus, the incoming queuing sub-process may have to wait until a full message summary is received. Each message summary from the transport element is generally copied once into memory. Other operations involving that message summary (including logging it to disk and performing decision logic) will generally use the same memory location.
The decision module evaluates the message summary to determine whether the message summary includes any recognized short code, at a decision operation 222. If the message summary does not include a recognized short code, the decision module sets an alarm, logs an error, increments an error count, and/or performs other air processing and an operation 224. The decision module may end further decision processing. Similar error processing may also be performed at other stages of the message processing system. For example the inbound transport module may detect a loss of communication with a decision module, set an alarm, and try to re-establish communication with that decision module, or initiate a transfer of control to a slave decision module as a new master decision module.
If the message summary includes a recognized short code, the decision module loads campaign information at an operation 226. The message summary may comprise a command to load initial campaign information and/or additional campaign information. At an operation 228, the decision module activates time specific campaign information, such as vote selections that may be based on the subscriber's time zone. And the decision operation 230, the decision module determines whether the message summary indicates an override of previous op-in or op-out selections. For example, the subscriber may have previously selected to opt into all campaigns. The received message summary may indicate a new selection to opt out of future campaigns. If the message summary indicates an override of a previous and/or default opt-in or opt-out setting, the decision module or another module processes the message summary at an operation 232 for overriding the setting. If no override is indicated, the decision module accesses one or more rules for processing the subscriber's state, at an operation 234. Overrides may also be applied within the message summary processing described below. The sender's opt-in and -out status can override any part of a rule, including causing different state changes or suppressing any state change, or changing or suppressing any messages (e.g., replies or follow-on replies) generated by the applied rule.
At a decision operation 236, the decision module determines whether a rules set is available and applicable for the short code in the message summary. If a rules set is available for the short code, the decision module accesses the rules set at an operation 238. The decision module then determines, at a decision operation 240, whether a rule is available and applicable for the text of the message. If the text rule is not available and/or applicable to the text, the decision module processes the message summary according to the accessed short code rule, at an operation 242. However, if a text rule is available and or applicable, the decision module processes the message summary according to the text rule, at an operation 244.
If a rules set was not associated with the received short code, the decision module determines, at a decision operation 246, whether a rule is available and/or applicable based only on the text of the message. If a text rule is available and or applicable, the decision module processes the message summary according to the text rule, at an operation 248. However, if a text rule is not available and/or applicable, the decision module processes the message summary according to a campaign default, at an operation 249.
In more detail, one embodiment starts by receiving a message summary at an operation 250. In this example, the decision module determines, at a decision operation 252, whether the message text indicates a request to register to vote in the current campaign. If the text does indicate a request to register, the decision module may optionally determine whether the subscriber has previously registered. If the subscriber has previously registered, the decision module may change a state of the subscriber so that a reply informs the subscriber that the subscriber is already registered. If the subscriber is not yet register, the decision module establishes a new subscriber in memory and sets the subscriber state(s) to default values at an operation 254.
For those subscriber is that are already registered, the decision module evaluates the message summary at a decision operation 256 to determine whether the message text indicates a valid vote or other selection. If the selection is not valid, the decision module returns a reply identifier and/or queues a reply, at an operation 258, indicating that the received message was invalid. The decision module may then log information regarding the non-vote message at an operation 260. The decision module also sends a confirmation to the slave decision modules, confirming that the master decision module completed processing of the message summary.
If the received message summary indicates a valid selection, the decision module may check (or double check) at a decision operation 264 that the subscriber is registered. If the subscriber is not register, the decision module returns a reply at an operation 266, instructing the subscriber to register before the selection can be processed. This transaction is also logged and a confirmation sent to the slave decision modules. If the subscriber is registered, the decision module checks the subscriber's vote counting at a decision operation 270. If the subscriber's vote count is exceeded, the decision module returns a reply ID and an operation 272 for a reply message indicating that the subscriber has voted to many times. Again, the non-vote data is logged and a confirmation is sent to the slave decision modules.
If the subscriber's vote count is not exceeded, the master decision module updates the subscriber's vote state at an operation 274 based on the subscriber's vote. The state change may be by the following relationship:
(Current State)+(Message Text)+(Short Code)=>Reply+(State Change)
The state change may include one or a combination of various required and/or optional states. At an operation 276, the decision module increments the subscriber's vote count.
The decision module returns a reply ID at an operation 278 for of a reply message thanking the subscriber for participating. Follow-on reply may also be scheduled, such as an advertisement, and invitation to another campaign, information about a current leader in the campaign, and/or other information. In one embodiment, each decision module maintains a queue of reply messages bound for subscribers. It is beneficial that reply messages to a subscriber be delivered in order, relative to the messages submitted by the subscriber. To help ensure this sequencing, the outgoing queue may be in two parts. First is a list of mobile directory numbers (MDN)s, maintained in priority order. There may be a literal “retry next” component in the list, as well, to prevent excessive retries in short-queue conditions. Second is the set of reply messages to be sent to each MDN, in time order. The set of queued reply messages for each MDN generally includes a pointer to a reply message template, a pointer to any follow-on messages to be queued upon delivery of this reply message, and any replacement strings whose value is determined at the time the reply message is queued (e.g., “this is your 4th vote”). The text substitution itself may occur when the reply message is forwarded to the outbound transport element. Priorities can also be applied. Lower-priority messages (incoming messages or reply messages) should not be delivered before higher-priority reply messages, and messages queued (or awaiting acknowledgement from the transport module) for one carrier should not prevent messages from being delivered to another carrier. The decision module may also load-balance outgoing traffic across the available outbound transport modules that can pass traffic to the target carrier. For example, the decision module may send reply traffic to the outbound transport module with the fewest outstanding messages.
In addition to processing the reply, the decision module logs the vote data at an operation 280 and sends a confirmation to the slave decision modules. Those skilled in the art will recognize that a variety of other rule processing logic may be used. In some embodiments, message processing logic may be dependent on the time the message was submitted, which may or may not be subscriber-centric time. Message processing may also be dependent on any number of opts in and out, which may be associated with the state of the subscriber. Blacklist status may be equivalent to having opted in (perhaps involuntarily) to the black list in question. Message processing may also be dependent on the number of state-changing messages received from the subscriber during the present campaign, and/or which messages have been sent to the subscriber during the present campaign. Any such state characteristics can be set before or during the campaign for any subscriber.
The outbound transport module logs message data at an operation 298. For example, a packet ID, time stamp, reply message count, and/or other data may be logged. Similar to the inbound transport module, one embodiment of the outbound transport module may maintain two categories of count data; (i) messages received and message summaries sent, and (ii) acknowledgements sent or received. Examples include:
On the decision-module-side interface, outbound transport modules may keep the following statistics:
In a simplified embodiment, the slave decision module receives and buffers a message summary from the inbound transport module(s) and an operation 300. At the decision operation 302, the slave decision module determines whether the master decision module confirmed completion of message processing. If the master decision module confirmed completion, the slave decision module removes the message summary from its inbound queue at an operation 304. The slave decision module then awaits another message summary from the inbound transport module and/or another confirmation from the master decision module.
If a confirmation or other signal has not yet been received from the master decision module, the slave decision module determines whether a timeout period has elapsed, and a decision operation 306. If the timeout period has not elapsed, the slave decision module continues to await a confirmation, a heartbeat, or other signal. If the timeout period has elapsed, the slave decision module assumes that the master decision module has failed, and the slave decision module processes messages in its inbound queue at an operation 308. The message processing by the slave decision module is similar to the processes described above with respect to
Post-processing modules also perform administrative operations to generate bills, provide usage statistics, and/or other information. The post-processing modules may use databases without slowing the other message processing operations. Data from the various logs are also used. For example, a billing module may use the information passed from master to slave decision modules (e.g., user state changes and outbound queue updates). The billing module may also use information regarding which outgoing reply messages and state changes constitute billable events. This information may be kept as part of the campaign configuration, and may be included in the state and queue updates sent from the decision modules or read independently by the billing module. State and queue updates may be helpful, or even necessary, to provide the billing module with the incoming message feed (or equivalent) as well.
The billing modules may harvest the log files created by the decision modules and transferred by a periodic automated process to the billing modules. These files comprise the state change information, which the billing module may process into an appropriate format for a 3rd party application. After collecting the events for which billing will be performed, the billing element may perform carrier-specific delivery of the billing events within a predefined timeframe.
A system administrator may further use the high capacity campaign system to perform a number of administrative functions. For example, commands may be issued to each decision module via TCP on a predefined port. The following are examples of commands and parameters to which the decision module may respond:
The above specification, examples, and data provide a complete description of the manufacture and use of the composition of the invention. Since many embodiments of the invention can be made without departing from the spirit and scope of the invention, the invention resides in the claims hereinafter appended.
This application claims the benefit under 35 U.S.C. 119(e) of U.S. Provisional Patent Application 60/825,386 filed Sep. 12, 2006, the entire contents of which are hereby incorporated by reference.
| Number | Date | Country | |
|---|---|---|---|
| 60825386 | Sep 2006 | US |
