Method and apparatus for filtering undesired email messages

A method, including: receiving an email message, the email message being generated by a computing device; detecting whether a condition associated with the email message is satisfied, the condition including a condition for detecting whether the email message is sent by an automailer that is executing on the computing device; forwarding the email message to an email server, when the condition is satisfied; and discarding the email message, when the condition is not satisfied.

BACKGROUND

Email is one of the most widely and commonly used internet services. The email infrastructure employed on the Internet primarily consists of email servers using Simple Mail Transfer Protocol (SMTP) to accept messages from clients, transport those messages to other servers, and deposit them into a user's server-based inbox. In addition to email servers, the infrastructure includes email clients. Clients retrieve email from their server-based inboxes using Post Office Protocol version 3 (POP3) or Internet Message Access Protocol (IMAP). Clients communicate with email servers using SMTP. Many Internet-compatible email systems rely on the X.400 standard for addressing and message handling.

SUMMARY

According to aspects of the disclosure, a method is provided, comprising: receiving an email message, the email message being generated by a computing device; detecting whether a condition associated with the email message is satisfied, the condition including a condition for detecting whether the email message is sent by an automailer that is executing on the computing device; forwarding the email message to an email server, when the condition is satisfied; and discarding the email message, when the condition is not satisfied.

According to aspects of the disclosure, a system is provided, comprising: a memory; and at least one processor operatively coupled to the memory, the at least one processor being configured to perform the operations of: receiving an email message, the email message being generated by a computing device; detecting whether a condition associated with the email message is satisfied, the condition including a condition for detecting whether the email message is sent by an automailer that is executing on the computing device; forwarding the email message to an email server, when the condition is satisfied; and discarding the email message, when the condition is not satisfied.

According to aspects of the disclosure, a non-transitory computer-readable medium is provided that stores one or more processor-executable instructions, which, when executed by at least one processor, cause the at least one processor to perform the operations of: receiving an email message, the email message being generated by a computing device; detecting whether a condition associated with the email message is satisfied, the condition including a condition for detecting whether the email message is sent by an automailer that is executing on the computing device; forwarding the email message to an email server, when the condition is satisfied; and discarding the email message, when the condition is not satisfied.

DETAILED DESCRIPTION

FIG. 1is a diagram of an example of an email system100, according to the prior art. As illustrated, the email system100may include an automailer102, an email server104, and one or more email clients106. The automailer102may include any software that is configured to send unauthorized email messages. An unauthorized email message may include a spoofed email message, a phishing email message, a spam email message, and/or another similar message. In operation, the automailer102may send an unauthorized email message to one or more of the email clients106by sending the email message to the email server104first. Upon receiving the email message, the email server104may distribute the email message to the one or more email clients106. In the example ofFIG. 1, the email system100lacks the capability to detect unauthorized email messages and prevent their dissemination.

FIG. 2is a diagram of an email system200that is provided with a capability to detect the transmission of unauthorized email messages and prevent it. The email system200may include a container201, an interface204, an email server206, email clients208and an identification database210. The capability to detect unauthorized email messages is provisioned, at least in part, by the interface204.

The container201may be configured to encapsulate (and execute) an automailer202and an email server203. The container201may include a virtual machine, a docker container, a microservice container, and/or any other unit of software that packages code and all (or at least some) of its dependencies for executing at least one of the automailer202and the email server203. The email server203may include a Simple Mail Transfer Protocol (SMTP) server and/or any other suitable type of email server. The automailer202may be configured to use the email server203to send unauthorized email to the email clients208and/or the email server206.

The email server206may include one or more of an SMTP server and/or any other suitable type of email server. According to the example ofFIG. 2, the email server206is an SMTP server. However, the preset disclosure is not limited thereto. The email server206may be configured to receive messages from the email server203and store the messages in inboxes that correspond to email addresses that are being accessed with the email clients208.

The email clients208may include email clients208A-C (shown inFIG. 3). Each of the email clients208may be associated with a different respective email address. Each respective email address may be associated with a corresponding inbox on the email server206. Each respective email address may belong to a respective user.

The identification database210may include a user directory that identifies a plurality of users. In some implementations, the identification database210may be configured to operate in accordance with the Lightweight Directory Access Protocol (LDAP). In some implementations, the user directory the users directory may include an employee directory that identifies all (or at least some) employees in a company.

FIG. 3is a diagram of an example of a hardware system300that is configured to implement the email system200. As illustrated, the hardware system300may include a computing device301, a computing device306, computing devices308A-C, and a computing device310, which are coupled to one another via a communications network312. The communications network312may include one or more of a local area network (LAN), a wide area network (WAN), a long term evolution (LTE) network, a wireless network, the Internet, and/or any other suitable type of communications network.

The computing device301may include a desktop computer, a laptop computer, and/or any other suitable type of computing device. In some implementations, the computing device301may be the same or similar to the computing device1000, which is discussed further below with respect toFIG. 10. According to the example ofFIG. 3, the computing device301is configured to execute the container201and the interface204. The container201and the interface204may be executed in the memory space of an execution environment303. The execution environment303may include one or more of an operating system, a hypervisor, a Docker production environment, a microservice production environment, and/or any other suitable type of execution environment. Although in the example ofFIG. 3the container201and the interface204are executed on the same computing device, it will be understood that alternative implementations are possible in which the container201and the interface204are executed on different computing devices. For example, the interface204may be executed on the same computing device as the email server206or on another computing device that lies on the a communications path between the email server206and the computing device301.

The computing device306may be configured to execute the email server206. According to the example ofFIG. 3, a computing device308A is configured to execute an email client208A, a computing device308B is configured to execute an email client208B, and a computing device308C is configured to execute an email client208C. The computing device310may be configured to execute the identification database210. Each of the computing devices306,308A-C, and310may be the same or similar to the computing device1000, which is discussed further below with respect toFIG. 10.

According to the example ofFIG. 3, the hardware system300is part of an enterprise network that is used for the exchange of internal communications within a company. The container201, along the automailer202and the email server203, is instantiated by malware for the purpose of transmitting unauthorized email messages to employees of the company (e.g., the owners of the email addresses that are being accessed with email clients208), as well as to other recipients. An unauthorized email message may include one or more of a spoofed email, a phishing email, a counterfeit email, a spam email, and/or any other email that is sent by the automailer. According to the present example, an automailer may include any software for sending unauthorized email messages. According to the example ofFIG. 3, the automailer202uses the email server203to send unauthorized email messages. Although the email server203is depicted as an entity that is separate from the automailer202, in some implementations the email server203may be integrated into the automailer202.

As noted above, the container201, along with the automailer202and the email server203, may be instantiated by malware that has found its way into the computing device301. Although the malware is being described as a separate entity, in some implementations, the malware may include code that is part of the automailer202, which allows the automailer202to replicate itself. In one example, once the malware is running on the computing device301, the malware may execute the following chain of attack: (1) the malware may instantiate, on the computing device301, a plurality of containers, such as the container201, (2) the malware may execute a different respective download of an execution file of the email server203to each of the containers, (3) the malware may execute an instance of the email server203in each of the containers, and (4) the malware may use each instance of the email server203to send unauthorized email messages.

Each of the containers may have a different Internet Protocol (IP) address. In this regard, the malware may instantiate multiple containers in order to conceal that unauthorized email messages are coming from the same device, and defeat any IP blocking mechanisms which might be employed in the hardware system300(and which react to spikes in email traffic from the same IP address). Each of the unauthorized emails may identify a fictitious sender (e.g., each of the unauthorized emails may include a spoofed sender email address and/or a spoofed sender name that is associated with the sender email address).

According to the example ofFIG. 3, the hardware system300is configured such that all outgoing traffic originating from the computing device301, and destined for the email server206, first passes through the interface204before reaching the email server206. The interface204may include software for detecting and blocking unauthorized email messages that are being sent by the computing device301to the email server206.

The interface204may employ at least one of several techniques to detect and block unauthorized email messages. For example, when the interface204receives an email message from the computing device301(which is destined for the email server206), the interface204may block the email message if a large number of containers is instantiated on the computing device301. Doing so may break the malware's chain of attack at stage1. As another example, when the interface204receives an email message from the computing device301(which is destined for the email server206), the interface204may block the email message if the executable file for the email server203has been downloaded many times to the computing device301. Doing so may break the malware's chain of attack at stage2. As yet another example, when the interface204receives an email message from the computing device301(which is destined for the email server206), the interface204may block the email message if the email message identifies a fictitious sender. To determine whether the sender of an email is fictitious, the malware may verify an identifier for the sender against the identification database210. If the identifier is not listed in the identification database210, the interface204may determine that the sender is fictitious. A sender identifier may include one or more of: an email address of the sender, a first name of the sender, a last name of the sender, a nickname of the sender, etc. As yet another example, when the interface204receives an email message from the computing device301(which is destined for the email server206), the interface204may block the email message if a signature of the received message does not match the signature of a preapproved message.

FIG. 4is a diagram of a microservice architecture for implementing the interface204in accordance with one particular implementation. As illustrated, the interface204may include an orchestrator410, a validation service411, a validation service412, a validation service413, a validation service414, a testing service415, a remedial action service416, and a forwarding service417.

The validation service411may include a microservice that is configured to determine whether the sender of an email message is fictitious (e.g., the validation service411may detect whether the email message includes a spoofed sender email address or a spoofed user name that is associated with the sender email address). In operation, the validation service411may receive, from the orchestrator410, an execution request. The execution request may include an email message (which is desired to be validated) and/or an identifier corresponding to the sender of the email message. Next, the validation service411may retrieve the identifier of the sender of the email message from the execution request (and/or the email message). Next, the validation service411may submit a query, to the identification database210, which contains the identifier of the sender of the email message. Next, the validation service411may receive a response from the identification database210, which indicates whether the identifier of the sender of the email message is listed in a directory that is managed by the identification database210. If the response from the identification database210indicates that the sender of the email message is listed in the directory, the validation service411may return TRUE to the orchestrator410. Otherwise, if the response from the identification database210indicates that the sender of the email message is not listed in the directory, the validation service411may return FALSE to the orchestrator410.

The validation service412may include a microservice that determines if an executable file for the email server203is downloaded many times on the computing device301. The predetermined software may include one or more of an email server, and/or an email client. In some implementations, the number of downloads of the predetermined software may be determined by counting the number of file downloads from a server that is known to serve as a repository for the software. In operation, the validation service412may receive an execution request from the orchestrator410. Next, the validation service412may determine a count of downloads, of the predetermined software, that have been performed by the computing device301. If the count is below a threshold, the validation service412may return TRUE. Otherwise, if the count is greater than or equal to the threshold, the validation service412may return FALSE.

The validation service413may include a microservice that determines if a large number of containers is instantiated on the computing device301. In operation, the validation service413may receive an execution request from the orchestrator410. Next, the validation service413may determine a count of containers that are instantiated on the computing device301, which also include (or execute) an email server. If the count is below a threshold, the validation service412may return TRUE. Otherwise, if the count is greater than or equal to the threshold, the validation service412may return FALSE.

The validation service414may include a microservice that is configured to compare a signature of an outgoing email (that is sent by the computing device301) to a list of signatures of emails whose forwarding to the email server206is permitted. In operation, the validation service414may receive, from the orchestrator410, an execution request. The execution request may include email source code that is part of (or otherwise associated with) an email message. The email source code may include a script, which, when executed by the email server206(or another email server), causes the email server206to disseminate the email message to a plurality of recipients. Next, the validation service414may generate a signature of the email source code. Next, the validation service414may compare the generated signature to a list of signatures. Each of the signatures on the list may correspond to an email that is pre-approved for forwarding by the email server206(e.g., to the email addresses associated with email clients208, etc.). If the generated signature matches any of the signatures on the list, the validation service414may return TRUE. Otherwise, if the generated signature does not match any of the signatures on the list, the validation service412may return FALSE.

The testing service415may include a service that is configured to test the configuration of the email server206by transmitting a test email message via the email server206. In some respects, the test email message may include an email message that is arranged to be rejected by the email server206, if the email server206is configured to operate in accordance with one or more desired security policies. If the email server206is improperly configured to operate as an open relay (i.e., without practicing any authentication (or examination) of outgoing email traffic), the email will be delivered (or forwarded), and the testing service415will receive an acknowledgement from the email server206. On the other hand, if the email server206is properly configured to perform authentication (or examination) of outgoing email traffic, the test email message will be rejected by the email server206, and the testing service415will receive an error message from the email server206. In operation, the testing service415may receive an execution request from the orchestrator410. Next, the testing service415may transmit the test email message to the email server206. If the testing service415receives, from the email server206, an acknowledgement that the test email message has been delivered (or forwarded), the testing service415may return FALSE to the orchestrator410. If the testing service415receives, from the email server206, an indication that the test email could not be delivered (or forwarded), the testing service415may return TRUE to the orchestrator410.

The remedial action service416may include a microservice that is executed, by the orchestrator410, when any of the validation services411-414returns FALSE with respect to a particular email message that is outgoing from the computing device301. In some implementations, when executed, the remedial action service416may block a sender of the particular outgoing email. Additionally or alternatively, in some implementations, when executed, the remedial action service or notify the owner of the computing device301that the computing device301is sending unauthorized emails.

The forwarding service417may include a microservice for forwarding email messages. In operation, the forwarding service417may receive, from the orchestrator, a request to forward an email message. The email message may be one that is transmitted by the computing device301and/or the automailer202. Next, in response to the request, the forwarding service417may determine a recipient (a final recipient or an intermediate recipient) for the email message (e.g., the email server206) and forward the email message to the determined recipient. In some implementations, the recipient may be determined based on information that is contained in the header of the email message.

FIG. 5is a flowchart of an example of a process500that is performed by the orchestrator410, according to aspects of the disclosure.

At step502, the orchestrator410receives an email sending request from the computing device301. According to the present example, the email sending request includes an email message that is generated by the automailer202and/or email server203. The email message may include a text message (and/or an image or other attached media) and/or email source code.

At step504, the orchestrator410identifies a plurality of validation services. According to the present example, the orchestrator410detects that validation services411-414are available to the orchestrator410.

At step506, the orchestrator410selects one of the identified validation services, which has not been executed in a previous iteration of step506.

At step508, the orchestrator410transmits an execution request to the selected execution service. For example, if validation service411is the selected service, the execution request may include the email message or an identifier of a sender of the email message. If the validation service412is the selected validation service, the execution request may include a request to determine if a count of downloads of predetermined software to the computing device301is below a threshold. If the validation service413is the selected service, the execution request may include a request to determine whether a count of containers that are instantiated on the computing device301is below a threshold. If validation service414is the selected service, the execution request may include a request to validate a signature of the email message.

At step510, the orchestrator410determines a value that is returned by the selected validation service, in response to the execution request (transmitted at step508). If the value is TRUE, the process500process to step512. If the value is FALSE, the process500proceeds to step516.

At step512, the orchestrator410detects whether all validation services (identified at step504) have been executed. If there are validation services that remain to be executed, the process500returns to step506and another one of the validation services is selected. If all validation services have been executed, the process500proceeds to step514.

At step514, the orchestrator410executes the email sending request (received at step502). Executing the request includes transmitting an execution request to the forwarding service417, to forward the email message (that is associated with the email sending request) to the email server206or another recipient. At step516, the orchestrator410denies the request (received at step502). Denying the request may include discarding the request, without forwarding it to any recipient. Additionally or alternatively, in some implementations, denying the request may include executing the remedial action service416to block a sender of the request (e.g., block an email address or an IP address associated with the sender) or notify a user of the computing device301that the computing device301is possibly used (by malware) to send unauthorized email messages.

Although not shown inFIG. 5, in some implementations, the orchestrator410may receive, from the computing device301, a request to test whether the email server206is configured securely. Next, the orchestrator410may transmit an execution request to the test service415. Next, the orchestrator410may receive a return value from the test service415. And finally, the orchestrator410may forward the return value to the computing device301. The computing device301may then display an indication of the return value to its user.

Although in the example ofFIGS. 4-5the interface204has a microservice architecture, the present disclosure is not limited to any specific implementation of the interface204. In this regard, in some implementations, the actions performed by validation services411-414may be performed by another type of software component. In some implementations, the hardware system300may be part of the computer network of a company, and the identification database210may manage a directory of all (or at least some of the employees of the company). In such implementations, by comparing email senders against the directory, the validation service411may prevent dissemination of spoofed emails within the company network. Similarly, by comparing signatures of outgoing emails to signatures of preapproved emails, the validation service414may ensure that only emails whose content is approved are exchanged on the company network.

Although in the example ofFIGS. 2-3the automailer202and the email server203are executed in a container, in some implementations they may be executed without the use of containers. Although the example ofFIGS. 2-3assumes that multiple instances of the automailer202and the email server203may be executed on the computing device, in some implementations, only one instance of the automailer202and/or email server203may be executed on the computing device301. Although the example ofFIGS. 2-5are presented in the context of filtering email traffic from the computing device301, it will be understood that the interface204may be configured to monitor email traffic (for the email server206) that originates from any computing device.

FIG. 6is a flowchart of an example of a process600, according to aspects of the disclosure. According to the example ofFIG. 6, the process600is performed by the interface204. However, alternative implementations are possible in which the process600is performed by another entity, such as the email server203.

At step602, a request is received to send an email message to a recipient. The request is received from a computing device, such as the computing device301. The request may include an email message. The email message may be a single-recipient email message, and it may identify a recipient email for the email message and a sender email for the email message. Additionally or alternatively, the message may be multi-recipient mail message, and it may include email source code, which, when executed by a mail server, causes the email server to send the email message to multiple recipients at once.

At step604, a determination is made if the message satisfies a predetermined condition. If the predetermined condition is satisfied, the process600proceeds to step606. If the condition is not satisfied, the process600proceeds to step608.

In some implementations, detecting whether the predetermined condition is satisfied may include detecting whether a sender of the email message is identified in a database, such as the database210. If the sender is identified in the database, the predetermined condition is deemed satisfied. If the sender is not identified in the database, the predetermined condition is deemed not satisfied. Additionally or alternatively, in some implementations, detecting whether the predetermined condition is satisfied may include executing one or more of processes700,800, and900, which are discussed further below with respect toFIGS. 7, 8, and 9, respectively.

At step606, the message is forwarded to a recipient. The recipient may include an email server, such as the email server206. In some implementations, recipient may be a “final destination” email server that manages the inbox of an email address to which the email message is directed. Additionally or alternatively, in some implementations, the recipient may be a “next hop” email server that would forward the message to another email server, upon receiving it.

At step608, the email message is discarded. When the email message is discarded, the email message is blocked, and not forwarded to a recipient. In other words, discarding the email message prevents the email message from reaching its recipient. In some implementations, when the message is discarded a sender of the message may be blocked and/or an alert may be generated to the owner of the computing device indicating that his or her computer is used to send unauthorized emails.

FIG. 7is a flowchart of an example of a process700for detecting whether a condition associated with an email message is satisfied, as specified by step604of the process600.

At step702, a count of containers is determined that are (i) instantiated on the computing device from which the request to send an email message is received at step602, and (ii) which are executing (or otherwise include) software for sending email messages. According to the present example, the software application is a mail server, however, the present disclosure is not limited thereto. As noted above, whether a container includes a predetermined software application, may include detecting whether the memory space of the container includes a predetermined file (e.g., email_server.exe) or a predetermined directory (e.g., “./Program Files/Mail Server/”) that is associated with the predetermined software application. In some implementations, the count of containers that are instantiated on the computing device includes: (i) a count of non-nested containers that are instantiated in an execution environment, such as the execution environment303, and (ii) a count of nested containers that are instantiated on the computing device. A nested container, according to the present example, includes a container that is instantiated in the memory space of another container.

At step704, the count is compared to a threshold a threshold. If the count does not meet the threshold (e.g., if the count is less than the threshold), the process700proceeds to step606(shown inFIG. 6). Otherwise, if the count meets the threshold (e.g., if the count is greater than the threshold), the process700proceeds to step608(shown inFIG. 8).

FIG. 8is a flowchart of an example of a process800for detecting whether a condition associated with an email message is satisfied, as specified by step604of the process600.

At step802, a count of downloads of software for sending email messages is determined, wherein the downloads are downloads performed by the computing device from which the request is received at step502. According to the present example, the software includes a mail server, however, the present disclosure is not limited thereto. Determining the count of downloads may include determining how many times the software has been downloaded on the computing device during a predetermined time period (e.g., during the last 1 hour). In some implementations, determining the count of downloads may include determining how many downloads are performed from a location that is recognized as a repository for the software. In some implementations, the count of downloads may be determined by examining the memory of the computing device from which the request is received at step502. Additionally or alternatively, in some implementations, the count of downloads may be determined by monitoring network traffic that is outgoing and/or incoming to the computing device.

At step804, the count is compared to a threshold. If the count does not meet the threshold (e.g., if the count is less than the threshold), the process800proceeds to step606(shown inFIG. 6). Otherwise, if the count meets the threshold (e.g., if the count is greater than the threshold), the process800proceeds to step608(shown inFIG. 6).

FIG. 9is a flowchart of an example of a process900for detecting whether a condition associated with an email message is satisfied, as specified by step604of the process600.

At step902, a signature of the email message is generated. The signature may include a signature of text that is part of the email message. Additionally or alternatively, the signature may include a signature of email source code that is part of the email message

At step904, a determination is made if the generated signature matches any of a plurality of pre-approved signatures. Each of the preapproved signatures may correspond to a respective email that is authorized to be forwarded (at step606). If the generated signature matches any of the pre-approved signatures, the process900proceeds to step606(shown inFIG. 6). Otherwise, if the signature does not match any of the pre-approved signatures, the process900proceeds to step608(shown inFIG. 8).

Referring toFIG. 10, computing device1000may include processor1002, volatile memory1004(e.g., random-access memory), non-volatile memory1006(e.g., a hard disk drive, a solid-state drive such as a flash drive, a hybrid magnetic and solid-state drive, etc.), graphical user interface (GUI)1008(e.g., a touchscreen, a display, and so forth) and input/output (I/O) device1020(e.g., a mouse, a keyboard, etc.). Non-volatile memory1006stores computer instructions1012, an operating system1016and data1018such that, for example, the computer instructions1012are executed by the processor1002out of volatile memory1004. Program code may be applied to data entered using an input device of GUI1008or received from I/O device1020.

Processor1002may be implemented by one or more programmable processors executing one or more computer programs to perform the functions of the system. As used herein, the term “processor” describes an electronic circuit that performs a function, an operation, or a sequence of operations. The function, operation, or sequence of operations may be hard-coded into the electronic circuit or soft coded by way of instructions held in a memory device. A “processor” may perform the function, operation, or sequence of operations using digital values or using analog signals. In some embodiments, the “processor” can be embodied in an application-specific integrated circuit (ASIC). In some embodiments, the “processor” may be embodied in a microprocessor with associated program memory. In some embodiments, the “processor” may be embodied in a discrete electronic circuit. The “processor” may be analog, digital or mixed-signal. In some embodiments, the “processor” may be one or more physical processors or one or more “virtual” (e.g., remotely located or “cloud”) processors.

FIGS. 1-10are provided as an example only. At least some of the steps discussed with respect toFIGS. 1-10may be performed in parallel, in a different order, or altogether omitted. As used in this application, the word “exemplary” is used herein to mean serving as an example, instance, or illustration. Any aspect or design described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects or designs.

To the extent directional terms are used in the specification and claims (e.g., upper, lower, parallel, perpendicular, etc.), these terms are merely intended to assist in describing and claiming the invention and are not intended to limit the claims in any way. Such terms do not require exactness (e.g., exact perpendicularity or exact parallelism, etc.), but instead it is intended that normal tolerances and ranges apply. Similarly, unless explicitly stated otherwise, each numerical value and range should be interpreted as being approximate as if the word “about”, “substantially” or “approximately” preceded the value of the value or range.

While the exemplary embodiments have been described with respect to processes of circuits, including possible implementation as a single integrated circuit, a multi-chip module, a single card, or a multi-card circuit pack, the described embodiments are not so limited. As would be apparent to one skilled in the art, various functions of circuit elements may also be implemented as processing blocks in a software program. Such software may be employed in, for example, a digital signal processor, micro-controller, or general-purpose computer.

Some embodiments might be implemented in the form of methods and apparatuses for practicing those methods. Described embodiments might also be implemented in the form of program code embodied in tangible media, such as magnetic recording media, optical recording media, solid-state memory, floppy diskettes, Compact Disk Read-Only Memories (CD-ROMs), hard drives, or any other machine-readable storage medium, wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the claimed invention. Described embodiments might also be implemented in the form of program code, for example, whether stored in a storage medium, loaded into and/or executed by a machine, or transmitted over some transmission medium or carrier, such as over electrical wiring or cabling, through fiber optics, or via electromagnetic radiation, wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the claimed invention. When implemented on a general-purpose processor, the program code segments combine with the processor to provide a unique device that operates analogously to specific logic circuits. Described embodiments might also be implemented in the form of a bitstream or other sequence of signal values electrically or optically transmitted through a medium, stored magnetic-field variations in a magnetic recording medium, etc., generated using a method and/or an apparatus of the claimed invention.

It will be further understood that various changes in the details, materials, and arrangements of the parts which have been described and illustrated in order to explain the nature of the claimed invention might be made by those skilled in the art without departing from the scope of the following claims.