Provisional Patent Application of Lorenzo T Geraci For

TITLE: METHOD AND SYSTEM TO BOND, OR INTEGRATE TIGHTLY, SOFTWARE TO HARDWARE, SOFTWARE TO OTHER SOFTWARE, HARDWARE TO OTHER HARDWARE, AND THE RESULT OF ANY BONDED COMBINATIONS TO ADDITIONAL SOFTWARE OR ADDITIONAL HARDWARE.

CROSS-REFERENCE TO RELATED APPLICATIONS: None.

FEDERALLY SPONSORED RESEARCH: None.

SEQUENCE LISTING: None.

ABSTRACT A method and system to bond, or integrate tightly, software to hardware, software to other software, and the result of any bonded combinations to additional software or additional hardware. The bonded system or systems, which are created through the use of a Framework (FIG. 1) consisting of Bus (200), Broker (300), Database (400), and Engine (500). The method and system enables faster deployment of software applications, greatly reduces maintenance, enhances the operational capabilities of the hardware and of the software including the operating system, increases the reliability of the systems consisting of bonded hardware, operating system, and application. Application Programming Interfaces or APIs (100) interface with layers such as the hardware layer, the operating system layer and the software application layer (FIG. 1 and FIG.2); monitoring the activities of these layers (130). Such activities are matched against actions stored into the Database (400) and trigger reactions directed by the Broker (300) and executed by the APIs (100).

2

Activities not present in the Database (400) are treated as extraordinary events and routed to the Engine (500) in order to have new procedures developed for execution by the APIs (100) and storage into the database (400).

TECHNICAL FIELD This invention relates in general to the integration of computing devices and software, including operating systems; as well as the management of ordinary and extraordinary tasks within the resulting computing environment and from the outside world to the resulting computing environment.

DISCLOSURE OF INVENTION Presently the computing paradigm follows a three layers approach: the hardware layer, the operating system layer and the application layer, the Legacy Paradigm (FIG. 1). The present invention is a system and method for executing a tight integration called Bonding among two or more of the following layers: - Hardware Layer; - Operating System Layer; - Application Layer; - The Bonded Layer resulting from the combination of two or more of the layers. The logical components of the invention are as follows (FIG. 2): - Multiple Application Programming Interfaces (APIs), one per each layer to be bonded; - The Broker, which manages the APIs; - The Database, which stores and queries activities, events, notices and procedures; - The Engine, which oversees the entire operation. The API (Application Programming Interface) interfaces and interacts with its layer and performs three sets of functionalities (FIG. 3): a) It is capable of monitoring the activities of its layer (130 and 140): i) internal to the layer, ii) calls generated by the layers to other layers, iii) calls received by the layer generated outside the layer; querying the Database for the related activity (141); b) Executes instructions retrieved from the Database or in response to activity in its layer or as instructed by the Broker or the Engine (151, 150; 151, 152, 160 and 165); c) Simulates the functions of the layer (151).

3

The Bus (FIG. 4) scans its interfaces with the other logical components (250 and 210; FIG. 1), reads the header (220) of each instruction (230 and 235) and of each notice (240 and 245) arriving to the Bus; then routes such instruction or notice to the appropriate destination. The Broker (FIG. 5) receives notices from the API(s) about activities within the layers and between layers. The Broker queries the Database for the appropriate instruction(s) associated with such activities (321 and 325) and manages the execution of the response(s) associated with notices (326). Such responses can be: - Instruct one or more APIs to execute one or more instructions; - Send a notice to the Engine; - Send a request for instruction to the Engine; - Check on the status of one or more APIs then resubmit the query; - A combination of two or more of the above; - Do nothing. If the query does not produce any response (325), the Broker flags the activity as Extraordinary Event (330), and sends a Request to the Engine (335), then continues in its routine (340). When the Engine sends an instruction to the Broker (340 and 350), the Broker selects the API that will execute the instruction and add the appropriate header to the instruction (351) before sending it to the Bus (353). The Broker loops back to monitoring the Bus for notices (310). The Database (FIG. 6) receives requests from the API(s) (410 and 420). If a match to the request exists in the Database, the corresponding instruction is sent to the Bus (423), if there’s no match, a notice is sent to the Bus. The Database receives notices from the Broker (430 and 440). If a match to the notice exists in the Database, the corresponding instruction is returned to the Broker (443), if there’s no match, a notice is returned to the Broker. The Database receives notices from the Engine (450 and 460). If a match to the notice exists in the Database, the corresponding instruction is sent to the Bus (463), if there’s no match the Database gathers relevant data on the event (465). Examples of relevant data are: - Data on similar events; - Similar notices; - Status of API(s); - Status of the layer related to the notice.

4 Then the data is sent to the Engine (466), and the procedure is flagged “Attempted, Waiting for Feedback” (467). The Database receives feedback from the Engine (470), related to non-standard procedures attempted. Positive feedback will result in the insertion of the procedure into the Database (472) therefore becoming part of the standard procedures. After storing the new procedure, the flag on the related attempted procedure is cleared (473). The Database loops back to monitoring the Bus. The Engine (FIG. 7) monitors the Bus for notices of Extraordinary Events (510 and 520). If the Broker can handle this event, the event is routed to the Broker (521 and 540). If the Broker cannot handle it, the notice is compared to the standard procedures in the Database (522), then a set of instructions is formulated (523). The Database determines the logical units that will execute the instructions and the appropriate headers are added to the instructions (524), passed to the Bus (525), and the attempted procedure is flagged as “Waiting for Feedback” (526). If the procedure returns errors, the process of determining the new procedure loops back (522, 523, 524, 525, 526, and 527). Once the new attempted procedure is executed with no errors, the new set of instructions is compiled in finished form (530) and it is sent to the Database for insertion as a new standard procedure (531), notifying the related API(s) of the existence of the new standard procedure (532). The Engine receives requests from the Broker (535 and 550). The Engine processes these requests as if they were Extraordinary Events. The request is compared to the standard procedures in the Database (522) and then a set of instructions is formulated (523). The Database determines the logical units that will execute the instructions and the appropriate headers are added to the instructions (524), passed to the Bus (525), and the attempted procedure is flagged as “Waiting for Feedback” (526). If the procedure returns errors, the process of determining the new procedure loops back (522, 523, 524, 525, 526, and 527). Once the new attempted procedure is executed with no errors, the new set of instruction is compiled in finished form (530) and it is sent to the Database for insertion as a new standard procedure (531), notifying the related API(s) of the existence of the new standard procedure (532). The Engine receives Error Flags (560). The Engine processes these Error Flags as if they were Extraordinary Events. The Error is compared to the standard procedures in the Database (522), then a set of instructions is formulated (523). The Database determines the logical units that will execute the instructions and the appropriate headers are added to the instructions (524), passed to the Bus (525), and the attempted procedure is flagged as “Waiting for Feedback” (526). If the procedure returns errors, the process of determining the new procedure loops back (522, 523, 524, 525, 526, and 527).

5 Once the new attempted procedure is executed with no errors, the new set of instruction is compiled in finished form (530) and it is sent to the Database for insertion as a new standard procedure (531), notifying the related API(s) of the existence of the new standard procedure (532). The Engine loops back to monitoring the Bus.

DESCRIPTION OF THE DRAWINGS FIG. 1 is a high level representation of the common computing paradigm represented by three logical layers: - Hardware Layer; - Operating System Layer; - Application Layer. For the purpose of describing the invention, this representation is referred to as the Legacy Paradigm. FIG. 2 is a high level representation of the integration of the invention with the Legacy Paradigm, bonding multiple layers into one single logical layer that acquires different properties such as: - Increased reliability; - Elimination of conflicts between the layers and between the bonded layers and other systems or users, including those connected by networks or by other means; - Self-healing properties. The Invention is composed of five logical units: - The Application Programming Interfaces (APIs); one API per logical layer (100); - The Bus (200); - The Broker (300); - The Database (400); - The Engine (500). FIG. 3 is a flow chart illustrating the process within the API (100) logical component, by which the invention interfaces and interacts with the various layers. The logical unit representing this process is referred as the API. The API is common to the various types of layers such as: - Hardware Layers, meaning any computing platform or computing device; - Software Layers, including Operating System’s Layers; - Bonded Layers resulting from the combination of two or more of the following: o Hardware Layers; o Software Layers, including Operating System’s Layers; o Bonded Layers.

6 The API (100) for each distinct software, hardware, or bonded layer abstracts the direct interface differences required to access and interact with each layer in order to provide a common, standardized interface for access and interaction with the Bus (200). FIG. 4 is a flow chart illustrating the process within the Bus (200) logical component. The Bus routes data within the system’s framework and among its logical units. FIG. 5 is a flow chart illustrating the process within the Broker (300) logical component, which manages the APIs (100), their requests, and the execution of the instructions related to standard procedures stored in the Database (400), as well as routes special events to the Engine (500) or to the Database (400). FIG. 6 is a flow chart illustrating the process within the Database (400) logical component, which stores standard procedures to be executed, the event that triggers these procedures, and the logical units that will execute the procedures linked to their timing. The Database (400) also gathers data regarding extraordinary events for which there is no stored procedure, and receives and stores procedures related to these events, formulated by the Engine (500). FIG. 7 is a flow chart illustrating the process within the Engine (500) logical component, which oversees the hierarchy of the logical units, controls the layers, and governs the formulation of procedures to be stored in the Database (400) in response to new events.

DESCRIPTION OF THE PREFERRED EMBODIMENT FIG.1 illustrates a typical computing environment, composed of the hardware layer, the operating system layer and the application layer; where a software application (the application layer) delivers utility to the end user(s). For the purpose of describing the invention, this is called the Legacy Paradigm. FIG. 2 illustrates the same paradigm with the addition of the present invention, called the Framework, resulting in a tightly integrated computing unit called Bonded Layers. A preferred embodiment of the present invention executes on a computer system based on an Intel X86 compatible processor such as the Intel Pentium processor (the hardware layer); executing the Red Hat Linux (the operating system layer); with a software application installed that requires the above combination of hardware and operating system, such as Nagios (the application layer). The present invention is typically stored in the storage device and executed by the processor from memory, as it is typical for the application layer and the operating system layer.

7

In the following discussion, the term “action” refers to the execution of a set of instructions by the layers; the term “monitoring” refers to the observation of the APIs of such actions; the term “notice” refers to information sent by a logical component of the invention to another logical component of the invention; the term “instruction” refers to the set of instructions to be executed by one or more logical components within the invention, including a “do nothing” instruction. Within each layer (hardware, operating system and application), is an API (100) that has been designed to perform method steps of the present invention, geared toward monitoring the layers, and to perform actions on such layers as instructed by the other logical components of the invention. The layers’ activities trigger responses from the API, dependent on the instructions received from the other logical components of the invention. Known activities are stored in the Database (400) along with the appropriate instruction. Instructions in response to unknown activities (extraordinary events) are formulated and tested by the Engine (500), before being executed by the APIs (100). New instructions executed by the API under direct control from the Engine (500) are then stored in the Database (400) and become part of the stored procedures repository. An example of an action to be taken is when the software application may need to reboot the hardware. The invention will call the proper procedure from the Database (400), shut off the software application, shut off the operating system, note to restart the operating system, note to restart the software application, put itself into a reboot mode, reboot the hardware and upon the hardware coming back on line, launches the operating system, then launches the application software returning the application software at the same status prior to the reboot call. Another example of an action to be taken is when the application software must perform maintenance tasks, such as data compacting and file defragmentation. The entire computing unit is shut-off, then the operating system is launched with the bare minimum services necessary to operate the computing environment and launch the maintenance application. Upon successful completion of the data compacting and file defragmentation, the maintenance application is closed, the operating system is restarted with the entire set of services, and the software application is launched returning it to the same status prior to the maintenance call. A third example of an action to be taken is when the available disk space decreases below a threshold, within a series of progressive thresholds, the invention can send an alert message via the API, using features present in one or more the layers, such as visual or acoustic signals in the hardware, messaging capabilities in the operating system or in the software application.

8 The present invention preferably contains many different stored procedures (possible actions with related instruction set), with additional stored procedures to be created, tested, executed and stored for future reference and use.

CLAIMS 1. A method for bonding, or integrating tightly, software to hardware. By software it is intended any instruction set, including, but not limited to, operating systems. By hardware it is intended any computing platform capable of running software, including, but not limited to, operating systems and software applications. 2. A method for bonding, or integrating tightly, software to software. By software it is intended any instruction set, including, but not limited to, operating systems. 3. A method for bonding or integrating tightly, hardware to hardware. By hardware it is intended any computing platform capable of running software, including, but not limited to, operating systems and software applications. 4. A method for bonding or integrating tightly, multiple pieces of software to hardware. By software it is intended any instruction set, including, but not limited to, operating systems. By hardware it is intended any computing platform capable of running software, including, but not limited to, operating systems and software applications. 5. A method for bonding or integrating tightly, software to multiple pieces of hardware. By software it is intended any instruction set, including, but not limited to, operating systems. By hardware it is intended any computing platform capable of running software, including, but not limited to, operating systems and software applications. 6. A method for bonding or integrating tightly, multiple pieces of software to multiple pieces of hardware. By software it is intended any instruction set, including, but not limited to, operating systems. By hardware it is intended any computing platform capable of running software, including, but not limited to, operating systems and software applications. 7. A method for bonding or integrating tightly, the result of any bonded combination in claims 1 to 7 to additional software or additional hardware. By software it is intended any instruction set, including, but not limited to, operating systems. By hardware it is intended any computing platform capable of running software, including, but not limited to, operating systems and software applications. 8. Any of the methods in claims 1 to 7, where one of the software is a piece of software sending and receiving information to a network. 9. Any of the methods in claims 1 to 7, where all, or a portion of, the invention is tightly

9 integrated into another piece of software. By software it is intended any instruction set, including, but not limited to, operating systems. 10. Any of the methods in claims 1 to 9, where the resulting tool is a single computing unit, used for single or multiple purposes. 11. Any of the methods in claims 1 to 10, where one of the software is a piece of software that integrates multiple computing units within a population of units, into overlapping subsets of the population, that can be managed and operated individually, as the whole population, as the whole subsets, or multiple units within a subset. * * * * *

10
LEGACY PARADIGM

APPLICATION LAYER

OPERATING SYSTEM LAYER

HARDWARE LAYER

FIGURE 1

BONDED LAYERS FRAMEWORK LEGACY PARADIGM

BROKER (300)

API (100)

APPLICATION LAYER

ENGINE (500)

B U S (200)

DATABASE (400)

API (100)

OPERATING SYSTEM LAYER

API (100)

HARDWARE LAYER

FIGURE 2

11

APPLICATION PROGRAMMING INTERFACE - API (100)

MONITOR BUS FOR API INSTRUCTION (110)

INSTRUCTION PRESENT? (120) NO MONITOR LAYER ACTIVITY (130)

YES

EXECUTE INSTRUCTION (121)

SEND NOTICE TO BUS (122)

BUS (200)

ACTIVITY PRESENT? (140) NO

YES

COMPARE ACTIVITY AGAINST DATABASE (141)

BUS (200)

ACTIVITY IN DATEBASE? (150) NO FLAG ACTIVITY AS EXTRAORDINARY EVENT (160)

YES

EXECUTE RESPONSE (151)

SEND NOTICE TO THE BUS (152)

BUS (200)

BUS (200)

SEND NOTICE TO THE BUS (165)

FIGURE 3

12

B U S (200)

WAIT FOR ACTIVITY (210)

READ HEADER (220)

API (100)

INSTRUCTION? (230) NO

YES

ROUTE TO API (235)

NOTICE? (240) NO ROUTE TO ENGINE (250)

YES

ROUTE TO BROKER (245)

BROKER (300)

ENGINE (500)

FIGURE 4

13

BROKER (300)

MONITOR BUS FOR NOTICES (310)

NOTICE PRESENT? (320) NO MONITOR ENGINE INTERFACE FOR INSTRUCTIONS (340)

YES

COMPARE NOTICE AGAINST DATABASE (321)

DATABASE (400)

NOTICE IN DATEBASE? (325) NO

YES

EXECUTE RESPONSE (326)

NO

INSTRUCTION PRESENT? (350) YES ADD HEADER TO INSTRUCTION (351)

FLAG ACTIVITY AS EXTRAORDINARY EVENT (330)

SEND REQUEST TO THE ENGINE (335)

ENGINE (500)

SEND INSTRUCTION TO THE BUS (353)

BUS (200)

FIGURE 5

14

DATABASE (400)

MONITOR BUS FOR API REQUESTS (410)

REQUEST PRESENT? (420) NO MONITOR BROKER INTERFACE FOR NOTICES (430)

YES

MATCH REQUEST AGAINST STORED PROCEDURES (421)

MATCH FOUND? (422) NO SEND NOTICE TO THE BUS (425)

YES

SEND INSTRUCTION TO THE BUS (423)

BUS (200)

NOTICE PRESENT? (440) NO MONITOR ENGINE INTERFACE FOR NOTICES (450)

YES

MATCH REQUEST AGAINST STORED PROCEDURES (441)

MATCH FOUND? (442) NO RETURN NOTICE TO THE BROKER (445)

YES

RETURN INSTRUCTION TO THE BROKER (443)

BROKER (300)

NOTICE PRESENT? (460) NO

YES

MATCH REQUEST AGAINST STORED PROCEDURES (461)

MATCH FOUND? (462) NO GATHER DATA ON SIMILAR EVENTS, SIMILAR NOTICES, STATUS OF API(s) AND RELATED LAYERS (465)

YES

SEND INSTRUCTION TO THE BUS (463)

FEEDBACK PRESENT? (470) NO

YES

MATCH FEEDBACK WITH ATTEMPTED PROCEDURE (471)

BUS (200)

STORE NEW PROCEDURE INTO DATABASE (472)

SEND DATA TO ENGINE (466)

ENGINE (500)

CLEAR FLAG FROM ATTEMPTED PROCEDURE TABLE (473)

FLAG PROCEDURE AS ATTEMPTED, WAITING FOR FEEDBACK (467)

FIGURE 6

15

ENGINE (500)

MONITOR BUS FOR NOTICES OF EXTRAORDINARY EVENTS (510) DATABASE (400) NOTICE PRESENT? (520) NO YES CAN IT BE HANDLED BY THE BROKER? (521) YES FORMULATE INSTRUCTION (523) NO COMPARE NOTICE AGAINST DATABASE (522)

BROKER (300)

PASS NOTICE TO BROKER (540)

MONITOR INTERFACE WITH BROKER FOR REQUESTS (535)

ADD HEADER TO INSTRUCTION (524)

PASS INSTRUCTION TO THE BUS (525) YES AWAIT FEEDBACK (526)

REQUEST PRESENT? (550) NO

NO YES WAS IT A BROKER REQUEST? (535)

ERROR PRESENT? (527) NO COMPILE NEW INSTRUCTION FOR BROKER (530)

YES

NO

WAS IT AN ERROR? (536) YES

SEND NEW INSTRUCTION SET TO THE DATABASE (531)

DATABASE (400)

NOTIFY API OF NEW STANDARD EVENT (532) NO ANY ERROR FLAGS? (560) YES

API (100)

FIGURE 7

Sign up to vote on this title
UsefulNot useful