Patent ID: 12261854

DETAILED DESCRIPTION OF SOME EMBODIMENTS

This disclosure is directed to the technical field of cybersecurity systems and methods. The prior Brief Summary and the following description provide examples and are not limiting of the scope, applicability. Changes can be made in the function and arrangement of elements discussed without departing from the spirit and scope of the disclosure. Various embodiments can omit, substitute, add, or mix and match various procedures or components as appropriate. For instance, the methods disclosed can be performed in an order different from that described, and various steps can be added, omitted, or combined. Also, features disclosed with respect to certain embodiments can be combined in or with other embodiments as well as features of other embodiments.

Certain embodiments of the cybersecurity infection detection system and method of use are described with reference to methods, apparatus (systems), and computer program products that can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a computing devices, such as a general purpose computer, special purpose computer, mobile computing device, or other programmable data processing apparatus to produce a particular machine, such that the instructions, which execute via the processor of the computing device, implement the acts specified herein to transform data from a first state to a second state, transmit data from one computing device to another computing device, and generate physical state transitions at one or more geographic locations.

These computer program instructions can be stored in a computer-readable memory that can direct a computing device or other programmable data processing apparatus to operate in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instructions for implementing the acts specified herein. The computer program instructions can also be loaded onto a computing device or other programmable data processing apparatus to cause a series of operational steps to be performed on the computing device or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the acts specified herein.

The programming of the programmable apparatus creates a new machine, creating a special purpose computer once it is programmed that performs particular functions pursuant to instructions from program instructions. The cybersecurity infection detection system can be described in terms of a dedicated circuit or a process that emulates that circuit. The software processes of the cybersecurity infection detection system are, at least in part, interchangeable with a hardware circuit. This new machine can thus be implemented as a complex array of hardware circuits, programming that facilitates the unique functions of the cybersecurity infection detection system, or both.

The various illustrative logical blocks, modules, and algorithm steps described in connection with the embodiments disclosed herein can be implemented as electronic hardware, computer software, or combinations of both. To illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, and steps have been described generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. The described functionality can be implemented in varying ways for each particular application and function, but such implementation decisions should not be interpreted as causing a departure from the scope of the disclosure.

The various illustrative logical blocks and modules described in connection with the embodiments disclosed herein can be implemented or performed with a general purpose processor, a specific purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor can be a microprocessor, but in the alternative, the processor can be any conventional processor, controller, microcontroller, or state machine. A processor can also be implemented as a combination of computing devices such as, for example, a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

The blocks of the methods and algorithms described in connection with the embodiments disclosed herein can be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module can reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, a hard disk, a removable disk, a CD-ROM, or any other form of computer-readable storage medium known in the art. An exemplary storage medium is coupled to a processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium can be integral to the processor. The processor and the storage medium can reside in an ASIC. The ASIC can reside in a computer terminal. In the alternative, the processor and the storage medium can reside as discrete components in a computer terminal.

Depending on the embodiment, certain acts, events, or functions of any of the methods described herein can be performed in a different sequence, can be added, merged, or left out altogether (e.g., not all described acts or events are necessary for the practice of the method). Moreover, in certain embodiments, acts or events can be performed concurrently such as, for example, through multi-threaded processing, interrupt processing, or multiple processors or processor cores, rather than sequentially. Moreover, in certain embodiments, acts or events can be performed on alternate tiers or on alternate components within the architecture.

Referring now toFIG.1andFIG.2, a computer network or similar digital processing environment in which the system and method disclosed can be implemented. The cybersecurity infection detection system and method of use can be distributed on multiple computers and devices150. In some instances, the cybersecurity infection detection system is in communication with a security stack125. In some embodiments, the cybersecurity system and method includes, but is not limited to, one or more of the following components providing one or more of infection monitoring or detection or protected devices105, such as a cloud server, on-premise server, peripheral device, internet-of-things device, network device, smart device, or other computing device:a) Probe, which can also be referred to as an agent205;b) Monitor110;c) Configuration ledger130;d) Signature ledger, which can also be referred to as a standard ledger135;e) Audit ledger140;f) Configuration controller120;g) Notification engine115;h) Public-private key infrastructure (not shown, but can be operably integrated with the configuration controller120; andi) Switchboard111.

In some embodiments, the configuration controller consoles specify the monitors' configurations, are where the configurations are modified, or both. Configurations can be written, digitally signed, to the configuration ledgers, as well as recorded, digitally signed, in the audit ledgers.

In some implementations, a messaging engine controls how the various components communicate with each other. In some instances, messages consist of two primary parts: to whom the message is intended and from whom it came, and the contents of the message. One or both parts can be digitally signed by the sender, encrypted with the public of key(s) of their intended recipients(s), or both.

In some embodiments, the cybersecurity system makes use of Public-Private Key Infrastructure, which can involve a database of one or more of the components, paired with their respective public keys. Some or all of the components of the Public-Private Key Infrastructure system are protected by the system. One or more devices are protected by one or more monitors and one or more probes. Public-Private Key Infrastructure servers can function in a similar manner as ledger servers do.

In some instances, the switchboard prevents “traffic monitoring” of the infrastructure. It does so by, at least in part, anonymizing the “to” and “from” of each message. When a Switchboard is in use, messages can be sent through it. When a message is issued from one component, e.g., from a monitor, to another, e.g., a ledger, the “To” part of message (“the header”) can be initially encrypted with the switchboard's public key and sent to the switchboard. Upon receipt and decryption of the message header, the switchboard can reroute the message to the appropriate recipient, re-encrypting the header with the public key(s) of the ultimate recipient(s).

Referring now toFIG.3, in some embodiments, the redundant components are comparable to a self-protecting mesh framework, where one or more protected devices105are monitored and managed through interactions with multiple probe205functionality managed, at least in part, by the one or more monitors110, the monitors110being managed by backend system services150. The protected devices105, as well as the devices hosting one or more of the various components of the cybersecurity infection detection system, except for the probe205and the messages, can have one or more probes205within them monitoring the protected device and the cybersecurity infection detection system components. In some implementations, probe monitoring includes performing device scanning operations.

In some embodiments, one or more probes are launched by the monitor to whom that probe reports. In some instances, one or more devices are protected by one or more probes. A single device may have probes that are launched/initiated from different monitors. Probes within the same device can take hashes of each other, as well as of the other system elements. Upon start-up, each probe can do one or more of:a) self-checks its own digital signature—The digitally signed hash of each probe is included in, for example, the probe code itself;b) performs an initial handshake with the monitor that launched it; andc) receives its first instructions from its Monitor.

If a probe fails to initiate properly, is discovered to be “defective”, or both (e.g., it fails a hash comparison test), that probe can either self-destruct or be destroyed by its parent monitor.

Referring now toFIG.4, in some embodiments, a probe205is assigned to a parent monitor110. In some instances, a probe205is an executable component that is delivered to a protected device105by a parent monitor110. The parent monitor110can further provide initialize instructions, such as, for example, a parameter file, to the probe205. The parent monitor110can connect to the protected device105and direct the protected device105to execute the probe205, where the probe205is initialized based upon the provided parameter file410.

In some implementations, the probe205will perform a check to determine if there are any other protected device resident probes205sharing the same parent monitor110running. If it is determined that such a condition exists, the probe205will kill the additional probe or probes205. In some instances, protected devices105host multiple probes205, each probe205having a unique parent monitor110with respect to the other probes205resident on the protected device105.

In some embodiments, the probe205and the parent monitor110are expected to communicate successfully within a pre-defined time period. This pre-defined time period can serve as a timeout, where a failure to both send and receive a communication between the two components can result in a timeout condition. Then timeout can be a fixed pre-determined value or a variable value. In some instances, the value is provided to the probe205by the parent monitor110. The timeout value can be modified over time, such as in response to states or conditions detected by the probe205, as an updated timeout value received from the parent monitor110, or both. In some implementations, a timeout clock is zeroed out at initialization415, after each successful communication exchange. The probe205can be implemented such that it listens for parent monitor requests420so long as a timeout determination returns false430. Upon detection of the receipt of a monitor request425, the probe205can determine the type of request435and proceed with the appropriate operations. In some cases, the message request type will be a kill probe request type, in which case, the probe205will execute a self-destruction operation455, rendering the probe205inoperable, deleting the probe205from the protected device105, or both. In some instances, helper processes external to the probe205are engaged as part of the self-destruction operations, where such helper processes can include operating system processes, installed helper applications, or both.

In other cases, the message request type will include a scan request, such as a scan of one or more files resident on the protected device105. Where the scan results in an effective scan determination result445, and where that scan determination result is effectively transmitted to the parent monitor450, then the probe205can continue listening for requests and performing probe operations. Alternatively, where the scan is unable to generate a scan determination result, or where the attempt to transmit a scan determination results to the parent monitor110fails, then the probe205can execute a self-destruction operation455.

In other cases, the message request type will include a heartbeat. The heartbeat can be accomplished through successful message exchange of various types. For example, where the parent monitor110is not requesting probe monitoring or protection activities, but instead is verifying one or more of the presence and operation of the probe205, the probes205ability to communicate effectively and correctly, or the integrity of the communication channel, then a heartbeat request can be sent to the probe205. The probe205can then respond accordingly with a heartbeat response within an acceptable time window440.

In the case where no request has been received within the timeout period such that the timeout determination equals true430, the probe205can include resident instructions that initiate self-destruct operations.

In some embodiments, the content portion of all communications to a probe are encrypted with the probe's Public Key, and only the probe is able to decrypt them. In some embodiments, the probe Private Key is not stored on a disk. It is generated as needed by the probe, using in part, its own hash as a seed for key generation. Thus, in some cases of probe compromise, the probe will not be able to generate its appropriate Private Key. In that situation, communications with the probe will fail their signature tests and the probe will be destroyed.

In some embodiments, each monitor is responsible for protecting one or more devices. A monitor can be, for example, a standalone device, such as a dedicated server, or a software process running resident within another security device (e.g., a firewall).

In order to protect another device, a monitor can launch one or more probes to run within that other device. It then sends instructions to one or more of its probes on that device. These tell the probe to, for example, take hashes at specified times/intervals of the system elements of the device. The identity of those elements and the frequency of the hashes are determined, at least in part by the monitor's configuration.

In some embodiments, monitors have one or more probes running within them. These probes can be initiated by, report to, or both, other monitors.

In some embodiments, when a Monitor boots up, it has no operational configuration. Its boot sequence includes one or more of:a) a self-check of its own digital signature—The digitally signed hash of each monitor is included in the monitor code itself;b) the initial handshake with the configuration ledgers;c) a request for, and receipt of, its operating instructions from the configuration ledgers.d) a check whether its GPS coordinates are within its operational range;e) a check of the digital signature of its host device in order to determine whether it is running inside its configured host device;f) the initial handshake with appropriate signature ledgers, audit ledgers, or both;g) the initial handshake with the appropriate external devices; andh) a check whether that at least one verified probe is running on its host device.

If a monitor fails to one or more of initiate properly is discovered to be “defective” (e.g., it fails a hash comparison test), or cannot find a resident probe, that monitor can, report its condition to the audit ledger and can then shut down itself, be shut down, or both.

In some instances, after it has obtained its operating instructions, a monitor commences operations, launching one or more probes in the devices it is configured to protect.

In some embodiments, the content portion of all communications to a monitor are encrypted with the monitor's Public Key. Only the monitor will be able to decrypt them. The monitor's Private Key may not be stored on a disk. It is generated as needed by the monitor, using in part, its own hash as a seed for key generation. Thus, in some cases of monitor compromise, the monitor will not be able to generate its appropriate Private Key. In that situation, communications with the monitor will fail their signature tests and, as soon as the failure is logged in the audit ledgers, the monitor can be shut down.

Referring now toFIG.5, in some embodiments, the monitor110will pull a list of protected devices105from the configuration ledger130, the list indicating to which protected devices105it will operate as a parent monitor510. The monitor110will create or update a protected device table for use in iterating through protected device probe requests and activities515. The monitor can then launch probes205on protected devices525, such as by transmitting executable probes205, parameter files, or both to the protected devices105. In the event the monitor110determines there is an indication of a launch failure, a launch failure error for the device is logged in the audit ledger530.

In some embodiments, where there is no launch failure indication, the parent monitor110sends one or more test messages to the probe205to validate that the probe is operational, the communication channel is intact and operational, or both535. Where a test message response is received, message type is determined and handled appropriately540. If the test message is responded to with a probe malfunction error, the malfunction error is logged in the audit ledger545. If the test message is responded to with a communication failure error, the communication failure error is logged in the audit ledger555. If the test message is responded to with a probe operational confirmation, the probe operational indicator is set to true550. In some instances, the protected device table is updated to indicate which protected devices assigned to the monitor have operational probes205.

Referring now toFIG.6, in some embodiments, the monitor traverses the protected device table610,615and determines which protected devices105have operational probes620. If the probe205is not operational, the monitor110can attempt to relaunch the probe625. If the probe205is determined to be operational, then the monitor110determines the type of the most recent received message from the probe205. If the message received is a scan result, then the monitor110process the scan result640, and in some instances, transmits a new scan request650to the probe205. In some cases, where an error message is received by the monitor110from the probe205, the error is handled according to a pre-defined error handling procedure635. Where the message received is indicative of an inactive state, such as receipt of a disconnect notification, the protected device table can be updated to indicate a non-operational probe state645.

In some implementations, the probe205supports or performs one or more of measurements (“hashes”) of critical system components, digitally signing of those hashes, and communication of those signed hashes, such as to its parent monitor110.

In some instances, the monitor110launches and operates one or more probes205in one or more protected devices105for which it is responsible. It requests from those probes205, measurements, such as digitally signed hashes, of system components, such as critical system components, and compares those digitally signed hashes with “gold standard” signed hashes in the signature ledger135. Hashes can include, but are not limited to, file content hashes, file permission hashes, and file ownership hashes.

In the event of an unauthorized discrepancy, the monitor110can issue an alert, such as an infection or device compromised alert. For every transaction the monitor110sends and receives, it can log, for example, a digitally signed record of that transaction in the audit ledger140. In some embodiments, the monitor110can also assist in creating the “gold standard” such as a standard based, at least in part, on signed hashes that are stored in the standard ledger135.

For each monitor110, its digitally signed configuration can be stored in the configuration ledger130. For each monitored component, its “gold standard”, which can include a digitally signed hash, can be stored in the signature ledger135. For every transaction involving any component, that transaction can be stored, digitally signed, in the audit ledgers140. These can include a record of every probe205a monitor10launches, the configuration of each monitor110, changes to a monitor's110configuration, and every probe request and response.

Referring now toFIG.7, a scan table is created or retrieved by the monitor110. The scan table is cleared at least with respect to entries corresponding to the probe providing scan results710. The monitor110traverses and process each of the records in the scan results received from the probe715. For each record in the scan results, the record is added to the scan table745. When all records from the probe scan results are added to the scan table, the scan table can be optionally sorted720. In some instances, the monitor110determines or detects that a new device standard is to be set725. When that determination is made, the monitor can use the received probe scan results and set the protected device standard equal to one or more of the probe scan result records730. Alternatively, where a new standard is not set, the monitor can compare the probe scan results to the stored protected device standard as part of determining whether or not the protected device may be in a compromised state735.

Referring now toFIG.8, in some implementations, when a scan comparison operation is appropriate, the monitor110receives scan results810and logs a scan result receipt record in the audit ledger815. The monitor can then proceed to compare one or more scan result records with the protected device standard to determine whether or not the two are identical820,825. In some instances, the comparison includes a tolerance for a certain degree of mismatch for one or more types of scan result records. In other instances, a match requires an identical match for all scan result records. Where the comparison determines the scan result matches the standard825, then no alerts are issued and additional subsequent scan requests may be issued. Alternatively, where the comparison determines the scan result does not match the standard825, a scan result discrepancy event is logged to the audit ledger830.

Referring now toFIG.9, in some embodiments, a notification engine115requests or receives a list of alerts stored in the audit ledger910. If it is determined that one or more of these alerts is an unsent alert915, then the alert is process such that the alert is sent to one or more target recipients based on one or more of a listing of target recipients in the configuration ledger920, internal system component recipients base on alert handling instructions, or both. Once an alert is sent to the target recipients, the audit ledger is updated with an entry indicating the alert was sent925. In some implementations, alert handling is dependent on one or more of alert priority, criticality, the role of the protected device, or other context or circumstances.

Referring now toFIG.10, in some implementations, a receiving side component, maintains an operational check on a sending side component in communication with the receiving side component. In some instances, a timeout clock is zeroed out1010before each operational check. The receiving side component can check for communications from a sending side component1015, and if it is determined that a requests is received1020, process the request accordingly1025. Alternatively, if the communication is not a request, the receiving side component can check for a heartbeat request1030. If it is determined that a heartbeat request is received1035, the process can repeat. Alternatively, if it is determined that a heartbeat was not received1035, and if it is also determined that the timeout period has elapsed1040, then a timeout alert can be issued1045.

Referring now toFIG.11, in some implementations, a sending side component, maintains an operational check on a receiving side component in communication with the sending side component. In some instances, a request is sent to a receiving side component1110and a timeout clock is zeroed out1115before each operational check. The sending side component, upon receipt of a response from the receiving side component1120determines the response includes the requested answer1125. If it does include the requested answer, then the answer can be processed accordingly1130. Alternatively, if it does not include the requested answer, the sending side component can determine if the received response is a heartbeat1140. If it is determined that it is a heartbeat1140, the process can repeat. Alternatively, if it is determined that a heartbeat was not received1140, and if it is also determined that the timeout period has elapsed1145, then a timeout alert can be issued1150.

In some embodiments, the ledgers are physically secure, remote, redundant, databases comprised of records that are digital signature linked into an immutable or near-immutable chain. Each ledger can be front-ended by a ledger server. Each ledger server is protected by one, or more, monitors and their associated probes.

In some embodiments, the content portion of all communications to a ledger server are encrypted with each ledger server's Public Key. Only each specific ledger server will be able to decrypt them. The ledger server's Private Key may not be stored on a disk. It is generated as needed by the ledger server, using in part, its own hash as a seed for key generation. Thus, in most cases of ledger server includes, the ledger server will not be able to generate its appropriate Private Key. In that situation, communications with the ledger server will fail their signature tests and, when the failure is logged in the audit ledger (those not front-ended by the compromised server), the ledger server will be shut down.

In some embodiments, the control consoles are one or more of physically secure, remote, redundant, computers. Each control consoles can be protected by one, or more, monitors and their associated probes.

In some embodiments, the content portion of all communications to a control consoles are encrypted with that control consoles's Public Key. Only the specific control consoles will be able to decrypt them. The control consoles's Private Key may not be stored on a disk. It is generated as needed by the control consoles, using in part, its own hash as a seed for key generation. Thus, in most cases of control consoles compromise, the control consoles will not be able to generate its appropriate Private Key. In that situation, communications with the control consoles will fail their signature tests and, as when the failure is logged in the audit ledgers, the control consoles will be shut down.

In some embodiments, a secure message protocol can be built on top of the application layer. Each Message can consist of at least two primary parts: to whom the message is intended and from whom it came, and the contents of the message.

Both parts are one or more of digitally signed by the sender and encrypted with the public of key(s) of their intended recipients(s). In some instances, when the switchboard is in use, the initial “To” is always to a switchboard, and the final leg “From” is also always from a switchboard. The content portions of the message can also have digitally signed “from” identification”.

Throughout this disclosure, in certain implementations, when it states that something is “encrypted with the Public Key” of a recipient, that can mean that the encryption is performed using a one-time, randomly generated symmetric encryption key, and that this symmetric encryption is then encrypted with the Public Key(s) of the intended recipient(s). It is the encrypted symmetric key(s) that is (are) included within the message.

In the event that the content is intended for multiple recipients, the content is encrypted only once, using the symmetric encryption key. It is only the one-time symmetric encryption key that is encrypted multiple times, using the respective Public Keys of each of the intended recipients.

In some embodiments, the switchboard is one or more of a physically secure, remote, redundant components that may be used for traffic anonymization. A switchboard can be, for example, a dedicated device, as in a dedicated server or a software program running resident within another security device (e.g., a firewall). It can be protected by at least one monitor and at least one associated probe.

If a switchboard fails to one or more of initiate properly, is discovered to be “defective”, (e.g., it fails a hash comparison test), or cannot find a resident Probe, that switchboard will, whenever possible, report its condition to the audit ledger and then will be shut down.

Referring now toFIG.12, each component of the cybersecurity infection detection system is connected to a system bus1205, providing a set of hardware lines used for data transfer among the components of a computer or processing system. Also connected to the bus1205are additional components1210, such as additional memory storage, digital processors, network adapters, and I/O devices. The bus1205is essentially a shared conduit connecting different elements of a computer system (e.g., processor, disk storage, memory, input/output ports, network ports, etc.) and enabling transfer of information between the elements. An I/O device interface1215is attached to system bus205in order to connect various input and output devices (e.g., keyboard, mouse, touch-screens, displays, printers, speakers, etc.) to the extended package collaboration system. A network interface1248allows the computer to connect to various other devices attached to a network. A memory1252provides volatile storage for computer software instructions1235and data1240used to implement methods employed by the system disclosed herein. Disk or persistent storage1245provides non-volatile storage for computer software instructions1250and data1255used to implement an embodiment of the present disclosure. A central processor unit1246is also attached to system bus1205and provides for the execution of computer instructions.

In one embodiment, the processor routines1235and1250are a computer program product, including a computer readable medium (e.g., a removable storage medium such as one or more flash drives, DVDROM's, CD-ROM's, diskettes, tapes, etc.) that provides at least a portion of the software instructions for the system. A computer program product that combines routines1235and data1240can be installed by any suitable software installation procedure, as is well known in the art. In another embodiment, at least a portion of the software instructions can also be downloaded over a cable, communication, and/or wireless connection.

While the foregoing disclosure sets forth various embodiments using specific block diagrams, flowcharts, and examples, each block diagram component, flowchart step, operation, and/or component described and/or illustrated herein can be implemented, individually and/or collectively, using a wide range of hardware, software, or firmware (or any combination thereof) configurations. In addition, any disclosure of components contained within other components should be considered exemplary in nature since many other architectures can be implemented to achieve the same functionality.

The process parameters and sequence of steps described and/or illustrated herein are given by way of example only and can be varied as desired. For example, while the steps illustrated and/or described herein can be shown or discussed in a particular order, these steps do not necessarily need to be performed in the order illustrated or discussed. The various exemplary methods described and/or illustrated herein can also omit one or more of the steps described or illustrated herein or include additional steps in addition to those disclosed.

Furthermore, while various embodiments have been described and/or illustrated herein in the context of fully functional computing systems, the functions described herein can be implemented in hardware, software executed by a processor, firmware, or any combination thereof. If implemented in software executed by a processor, the functions can be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Other examples and implementations are within the scope and spirit of the disclosure and appended claims. For example, due to the nature of software, functions described above can be implemented using software executed by a processor, hardware, firmware, hardwiring, or combinations of any of these. Features implementing functions can also be physically located at various positions, including being distributed such that portions of functions are implemented at different physical locations. Also, as used herein, including in the claims, “or” as used in a list of items prefaced by “at least one of” indicates a disjunctive list such that, for example, a list of “at least one of A, B, or C” means A or B or C or AB or AC or BC or ABC (i.e., A and B and C).

The foregoing description, for purpose of explanation, has been described with reference to specific embodiments. However, the illustrative discussions above are not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. The embodiments were chosen and described in order to best explain the principles of the present systems and methods and their practical applications, to thereby enable others skilled in the art to best utilize the present systems and methods and various embodiments with various modifications as can be suited to the particular use contemplated.

Unless otherwise noted, the terms “a” or “an,” as used in the specification and claims, are to be construed as meaning “at least one of” In addition, for ease of use, the words “including” and “having,” as used in the specification and claims, are interchangeable with and have the same meaning as the word “comprising.” In addition, the term “based on” as used in the specification and the claims is to be construed as meaning “based at least upon.” Also, the term “immediately” with respect to a delay of machine action means without delay typically perceivable by human users.