METHOD AND SYSTEM FOR SYNCHRONIZED ACQUISITION, PROCESSING AND SHARING OF INSTRUMENTATION DATA AND FOR SYNCHRONIZED CONTROL IN A CLIENT-SERVER NETWORK

Abstract: The present invention is a softare/hardware architecture which is based on an interactive graphical network model and which performs synchronized acquisition, processing and sharing of instrumentation data from at least one remote instrument coupled to one server and which synchronizes the control of devices including said instruments in a client-server network. In a specific embodiment, responsive to input from a user, the architecture transmits a selected software control object associated with a selected instrument. Second, the software/hardware architecture displays a graphical representation of a functionality of the selected software control object. Third, the software/hardware architecture, responsive to input from the user, acquires instrumentation data. Fourth, responsive to further input from the user, the software/hardware architecture stores the instrumentation data. Fifth, responsive to input from the user to a selected device driver associated with the selected instrument, the software/hardware architecture sends the instrumentation data to the display device of the client for presentation to the user. Sixth, the software/hardware architecture, responsive to further input from the user, presents a graphical representation of the instrumentation data to the user. Seventh, the software/hardware architecture manages the selected software control object at least for controlling a defined behavior of the object. Finally, the software/hardware architecture interfaces the selected software control object to the selected instrument via the client-server network and a device driver manager in each one of the servers.

Description: METHOD AND SYSTEM FOR SYNCHRONIZED ACQUISITION, PROCESSING AND SHARING OF INSTRUMENTATION DATA AND FOR SYNCHRONIZED CONTROL IN A CLIENT-SERVER NETWORK BACKGROUND OF THE INVENTION This invention relates generally to instrumentation display and control in a client-server network environment, and particularly to a network implementation of a medical instrumentation cluster using a network browser paradigm. This invention affects all medical real-time imaging systems. In the past, several types of real-time medical imaging systems have been used. These types of real-time medical imaging systems have certain structural features which lead to several functional problems. Structurally, the different types of real-time medical imaging systems differ in terms of their computer architecture. Most of the past systems use proprietary software to control proprietary hardware. The rest of the past systems use commercially available (off-the-shelf) hardware components, such as digital signal processing (DSP) boards and/or software components, and, operating systems, to a limited extent. No matter what components are used by past systems, prior to this invention, their overall hardware/software architecture remains proprietary and closed. Generally, such traditional real-time medical imaging systems are based on a closed, monolithic architecture. Usually, these real-time medical imaging systems employ an embedded solution in which a central microprocessor (or a bank of microprocessors) is "embedded" in proprietary or off-the-shelf hardware. The hardware is controlled by "embedded" software with a proprietary or off-the-shelf real-time executive kernel (or basic component of an operating system), with most definitely proprietary applications to control the hardware. This requires intimate coupling of software to the target hardware. With this approach, the real-time medical imaging system has the advantage of being able to quickly execute real-time tasks by closely controlling the hardware with minimal software layers. However, this type of system's critical disadvantage is that the most important software and hardware components are proprietary and developed, in one shape or form, internally. Consequently, these types of real-time medical imaging systems have several significant functional disadvantages. These systems pose problems to users in terms of (1) the making of modifications to the system's software, (2) compatibility among diverse computer software components developed by different parties, (3) the gathering, processing, and sharing of image data from multiple instruments in multiple locations to multiple users in multiple locations, and (4) the integration of new software components into the existing system software. First, modifications to the system software of one of these systems incurs a considerable penalty in terms of (1) speed of development, (2) risks of affecting the rest of the software, and (3) difficulty of incorporating the changes without drastically altering the original design. Second, compatibility is a problem if the system software application was developed by a different party. Third, as in our design, an integrated approach to acquire or process data and to transfer the data across the network is difficult with such a monolithic design. Consequently, the sharing of instrumentation data is hampered by these systems because, typically, a user using one of these systems can monitor only one instrument at a time and can monitor that instrument from only one location. Finally, as new developments occur in the system's software, integration of these new software developments is made difficult by two factors. First, integration requires the integrator to have access to either the source code or a linkable library file that is compatible with the system's original software platform in terms of the language, hardware platform, etc. Second, even if the source code or the library were available, integration is still made difficult because it requires that the developer understand the internal design of the new software component in order to effectively use it within the system software. The Internet provides users with a means of communicating information, ideas, and messages and with a means to design reusable software written in a highly standardized computer language. The Internet is a global computer network, consisting of Web clients and Web servers, which allows a user at a Web client to access information through the use of an Internet Web browser running on the Web client. Through the Web browser, the user accesses a particular Web server through an Internet link. By connecting to the Internet, the user can retrieve information from a multitude of Web sites, where each Web site is located at a Web server. A Web site is a series of screen displays, Web pages, consisting of text, pictorial, and other information about a particular subject, organization, or company. A particular Web site can be retrieved from the Internet by establishing an Internet link to the Web site. In order to establish an Internet link to the Web site, the user would specify the Web site's Internet uniform resource locator (hereinafter URL) address to the Web browser or would click on a hypertext link on a Web page, with this hypertext link including the Web site's Internet URL address. The Internet provides a means to design and implement reusable software components developed in a highly standardized environment, such as Java Applets and/or ActiveX controls. Both Java Applets and ActiveX controls provide for modular, reusable code development. Such code can be easily transferred between systems in a network environment, such as the Internet. When a Web browser interprets a Web page which includes Java Applets or ActiveX controls, the Web browser retrieves a software object developed as a Java Applet or as an ActiveX control from a Web server on the computer network, such as the Internet. After retrieving this software object, the Web client, which is running the Web browser, makes use of the down-loaded software objects by running them on the Web client's system within the current Web page. SUMMARY OF THE INVENTION According to the invention, a software/hardware architecture is provided which is based on an interactive graphical network model and which performs synchronized acquisition, processing and sharing of instrumentation data from at least one remote instrument coupled to one server and which synchronizes the control of devices including said instruments in a client-server network, with the client-server network comprising at least one client, at least one server, and a communications medium connecting each client to each server, whereby the architecture permits the performance of a series of synchronized functions. In a specific embodiment, responsive to input from a user at the client, the architecture transmits, from at least one of the servers to the client, a selected software control object associated with a selected instrument. Second, the software/hardware architecture displays a graphical representation of a functionality of the selected software control object on a display device of the client. Third, the software/hardware architecture, responsive to input from the user to the selected software control object, acquires instrumentation data from the selected instrument. Fourth, responsive to input from the user to the selected software control object, the software/hardware architecture stores the instrumentation data in a designated computer storage medium. Fifth, responsive to input from the user to a selected device driver associated with the selected instrument via the selected software control object, the software/hardware architecture sends the instrumentation data to the display device of the client for presentation to the user. Sixth, the software/hardware architecture, responsive to input from the user to the selected software control object, presents a graphical representation of the instrumentation data on the display device of the client to the user. Seventh, the software/hardware architecture manages the selected software control object at least for controlling a defined behavior of the selected software control object. Finally, the software/hardware architecture interfaces the selected software control object to the selected instrument via the client- server network and a device driver manager in each one of the servers. Key components of the invention include the synchronization of the acquisition of the instrumentation data from the data acquisition elements and the synchronization of the presentation of this instrumentation data, such that the data acquisition tasks and the device control tasks are separated from the user interface tasks and data display tasks. In order to synchronize the acquisition of the instrumentation data from the data acquisition elements, the software/hardware architecture (the device driver manager in the server) controls a timing sequence of the software/hardware architecture's interfacing (each device driver's timing sequence) of the selected software control object to the selected instrument via the client-server network. In order to synchronize the display of the instrumentation data on the display device of the client to the user, the software/hardware architecture (the software control object at the client) controls a timing sequence of the software/hardware architecture's presenting of the instrumentation data on the display device of the client to the user. In addition, the software/hardware architecture (the software control object manager at the server) manages the selected software control object by at least controlling the behavior of the selected software control object. In these three ways (the device driver manager in said server, the software control object in the client, and the software control object manager in the server), the software/hardware architecture additionally separates the data acquisition tasks and the device control tasks, tasks performed at the server, from the user interface tasks and display tasks, tasks performed at the client. The invention will be better understood by reference to the following detailed description in connection with the following drawings. BRIEF DESCRIPTION OF THE DRAWINGS Fig. 1 is a block diagram of a client-server network for data acquisition and control, according to the present invention. Fig. 2 is a block diagram of the client-side system of the present invention, illustrating user interface elements and instrumentation data display elements. Fig. 3 is a block diagram of the server-side system of the present invention, illustrating data acquisition elements and control interface elements. Fig. 4 is a high-level flow chart illustrating the operation of the present invention between a client and a server. Fig. 5 illustrates a system block diagram of a typical computer system used to execute the software of a client and a server in an embodiment of the present invention. Fig. 6 is a block diagram of the Internet to which a client and a server, according to the present invention, can attach. Fig. 7 is a timing diagram illustrating data acquisition timing according to the invention. Fig. 8 illustrates a typical control object and data view according to the invention. DESCRIPTION OF SPECIFIC EMBODIMENTS The invention is explained in the context of applications of medical instrumentation in a client-server networked environment, such as an Internet/intranet environment. However, this invention is applicable to analogous fields requiring realtime and/or quasi-real-time data acquisition and control. Therefore, the description of the embodiment that follows is for purposes of illustration and not limitation. Fig. 1 is a block diagram of a client-server network for data acquisition and control, according to the present invention. Referring to Fig. 1, there is shown a system 100 comprising illustrative clients 112, 114 coupled via network 116 to a plurality of servers 118, 120, with each server 118, 120 being respectively connected to a plurality of acquisition modules 122, 124 and 126, 128, and, with each acquisition module 122, 124, 126, 128 being respectively connected to an instrument 130, 132, 134, 136. A user at client 112, 114 sends a user command to client 112, 114. Depending upon the type of user command inputted, client 112, 114 generates and sends a software control object (hereinafter control object) request, an acquire data command, or a store data command via network 116 to server 118, 120. Also depending upon the type of user command inputted to client 112, 114, server 118, 120 respectively generates and respectively sends control object behavior data and control object view data to client 112, 114 via network 116, acquisition module commands to acquisition module 122, 124 and 126, 128, and/or acquired timing data and acquired measured data to client 112, 114 via network 116. Acquisition module 122, 124, 126, 128 respectively sends instrument commands to instrument 130, 132, 134, 136. Instrument 130, 132, 134, 136 respectively generates and respectively sends instrument data to acquisition module 122, 124, 126, 128. Acquisition module 122, 124 and 126, 128 respectively generates and respectively sends acquisition module data to server 118, 120. Responsive to a command from a user, server, 118, 120 respectively generates and respectively sends control object behavior data, control object view data, acquired timing data, and acquired measured data via network 116 to client 112, 114. Client 112, 114 can display a control object view, a data view, or a control object and data view to the user on a display of the client. Fig. 2 is a block diagram of the client-side system of the present invention, illustrating user interface elements and instrumentation data display elements. Referring to Fig. 2, there is shown a system 200 comprising illustrative client 112, 114, connected to network 116. Client 112, 114 comprises network browser 210, control object shell 220, temporary computer storage medium 230, and archival computer storage medium 240. Control object shell 220 comprises command manager 222 and view manager 224. In an embodiment of the present invention, a control object comprises a software object responsive to at least one input command to generate and send at least one output command based on a defined behavior of the software object. In addition, a control object is responsive to at least one input command to generate and send at least one set of data. A control object is associated with a particular instrument 130, 132, 134, 136. In an embodiment of the present invention, each control object is a software object which is accessed by Java Applets or ActiveX controls within a Web page. A user inputs a user command into network browser 210 running on client 112, 114. Network browser 210 receives the user command and generates and sends either a control object request or a control object command. Depending upon the type of user command received, network browser 210 sends a control object request to server 118, 120 via network 116 and to view manager 224. Alternatively, network browser 210 sends a control object command to command manager 222. If network browser 210 sends a control object request to server 118, 120 via network 116, temporary computer storage medium 230 receives control object behavior data and control object view data from server 118, 120 via network 116. In an embodiment of the present invention, a control object request would be generated by network browser 210 in response to a user's having selected a particular control object in order to control its associated instrument 130, 132, 134, 136. In addition, in an embodiment of the present invention, temporary computer storage medium 230 receives an electronic copy of a user interface module when temporary computer storage medium 230 receives control object behavior data and control object view data. Command manager 222 subsequently retrieves the control object behavior data from temporary computer storage medium 230. View manager 224 also receives the control object request from network browser 210. View manager 224 subsequently retrieves the selected control object view data from temporary computer storage medium 230, and generates and sends a control object view to network browser 210. Network browser 210, thereafter, displays the control object view to the user on a display of the client. In an embodiment of the present invention, the displayed control object view is a graphical representation of a functionality of the selected control object. In an embodiment of the present invention, network browser 210 is optimized for presenting the graphical representation of the functionality of the selected control object on the display device of client 112, 114. In the present invention, the control object is responsive to control object commands, as follows. If command manager 210 receives a control object command from network browser 210, command manager 210 performs one of several functions. If the control object command corresponds to an acquire data command, command manager 222 sends an acquire data command to server 118, 120 via network 116, and, temporary computer storage medium 230 receives acquired timing data and acquired measured data from server 118, 120 via network 116. If the control object command corresponds to a store data command, command manager 222 sends a store data command either to server 118, 120 via network 116 or to temporary computer storage medium 230. If, according to the control object command, command manager 222 sends the store data command to temporary computer storage medium 230, temporary computer storage medium 230 sends acquired measured data and acquired timing data to archival computer storage medium 240 for storage. Alternately, command manger 222 sends the store data command to server 118, 120 via network 116, and, server 118, 120 reacts accordingly, as described later in this description. The present invention can provide several different views to the user. In addition to the aforementioned control object view, the present invention can provide a data view or a control object and data view. If command manager 222 sends to view manager 224 a view data command which indicates a request for a data view, view manager 224 retrieves the acquired timing data and the acquired measured data from temporary computer storage medium 230, and, subsequently, generates and sends a data view, comprising a graphical representation of the acquired measured data synchronized with the acquired timing data, to network browser 210. Network browser 210, thereafter, displays the data view to the user on the display of the client. Alternately, if command manager 222 sends to view manager 224 a view command which indicates a request for a control object and data view, view manager 224 retrieves the acquired timing data, the acquired measured data, and the control object view data from temporary computer storage medium 230, and, subsequently, generates and sends a control object and data view, comprising a graphical representation of the acquired measured data synchronized with the acquired timing data and a graphical representation of a functionality of the selected control object, to network browser 210. Network browser 210, thereafter, displays the control object and data view to the user on the display of the client. By synchronizing the acquired measured data with the acquired timing data, view manager 224 effectively controls the timing sequence of the presentation of the graphical representation of the acquired timing data by network browser 210. In an embodiment of the present invention, network browser 210 is optimized for presenting the graphical representation corresponding to the instrumentation data on the display device of client 112, 114. Fig. 3 is a block diagram of the server-side system of the present invention, illustrating data acquisition elements and control interface elements. Referring to Fig. 3, there is shown a system 300 comprising an illustrative server 118, 120 being respectively connected to network 116 and to at least one acquisition module 122 or 126, 124 or 128, with this acquisition module 122 or 126, 124 or 128 being respectively connected to instrument 130 or 134, 132 or 136. The server comprises control object manager 310, device driver manager 320, at least one device driver 330, 335, and computer storage medium 340. When control object manager 310 receives a control object request from client 112, 114 via network 116, control object manager 310 generates and sends control object behavior data and control object view data to client 112, 114 via network 116. The control object manager manages the behavior of the control object that has been requested by defining at least one characteristic of the control object in terms of control object behavior data, by creating the control object when the control object is requested, and by deleting the control object when the control object is no longer needed. When device driver manager 320 receives from client 112, 114 via network 116 an acquire data command which indicates a request to acquire data directly from instrument 130 or 134, 132 or 136, device driver manager 320 proceeds to generate and send a measure data command, a synchronize signal, and a setting command to device driver 330, 335. Device Driver 330, 335 respectively generates and respectively sends a synchronized measure data command, an acquisition module setting command, and an instrument setting command to acquisition module 122 or 126, 124 or 128. Acquisition module 122 or 126, 124 or 128, respectively generates and sends a retrieve data command and a setting command to instrument 130 or 134, 132 or 136. Thereafter, instrument 130 or 134, 132 or 136, respectively generates and sends an instrument status and measured data to acquisition module 122 or 126, 124 or 128. Acquisition module 122 or 126, 124 or 128 respectively generates and sends an acquisition module status and timing data, and, respectively sends the instrument status and the measured data to device driver 330, 335. From this data, device driver 330, 335 respectively generates and sends status data, and, respectively sends the timing data and the measured data to device driver manager 320. Device driver manager 320 generates and sends acquired timing data and acquired measured data to client 112, 114 via network 116. When device driver manager 320 receives from network 116 an acquire data command which indicates a request for stored data, device driver manager 320 proceeds to retrieve stored timing data and stored measured data, from computer storage medium 340. Thereafter, device driver manager 320 generates and sends acquired timing data and acquired measured data to client 112, 114 via network 116. When device driver manager 320 receives a store data command from network 116, device driver manager 320 proceeds to generate and store timing data and measured data in computer storage medium 340. Device drive manager 320, device driver 330, 335, and acquisition module 122 or 126, 124 or 128 accomplish the interfacing of a particular control object to a particular instrument 130 or 134, 132 or 136. Acquisition module 122 or 126, 124 or 128 responds to at least one real-time event in instrument 130 or 134, 132 or 136 via the instrument status sent from instrument 130 or 134, 132 or 136 and by issuing the setting command to instrument 130 or 134, 132 or 136. Device driver 330, 335 responds to at least one real-time event in instrument 130 or 134, 132 or 136 via the instrument status and acquisition module status sent from acquisition module 122 or 126, 124 or 128 and by issuing the acquisition module setting command and the instrument setting command to acquisition module 122 or 126, 124 or 128. Device Driver Manager 320 responds to at least one real-time event in instrument 130 or 134, 132 or 136 via the status sent from device driver 330, 335 and by issuing the setting command to device driver 330, 335. Device driver manager 320 controls the timing sequence of the interfacing of a particular control object to a particular instrument 130 or 134, 132 or 136 by issuing the synchronize signal to device driver 330, 335, which in turn generates and sends the synchronized measure data command to acquisition module 122 or 126, 124 or 128 . Fig. 4 is a high-level flow chart illustrating the operation of the present invention between a client and a server. First, at step 410, the client receives a control object request from the user and, subsequently, sends the control object request to the server via a network. Next, at step 420, the server receives the control object request. At step 425, the server generates and sends the requested control object to the client. At step 430, the client receives the control object. Next, at step 435, the client generates and displays a control object view. At step 440, the client receives an acquire data command from the user, and, subsequently, sends the acquire data command to the server. At step 450, the server receives the acquire data command. At step 455, the server acquires data, both acquired measured data and acquired timing data, from an instrument via a corresponding acquisition module, and, subsequently, sends this data to the client. At step 460, the client receives this data. At step 470, the client receives a view data command. Next, at step 475, the client generates and displays a data view or a control object and data view on the display of the client. At step 480, the client receives a store data command, and, subsequently, sends the store data command to the server or stores the data within itself in an archival computer storage medium. Next, at step 490, the server receives the store data command. At step 495, the server stores the data in a computer storage medium. Fig. 5 illustrates a system block diagram of a typical computer system 500 used to execute the software of client 112, 114 and server 118, 120 in an embodiment of the present invention. Computer system 500 includes subsystems such as a central processor 510, a system memory 520, an I/O control object 530, a fixed disk 540, and a network interface 550. Computer system 500 may also include a display 560, a keyboard 570, a pointing device 575, and a removable disk 580. Other computer systems suitable for use with the present invention may include additional or fewer subsystems. For example, another computer system could include more than one processor 510 (i.e. , a multi-processor system) or a cache memory as part of system memory 520. Arrows such as 590 represent the system bus architecture of computer system 500. However, these arrows are illustrative of any interconnection scheme serving to link the subsystems. For example, a local bus could be utilized to connect the central processor to the system memory and display adapter. Computer system 500 is but an example of a computer system suitable for use with the present invention. Other configurations of subsystems suitable for use with the present invention will be readily apparent to one of ordinary skill in the art, especially in the field of parallel processing. Fig. 6 is a block diagram of the Internet/intranet 600 to which client 112, 114 and server 118, 120, according to the present invention, can attach. In the example shown, client 112, 114 is attached to an Internet provider network 610, and, server 118, 120 is attached to an Internet provider network 610. A number of Internet provider networks 610 provide connection to local access providers 620, which then provide access to network service providers 630. The network service providers 630 then connect to network access providers 640, which, in turn, are connected to the backbone service 650. It should be understood that other configurations of the Internet or other networks could be used with the present invention. Fig. 7 illustrates timing diagram 700 depicting a typical data acquisition timing sequence according to the invention. Data trace 710 illustrates the value of frame index interrupt signal (FII) 712 over time. Data trace 715 illustrates the value of hardware toggle/notify signal (HT/N) 717 over time. Data trace 720 illustrates the value of R-Theta (hereinafter RT) transfer from hard disk (hereinafter HD) to the data dependent processing module (hereinafter DDP) input buffer signal (RTT_HD_DDP) 722 over time. Data trace 724 illustrates the value of DDP table based filtering signal (DDP TBF) 726 over time. Data trace 728 illustrates the value of RT transfer from the DDP output buffer to the scan converter module (hereinafter SC) input buffer signal (RTT_DDP_SC) 729 over time. Data trace 730 illustrates the value of read X/Y from the SC output buffer for three dimensional volume construction and rendering (hereinafter 3D) and long-view representation (hereinafter LV) signal (RX/Y_SC) 735 over time. Data trace 740 illustrates the value of process data for 3D and LV signal (PD 3D&LV) 745 over time. In an embodiment of the present invention, FII 712 is an instrument status signal generated by and sent from instrument 130 or 134, 132 or 136. In another embodiment of the present invention, FII 712 is an instrument status signal sent from instrument 130 or 134, 132 or 136 via acquisition module 122 or 126, 124 or 128. In an embodiment of the present invention, HT/N 717 is an instrument status signal generated by and sent from instrument 130 or 134, 132 or 136. In another embodiment of the present invention, HT/N 717 is an instrument status signal sent from instrument 130 or 134, 132 or 136 via acquisition module 122 or 126, 124 or 128. In an embodiment of the present invention, RTT_HD_DDP 722 is a signal generated and used within acquisition module 122 or 126, 124 or 128. In an embodiment of the present invention, DDP TBF 726 is a signal generated and used within acquisition module 122 or 126, 124 or 128. In an embodiment of the present invention, RTT DDP SC 729 is a signal generated and used within acquisition module 122 or 126, 124 or 128. In an embodiment of the present invention, read X/Y signal 735 is a signal generated and used within device driver 330, 335. In another embodiment of the present invention, RX/Y SC 735 is a signal generated and used within device driver manager 320. In another embodiment of the present invention, RX/Y_SC 735 is a signal generated and used within view manager 224. In an embodiment of the present invention, process data signal 745 is a signal generated and used within device driver 330, 335. In another embodiment of the present invention, PD_3D&LV 745 is a signal generated and used within device driver manager 320. In another embodiment of the present invention, PD 3D&LV 745 is a signal generated and used within view manager 224. In an embodiment of the present invention, each set of these signals represents a sequence of operations which can be performed by a single or multiple processors concurrently. In another embodiment of the present invention, several such sequences or parts of such a sequence, can be implemented in a parallel architecture comprising several processors executing parts of different sequences concurrently. Fig. 8 illustrates a typical control object and data view 800 according to the invention. First data view 810 depicts one view of acquired measured data. Second data view 812 depicts a second view of acquired measured data. Third data view 814 depicts a third view of acquired measured data. In an embodiment of the present invention, third data view 814 is a smaller version of first data view 810. Fourth data view 816 depicts a fourth data view of acquired measured data. In an embodiment of the present invention, fourth data view 816 is a smaller version of second data view 812. Control object view 820 depicts and provides clickable buttons, such as acquire data button 822, store data button 824, and view data button 826, displayed on the client's display device and usable via the keyboard 570 or pointing device 575 of the client 112, 114. In an embodiment of the present invention, a user could send a control object command to acquire data by selecting acquire data button 822 with keyboard 570 or pointing device 575. In an embodiment of the present invention, a user could send a control object command to store data by selecting store data button 824 with keyboard 570 or pointing device 575. In an embodiment of the present invention, a user could send a control object command to view data by selecting view data button 826 with keyboard 570 or pointing device 575. The invention has been explained with reference to a specific embodiment. Other embodiments will be apparent to those of ordinary skill in the art. It is therefore not intended that this invention be limited, except as indicated by the appended claims.

Claims: WHAT IS CLAIMED IS: 1. A method for synchronized acquisition, processing and sharing of instrumentation data from at least one remote instrument coupled to at least one server and for synchronized control of devices including said instruments in a client-server network, said client-server network comprising at least one client, at least one server, and a communications medium connecting each of said client to each of said server, said method comprising the steps of: responsive to input from a user at said client, transmitting, from at least one of said server to said client, a selected software control object associated with a selected said instrument; thereafter displaying a graphical representation of a functionality of said selected software control object on a display device of said client; responsive to input from said user to said selected software control object, acquiring said instrumentation data from said selected instrument; responsive to input from said user to said selected software control object, storing said instrumentation data in a designated computer storage medium; responsive to input from said user to a selected device driver associated with said selected instrument via said selected software control object, sending said instrumentation data to said display device of said client for presentation to said user; responsive to input from said user to said selected software control object, presenting a graphical representation of said instrumentation data on said display device of said client to said user; managing said selected software control object at least for controlling a defined behavior of said selected software control object; and interfacing said selected software control object to said selected instrument via said client-server network and a device driver manager in each one of said server. 2. The method of claim 1 wherein said software control object comprises a software object responsive to at least one input command to produce at least one output command based on a defined behavior of said software object. 3. The method of claim 1 wherein said software control object comprises a software object responsive to at least one input command to generate at least one set of data based on a defined behavior of said software object. 4. The method of claim 1 wherein said transmitting step comprises conveying an electronic copy of a user interface module corresponding to said selected software control object via said client-server network from said server to said client, said selected software control object having been previously selected by said user. 5. The method of claim 1 wherein said displaying step comprises presenting said graphical representation corresponding to said functionality of said selected software control object under control of a network browser on said display device of said client. 6. The method of claim 1 wherein said acquiring step comprises gathering said instrumentation data directly from said selected instrument. 7. The method of claim 1 wherein said acquiring step comprises retrieving said instrumentation data from said designated computer storage medium, said designated computer storage medium being at said server. 8. The method of claim 1 wherein said storing step comprises storing said instrumentation data in said designated computer storage medium, said designated computer storage medium being at said server. 9. The method of claim 1 wherein said storing step comprises storing said instrumentation data in said designated computer storage medium, said designated computer storage medium being at said client. 10. The method of claim 1 wherein said sending step comprises conveying said instrumentation data via said client- server network from said server to said client. 11. The method of claim 1 wherein said presenting step comprises displaying said graphical representation corresponding to said instrumentation data under control of a network browser on said display device of said client. 12. The method of claim 1 wherein said presenting step comprises controlling a timing sequence of said presenting step. 13. The method of claim 1 wherein said managing step comprises creating said selected software control object. 14. The method of claim 1 wherein said managing step comprises deleting said selected software control object. 15. The method of claim 1 wherein said managing step comprises altering at least one characteristic of said selected software control object. 16. The method of claim 1 wherein said interfacing step comprises responding to at least one real-time event in said selected instrument. 17. The method of claim 1 wherein said interfacing step comprises controlling at least one setting within said selected instrument. 18. The method of claim 1 further comprising controlling a timing sequence of said interfacing step. 19. The method of claim 5 wherein said network browser is optimized for presenting said graphical representation corresponding to said functionality of said selected software control object on said display device of said client. 20. The method of claim 11 wherein said network browser is optimized for displaying said graphical representation corresponding to said instrumentation data on said display device of said client. 21. An apparatus for synchronized acquisition, processing and sharing of instrumentation data from at least one remote instrument coupled to at least one server and for synchronized control of devices including said instruments in a client-server network, said client-server network comprising at least one client, at least one server, and a communications medium connecting each of said client to each of said server, said apparatus comprising: a transmitting module configured to transmit, responsive to input from a user at said client, from at least one of said server to said client, a selected software control object associated with a selected said instrument; a displaying module configured to display a graphical representation of a functionality of said selected software control object on a display device of said client; an acquiring module configured to acquire, responsive to input from said user to said selected software control object, said instrumentation data from said selected instrument; a storing module configured to store, responsive to input from said user to said selected software control object, said instrumentation data in a designated computer storage medium; a sending module configured to send, responsive to input from said user to a selected device driver associated with said selected instrument via said selected software control object, said instrumentation data to said display device of said client for presentation to said user; a presenting module configured to present, responsive to input from said user to said selected software control object, a graphical representation of said instrumentation data on said display device of said client to said user; a managing module configured to manage said selected software control object at least for controlling a defined behavior of said selected software control object; and an interfacing module configured to interface said selected software control object to said selected instrument via said client-server network and a device driver manager in each one of said server. 22. The apparatus of claim 21 wherein said software control object comprises a software object responsive to at least one input command to produce at least one output command based on a defined behavior of said software object. 23. The apparatus of claim 21 wherein said software control object comprises a software object responsive to at least one input command to generate at least one set of data based on a defined behavior of said software object. 24. The apparatus of claim 21 wherein said transmitting module comprises a conveying module configured to convey an electronic copy of a user interface module corresponding to said selected software control object via said client-server network from said server to said client, said selected software control object having been previously selected by said user. 25. The apparatus of claim 21 wherein said displaying module comprises a presenting module configured to present said graphical representation corresponding to said functionality of said selected software control object under control of a network browser on said display device of said client. 26. The apparatus of claim 21 wherein said acquiring module comprises a gathering module configured to gather said instrumentation data directly from said selected instrument. 27. The apparatus of claim 21 wherein said acquiring module comprises a retrieving module configured to retrieve said instrumentation data from said designated computer storage medium, said designated computer storage medium being at said server. 28. The apparatus of claim 21 wherein said storing module comprises a storing module configured to store said instrumentation data in said designated computer storage medium, said designated computer storage medium being at said server. 29. The apparatus of claim 21 wherein said storing module comprises a storing module configured to store said instrumentation data in said designated computer storage medium, said designated computer storage medium being at said client. 30. The apparatus of claim 21 wherein said sending module comprises a conveying module configured to convey said instrumentation data via said client-server network from said server to said client. 31. The apparatus of claim 21 wherein said presenting module comprises a displaying module configured to display said graphical representation corresponding to said instrumentation data under control of a network browser on said display device of said client. 32. The apparatus of claim 21 wherein said presenting module comprises a controlling module configured to control a timing sequence of said presenting module. 33. The apparatus of claim 21 wherein said managing module comprises a creating module configured to create said selected software control object. 34. The apparatus of claim 21 wherein said managing module comprises a deleting module configured to delete said selected software control object. 35. The apparatus of claim 21 wherein said managing module comprises an altering module configured to alter at least one characteristic of said selected software control object. 36. The apparatus of claim 21 wherein said interfacing module comprises a responding module configured to respond to at least one real-time event in said selected instrument. 37. The apparatus of claim 21 wherein said interfacing module comprises a controlling module configured to control at least one setting within said selected instrument. 38. The apparatus of claim 21 further comprising a module for controlling a timing sequence of said interfacing module. 39. The apparatus of claim 25 wherein said network browser is optimized for presenting said graphical representation corresponding to said functionality of said selected software control object on said display device of said client. 40. The apparatus of claim 31 wherein said network browser is optimized for displaying said graphical representation corresponding to said instrumentation data on said display device of said client.

Inventors: CHIN RICHARD, GRUNWALD SORIN, SO MASSERATI H, CHIN, RICHARD, GRUNWALD, SORIN, SO, MASSERATI, H.
Applicants: BOSTON SCIENT LTD, CHIN RICHARD, GRUNWALD SORIN, SO MASSERATI H, BOSTON SCIENTIFIC LIMITED, CHIN, RICHARD, GRUNWALD, SORIN, SO, MASSERATI, H.
Application year: 1998
Main classification: G06F9
IPC codes: G06F9, G06F17, G06Q50