WO2002038030A2

WO2002038030A2 - Method and apparatus for ultrasonic data acquisition and transfer in real-time

Info

Publication number: WO2002038030A2
Application number: PCT/IL2001/001043
Authority: WO
Inventors: Alex Passi; Garri Passi
Original assignee: Sonotron Ltd.
Priority date: 2000-11-08
Filing date: 2001-11-08
Publication date: 2002-05-16
Also published as: WO2002038030A3; AU2002223988A1

Abstract

An ultrasonic data acquisition apparatus (10) and transfer in real-time. The apparatus (10) has a server computer (14) connected to on-site ultrasonic data acquisition hardware (12) and a communications medium. The server computer (14) comprises residential communication software and on-site data acquisition software for interacting with and communicating the ultrasonic data from the ultrasonic data acquisition hardware. The apparatus further comprises a client computer (20) that is electronically connected to the same communications medium as the server computer (14). The client computer (20) includes data acquisition and processing software, which enables it to interact with and access the ultrasonic data from the ultrasonic data acquisition hardware, in real time. The method converts ultrasonic data acquired by the data acquisition hardware to command packets, which define, prioritize and configure the ultrasonic data for interaction with a client program. These command packets are small packets that are attached to digital data packets and are transferred in real time from the server computer (14), via the communications means, to the client computer (20). The data is subsequently displayed and can be interacted and controlled by the client computer (20).

Description

METHOD AND APPARATUS FOR ULTRASONIC

DATA ACQUISITION AND TRANSFER IN REAL-TIME

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is entitled to the benefit of U.S. Provisional Application No. 60/246,567, filed Nov. 8, 2000.

FIELD AND BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates, in general, to the field of ultrasonic diagnostics, and in particular, the present invention is of a method and apparatus for ultrasonic data acquisition and transfer in real-time.

2. Description of the Related Art

Ultrasonics refers to the science and technology that deal with the study and application of ultrasound, which generally relates to and involves acoustic frequencies above the range audible to the human ear, or above approximately 20,000 Hertz. Ultrasound is commonly produced by piezoelectric transducers, and it is used for nondestructive testing (NDT), and for the cleaning of fine machine parts and surgical instruments. In medicine, ultrasound devices are used to examine internal organs without surgery. Ultrasonic diagnostic systems refer to the art or practice of diagnosis based on ultrasound data.

Various methods and systems enabling communication between an ultrasonic diagnostic system and a remote location are known in the art. U.S. Pat. No. 5,715,823 (the '823 patent), which is fully incorporated herein by reference, claims several medical diagnostic ultrasound systems that enable a remote user to access and view diagnostic ultrasound images or diagnostic reports that are produced by and stored in a local system. The '823 patent has a number of shortcomings. First and foremost, all claimed systems are limited in that they can transmit to a remote location only such images or reports that are previously produced and stored in the local ultrasound system. The patent, in this light, fails to teach how ultrasonic images can be transferred to a remote location in real-time, that is simultaneously as ultrasonic data is being acquired on-site. Second, it is often desirable to provide the remote user, instead of an ultrasonic image or report, the ultrasonic "raw data", i.e. a stream of digital samples representing the received ultrasonic signal (for example, a digitized A-scan) that is the basis for producing the ultimate ultrasonic image or report. Sending such "raw data", rather than a fully processed ultrasound image or report, allows the remote user to manipulate, process and "fine-tune" the ultrasonic data on his/her own computer, thus eliminating the need to send control commands from the remote user's terminal to the local ultrasound system. Third, the '823 patent only teaches how a remote user will be able to view a control of the local ultrasound system, but does not teach how a remote user will be able to influence from his/her remote location the actual diagnostic process taking place in the local system. Fourth, the patent does not address the problem of verifying whether the remote user is at all authorized to access the data that is stored locally. Fifth, the patent does not provide any means for communication (vocal, textual or other) between the remote user and the operator of the on-site ultrasound system. And sixth, the '823 patent is limited by its claims to medical diagnostic ultrasound systems, whereas it would be desirable to provide a remote user access to non-medical diagnostic ultrasound systems, e.g. in the field of NDT

U.S. Pat. No. 5,851J 86, which is a division of the '823 patent, and which is fully incorporated herein by reference, teaches a method of acquiring over a communications network an ultrasonic image from a local ultrasound system by means of a remote computer. U.S. Pat. No. 5,891,035 which is a continuation-in-part of the '823 patent, and which is fully incorporated herein by reference, discloses a medical diagnostic ultrasound system which comprises browser software capable of remotely accessing images stored in an external database. Both patents come short of solving any of the disadvantages of the '823 patent listed hereinabove.

U.S. Pat. No. 5,897,498 which is also a continuation-in-part of the '823 patent, and which is fully incorporated herein by reference, discloses a medical diagnostic ultrasound system which includes electronic message software for sending and receiving electronic messages to and from sources external to the ultrasound system. This patent offers only a partial solution to the fifth problem described hereinabove in connection to the '823 patent, such that this invention provides an alternative means for communication between the remote user and the operator of the on-site ultrasound system. The patent does not teach how electronic messages can be sent in real-time, simultaneously as ultrasonic data is acquired and transferred to a remote location. The patent also does not offer solution to any of the other disadvantages listed hereinabove. Hence, it is desirable to provide a method and apparatus for ultrasonic data acquisition and transfer in real-time, devoid of the aforementioned limitations.

SUMMARY OF THE INVENTION

The present invention provides for a method and apparatus for ultrasonic data acquisition and transfer in real-time. The components, according to the present invention, include a server computer connected to on-site ultrasonic data acquisition hardware and a communications medium. The server computer comprises residential communication software and on-site data acquisition software for acquiring and transferring the ultrasonic data from the on-site ultrasonic data acquisition hardware to a remote location over the communications medium. The communications medium is furthermore connected electronically to a client computer. The client computer has data acquisition and processing software, which enables it to interact with and access the ultrasonic data from the on-site ultrasonic data acquisition hardware, in real-time, based on a software algorithm or computer executable code.

The method, according to the present invention, comprises a procedure whereby ultrasonic data acquired from the on-site ultrasonic data acquisition hardware is converted to command packets, which define, prioritize and configure the ultrasonic data for interaction with a client program. These command packets are small packets that are attached to digital data packets and are transferred in real time from the server computer, via the communications means, to the client computer. The data is subsequently displayed, and can be interacted with and controlled, by the client computer. Furthermore, data can be customized by both the on-site operator and the remote user, such that relevant data only is transferred to the remote user. A further embodiment of the present invention enables the verification of the remote user, for security purposes.

A further embodiment of the present invention provides a plurality of end users (operators, remote users, etc.) the means to communicate with each other and with the on-site operator using text-based messages, audio messages, multimedia messages or audio-visual conferencing means, in real-time, as data is being acquired on-site and transferred to the remote location.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is herein described, by way of example only, with reference to the accompanying drawings. With specific reference now to the drawings in detail, it is stressed that the particulars shown are by way of example and for purposes of illustrative discussion of the preferred embodiments of the present invention only, and are presented in the cause of providing what is believed to be the most useful and readily understood description of the principles and conceptual aspects of the invention. In this regard, no attempt is made to show structural details of the invention in more detail than is necessary for a fundamental understanding of the invention, the description taken with the drawings making apparent to those skilled in the art how the several forms of the invention may be embodied in practice.

In the drawings:

FIG. 1 is a block diagram illustrating a preferred embodiment of an apparatus for ultrasonic data acquisition and transfer in real-time, according to the present invention;

FIG. 2 is a flowchart illustrating the method of operation of the preferred embodiment of the present invention; FIG. 3 is a flowchart illustrating a real-time data processing algorithm according to the present invention.

DETAILED DESCRIPTION OF THE INVENTION

The present invention relates to a system and method for ultrasonic data acquisition and transfer in real-time.

The following description is presented to enable one of ordinary skill in the art to make and use the invention as provided in the context of a particular application and its requirements. Various modifications to the preferred embodiment will be apparent to those with skill in the art, and the general principles defined herein may be applied to other embodiments. Therefore, the present invention is not intended to be limited to the particular embodiments shown and described, but is to be accorded the widest scope consistent with the principles and novel features herein disclosed.

Specifically, the present invention can be used to acquire and transfer a stream of digital data representing ultrasonic data, between two locations in real-time.

The principles and operation of a system and a method according to the present invention may be better understood with reference to the drawings and the accompanying descriptions, it being understood that these drawings are given for illustrative purposes only and are not meant to be limiting.

Referring now to FIG. 1, an apparatus 10 for ultrasonic data acquisition and transfer in real-time, constructed in accordance with the principles of the present invention, will be described. Apparatus 10 comprises on-site ultrasonic data acquisition hardware 12, a server computer 14, a client computer 20 and a communications medium 30. On-site data acquisition hardware 12 is coupled to server computer 14. Server computer 14 can be any suitable computer, for example, a standard personal computer (such as an IBM-compatible PC) operated with a conventional operating system (such as Microsoft® Windows® 98). Server computer 14 further includes an installation of on-site data acquisition software 16 ("server program") and resident communication software 18 ("RCS").

The server program comprises a computer executable code (software code) that enables the receiving of all ultrasonic data acquired by the on-site data acquisition hardware. The server program checks if there is a client request from an authorized client, and if there is, the server computer transfers the data, via the communications medium, to the client. The server also verifies with the client that data was received correctly, and acts to maintain communications and rectify communication problems. The server program also checks data relevance against a table of rules or preferences, subsequently filtering the original data and producing from the relevant data command packets. These packets are subsequently transferred to the client.

The RCS is likewise a computer executable code (software code), wherein its function is to enable the establishing of a communication channel between the server and the communications medium. Optionally, the RCS functionality can be incorporated in the server program, such that the server program can be programmed to establish an Internet connection independently of RCS. However, in reality it is easier for the programmer to keep the part responsible for the Internet connection external to the server program. This may be compared to a user of a PC, wherein an Internet connection is not a feature of the word processing software (such as MS- Word), such that the sending of MS-Word files to a mail recipient would rely on an external communications program. Client computer 20 can also be any suitable computer, for example, a computer similar to server computer 14. Client computer further includes an installation of data acquisition and processing software 22 ("client program"). The client program enables receiving of data from the server, and the subsequent preparation of the data, including extracting and configuring of the command packets, such that the relevant ultrasonic data can be displayed on the client computer.

Both server computer 14 and client computer 20 have access to communications medium 30. The Internet is currently the preferable communications medium, since it offers cheap, readily available and easily accessible means for communication, although any non-Internet communications medium, such as a wide area network (WAN), a local area network (LAN), or a point-to-point channel is also within the scope of the present invention.

Referring now to FIG. 2 (and still referring to FIG. 1), the method of operation of apparatus 10 will be described. An on-site operator runs RCS 18 (step 42) on the server computer. When RCS is ranning, an RCS icon is added to the Windows Taskbar and keeps running in the background. A right-click on the RCS icon opens up a menu, currently with three options: first, the on-site operator can add an e-mail address, pager account, cellular telephone number, Instant Messaging (IM) address, SMS address or other electronic address of a remote expert, for subsequent communications (including audio messages, multimedia messages or audio-visual conferencing means); second, the operator can enable or disable the Internet communication feature without exiting RCS; and third, the operator can exit RCS.

When the Internet communication feature of RCS is enabled (whether by default or by an action of the on-site operator), RCS establishes a connection (step 44) between the server computer and communications medium 30. As mentioned heretofore, the Internet is the preferable communications medium. When establishing an Internet connection, any known type of such connection can be implemented including, for example, modem connection through an Internet service provider (ISP), LAN connection, or WAP (wireless Internet protocol) connection. Preferably, TCPMP protocol will be used for Internet communication in order to achieve a steady Internet connection between the server and client computers, although any other known communication protocol can similarly be implemented. Obviously, if the server computer is already connected to the Internet at the time RCS is executed, then RCS will skip the step of establishing an Internet connection.

Following the establishing of a communications connection, the operator runs server program 16, or alternatively RCS is programmed to cause server program 16 to run (step 46). When the server program is running, RCS 18 establishes a connection with it using internal Windows messaging. RCS then informs server program 16 (step 48) that a connection to communications medium 30 has been established, and requests an access code for the remote expert.

Server program 14 generates a unique access code, such as a random numerical string or password, and sends it (step 50) back to RCS 18. In order to restrict unauthorized access to ultrasonic data acquired by on-site ultrasonic data acquisition hardware 12, this access code may be valid only during the current session of the server program. The RCS then sends an electronic message (step 52), or some other type of message, to the predetermined electronic address (e.g. e-mail address, pager account, cellular telephone number, or other address of a remote expert), which was fed to RCS. The electronic message contains access information including the current unique access code and the current IP address (Internet protocol address) of server computer 14. In addition, RCS 18 commands server program 16 to open a listening socket (step 54) over communications medium 30. In order to allow Internet connectivity with a computer that is behind a firewall, the server program will preferably listen on port 80 (HTTP port).

Upon receiving the electronic message containing access information, the remote expert runs client program 22 (step 56) on client computer 20 and feeds it with the received access information. Client program 22 establishes a connection (step 58) between client computer 20 and communications medium 30 (as explained in step 44 hereinabove). The client program then sends, through communications medium 30, a connection request to server computer 14 (step 60) based on the given access information. Server program 16 authenticates the access code sent in the connection request and, if authenticated, establishes a connection (step 62) with client computer 20. If the client program sends a wrong access code to the server program, the server will resume listening without further proceedings. The same will happen if the client program does not send an access code within a chosen unit of time (such as five seconds) after a connection request is issued. Optionally, the server program can be programmed to exit automatically after a predetermined number of failed connection trials, or to issue messages warning the remote expert and the on-site operator of a wrong access code or of other failures during the connection process.

After a TCP/IP connection over communications medium 30 is established between the server and client computers, the server program starts to send command packets to the client program (step 64). Command packets contain all the information necessary for reconstructing, on the client computer, a comprehensible real-time picture of the ultrasonic data as the latter is being acquired by on-site ultrasonic data acquisition hardware 12. The command packets include, for example, information regarding the type of ultrasonic diagnostic application currently running on the server computer, the type of windows open in that application, any information typed or displayed in the open windows, any digitized ultrasonic data acquired or displayed in any such windows, and any other information regarding the current status of the server program. The command packets are sent to the client program inside data packets.

It is important to understand the difference between the term "command packet" and the term "data packet", as these terms are used in the description provided herein. A "command packet" is a group of digital data (for example, a group of 200 bytes), which contains a command that the client program understands and can execute on the client computer. For example, a simple command packet may contain the coordinates of several pixels that represent several ultrasonic samples (e.g. a portion of an A-scan), and instructions to the client program to draw these pixels in a certain window on the screen of the client computer. On the other hand, a "data packet" refers to a group containing one or more digital values (for example, a group of 200 bytes), which group is sent in a single transmittal event (i.e. without any intermission or break during transmittal) from one computer to another computer (e.g. from the server to the client, or vice versa) through the communications medium (e.g. the Internet). A single data packet may contain either a portion of a command packet, one complete command packet, or more than one command packet.

The purpose of each command packet is to break up and translate the relevant on-site data into small packets of data containing relevant commands or rules, that can be sent in frequent intervals to remote clients, in order to enable "real time" viewing of data on the client computer. The actual transfer from the on-site ultrasonic data acquisition hardware to a command packet is as follows: the server program, connected to the on-site data acquisition hardware, portrays whatever is being captured on-line. Each change in on-site data (such as the type of ultrasonic diagnostic application currently running on the server computer, the type of windows open in that application, any information typed or displayed in the open windows, any ultrasonic data acquired and digitized by the on-site data acquisition hardware and displayed in any such windows, and any other information regarding the current status of the server program) is compared to some rules table in order to establish the relevance of such a change. Each relevant change is considered by the server program as an event. The server program then filters the events according to a preferences table (containing user preferences for desired data types). Relevant events are subsequently converted by the server program to command packets, each command packet comprising a plurality of bits relating to the event, and a header containing the relevant rules governing the packet behavior. These additional rules may incorporate adding alternative commands to the pure data, such that the data is not simply displayed on the client computer, but is able to be automatically filtered, mapped, sized, matched, coded, etc., according to the remote user's preferences. The command packets are configured so as to be readily understood by the client program. For example, rules may be provided that tell the client program how to display the data contained in the command packet, whether to combine it with other command packets, what it represents, etc. These command packets are wrapped in data packets for transfer over a packet network using, for example, TCP/IP protocol. Any command packet that was divided up into several data packets, for data transfer using TCP/IP, is re-assembled on the client side, using the client program (this procedure will be explained in further detail hereunder). This entire process enables the filtering and transfer of ultrasonic data in real time. Client program 22 receives the data packets sent by server program 16, extracts the command packets from the data packets in real-time, as each data packet arrives, and immediately executes each command packet that has arrived (step 66). Thus, a digital representation of the ultrasonic diagnostic data acquired on-site, is received in real-time by client computer 20. This data may be displayed on the client computer in a display format predetermined according to the remote user's preferences. A typical display preference is in a format that is identical to the display on server computer 14. In this example, the server program identifies the type of display of the original data, and forwards this information in the command packets, so that the receiving client program is able to display the data in a similar form. In such cases where the remote user chooses to view transferred data in a format that is identical to that which is displayed locally on the server computer, it is necessary that the client program include an updated set of applications and interfaces that are installed in the server computer, and are of interest to the client user. In addition to presenting the transferred data on a visual display, this data can be stored on client computer 20, printed using a printer coupled to client computer 20, or otherwise transferred to or presented on any known media.

The procedure in which the server program sends the client program "data packets" carrying "command packets", will now be explained in greater detail. As mentioned previously, command packets sent by the server program to the client program may include data such as: the type of ultrasonic diagnostic application currently running on the server computer; the type of windows open in that application; any information typed or displayed in the open windows; any digitized ultrasonic data acquired or displayed in any such windows; and any other information regarding the current status of the server program.

The client program comprises a set of applications and interfaces, which include components that are operable with all relevant applications and windows that exist on the server computer. Thus, the client program can load and display an appropriate window according to command packets received from the server program.

In general, windows which may be open in an ultrasonic diagnostic application on the server computer can be categorized into three groups: irrelevant windows; static information windows; and dynamic windows.

"Irrelevant windows" are windows which are not relevant or of no interest to a remote expert, and therefore are not sent to the client computer. If such a window is loaded on the server computer, the server program will send a command that will cause the client program to display on the client computer a label describing the current status of the server computer, for example, "listening". When an irrelevant window is unloaded, the server program sends a command that causes the client to remove this label. In this way, the client computer does not receive windows and content defined by the remote user as being irrelevant, and in their place, the remote user receives some notification that an irrelevant window has been left out. Under the category of "irrelevant windows" there may be included, for example, windows involving preliminary calibration procedures of an ultrasonic scanning probe which is part of on-site ultrasonic data acquisition hardware 12. Preferably, the definition of the windows that are considered "irrelevant" can be changed by the on-site operator or the remote user, according to his/her current needs. For example, if the on-site operator is currently seeking help from a remote expert during a probe calibration procedure, s/he will be able to enter a "Preferences" menu in the server program and add the "probe calibration" window to a list of "relevant windows" that determines which windows will be transferred to the client computer. In this way, both the on- site operator and the remote expert can define the relevance of windows, and thereby customize user sessions in order to work with relevant data only. Ultimately, this feature improves the speed of communication between the on-site and remote computers by avoiding transfer of irrelevant data.

"Static information windows" are windows whose content can be changed by the on-site operator, but cannot be influenced by data arriving from the on-site ultrasonic data acquisition hardware 12. These, for example, are windows with set menus that may be changed by the on-site operator, but where changes registered by the on-site ultrasonic data acquisition hardware do not have an impact. If such a window is loaded on the server computer, the server program will send a command that will cause the client program to display a window in the appropriate window format. In addition, the server program will send to the client all data displayed in the window. Each time the on-site operator changes a parameter in such a loaded window, the server program sends, in real-time, a command packet containing the name of the display control which has been changed along with the changed parameter. If such a window is unloaded, the server program will send the client a command to unload the window.

"Dynamic windows" are windows whose content can be changed not only by the on-site operator, but also based on data arriving from the on-site ultrasonic data acquisition hardware 12. These windows are predetermined as being windows that are connected to a source of dynamic data and that have the potential for accepting new data at any time. Consequently, if the data on-site changes (for example, if on-site data acquisition hardware has received a reflection of an ultrasonic signal from an object under evaluation), this change will automatically be detected by the server program, and subsequently in the client program, such that changes are noted by the remote user in real time.

Following is an example of the communication protocol between the server and client programs, for two types of "dynamic" windows which are part of ISONIC™ ultrasonic diagnostics system by Sonotron NDT Ltd. of Rehovot, Israel: "Pul\Rec" (pulser-reeeiver) window and "Imaging" window.

"Pul\Rec" Window is a dynamic window which displays an A-scan signal acquired by on-site ultrasonic data acquisition hardware 12, and further enables the on-site operator to define various parameters regarding the ultrasonic inspection such as: ultrasonic velocity in the object under examination, ultrasonic signal range, probe delay, display delay, gates, etc. When this dynamic window is loaded on the server computer, the server program sends a command that causes the client program to load a corresponding "PulVRec" window on the client computer. Each time the on-site operator changes a parameter in this window on the server computer, the server program sends to the client program a command including the name of the display control changed by the on-site operator, as well as the new parameter. Data arriving from on-site ultrasonic data acquisition hardware 12 (e.g. an ultrasonic A-scan signal, probe location, etc.) is acquired by the server program, for example, every 100 milliseconds, and is sent in real-time (in the form of one or more command packets) to the client program. Let us consider, for example, that the ultrasonic diagnostic application running on the server computer represents a given ultrasonic signal (e.g. time domain, frequency domain or other) using 200 coordinates, and each coordinate is within a range of 0 to 255 (e.g. each coordinate represents an amplitude value from 0 to 255). In the latter example, a given ultrasonic signal can be represented by a single command packet that is on the order of only a few hundred bytes: a few bytes represent the number of bytes contained in the command packet, 200 bytes represent the ultrasonic signal coordinates, and a few more bytes may include additional instructions to the client program regarding how to display the data. Simultaneously, as the client receives commands from the server, the client program starts to display on the screen of the client computer a corresponding window (i.e. a "PulVRec" window) on which additional incoming data, such as the ultrasonic signal, which is being acquired in real-time, is plotted. When the "PulVRec" window is unloaded in the server computer, the server program sends to the client program a command to unload the "PulVRec" window accordingly.

It is a particular feature of the present invention that the use of command packets of minimal size allows for real-time data transfer from the server program to the client program, even over a slow communications medium, such as current day cellular phone Internet connections.

"Imaging" window is a dynamic window which displays an image of the object under examination (for example, based on the dimensions of the object as predefined by the on-site operator), an image of the scanning pattern of the ultrasonic probe as the probe is manipulated (either manually, by the on-site operator or automatically, for example, by a step-motor actuator), and further displays the location of flaws as they are detected by the system. When this dynamic window is loaded on the server computer, the server program sends a command that causes the client program to load a corresponding "Imaging" window on the client computer. The server program then sends commands containing data, such as the dimensions of the object under test, the scale and the scanning pattern. Thus, the client program can draw an image of the object under examination on which imaging data is plotted simultaneously, as the imaging data is acquired on-site. If, for example, the scanning trajectory and detected flaws are plotted on the "Imaging" window of the server computer using rectangles, then accordingly, the server program will send to the client program commands including the coordinates of such rectangles. The server program keeps track of all rectangles plotted on the "Imaging" window, and transfers updated data to the client computer in real-time. Finally, when the "Imaging" window is unloaded, the server program sends the client program a command to unload this window.

As mentioned heretofore, the present invention supports Internet connection via wireless phone. As of today, a cellular phone Internet connection is often slow and unstable. In order to transfer data over such a phone connection, it is a particular feature of apparatus 10 that it is capable of recognizing and dealing with partial command packets, joined command packets (i.e. more than one complete command packet in a single data packet) and invalid or incomprehensible packets. The present invention, through the sending of command packets inside of data packets, enables an adequate quantity of data to be transferred to the client in rapid sessions such that the user receives changes and updates to ultrasonic data in real time. An example of a command packet size that enables such an efficiency of data transfer is 200 bytes.

The present invention provides the above features by following these principles: the first two bytes of each command packet represent the length of the command packet, i.e. the total number of bytes in the command packet; every discrete command packet is processed only when it has fully arrived at the client program; invalid packets are ignored unless the packet is crucial for correct operation, in which case the client program will send the server program a request to resend that packet.

Referring now to FIG. 3, the real-time data processing algorithm 300 executed by the client program according to the present invention, will be explained in detail. As mentioned hereinabove, TCPVIP protocol is preferably used for communication between the server and client computers, although any other known communication protocols are also within the scope of the present invention. TCPVIP ensures that data sent by the server program is arranged in the client computer in the order in which it was sent. According to the present invention, every data packet that arrives at the client computer causes the client program to open a new DataArrival event. In each DataArrival event, incoming data is stored in one of currently three buffer memory addresses: IncomingBytes array (IB), which contains bytes that need to be processed; ResidualBytes array (RB), which contains bytes that have remained from a previous DataArrival event; and PacketBytes (PB) array, which contains a complete command packet to be executed in the client computer.

When a DataArrival event starts, IB is filled with the bytes of the incoming data packet (step 302). The client program then checks if RB is empty (step 304). If RB is not empty, meaning that residual bytes have remained from a previous DataArrival event, then the bytes of RB are copied into the beginning of IB (step 306); RB is then cleared (step 307) and the client program proceeds to step 314. If RB is empty, then the Client Program will check if the number of bytes in array IB equals one (step 308). As mentioned hereinabove, the first two bytes in every command packet represent the length of, or the number of bytes in, the command packet. If only one byte has arrived in the current DataArrival event, and no bytes have remained from a previous DataArrival event (since in step 304 RB was found to be empty), then obviously the single byte in IB cannot contain a complete command; in fact, in such a case IB does not even contain the length of the command packet, which as already mentioned, consists of two bytes. If so, then IB will be copied into residual bytes array RB (step 310) and the current DataArrival event will end (step 312).

If, however, IB contains more than one byte, then the client program will set L to equal the length of, or number of bytes in, the command packet (step 314). More precisely, the client program reads the value of the first two bytes in the packet (which, as already mentioned, represent the number of bytes in the command packet immediately following these two bytes) and sets L to equal this value. The computer then checks if L is smaller than the actual number of bytes in IB (step 316). If L is smaller than the actual number of bytes, it means that the data packet does not contain a complete command packet; in other words, one or more bytes belonging to the command packet have not yet arrived. In this case, the bytes in IB are copied into RB (step 310) and the current DataArrival event ends (step 312).

If L is equal to the number of bytes in IB, it means that IB contains exactly one complete command packet. If L is greater than the number of bytes in IB, it means that IB contains a complete command packet and then some more bytes. In both cases, PB is filled with the command packet bytes (i.e. the first L bytes in IB) and, accordingly, these bytes are removed from IB (step 318). Obviously, if L is exactly equal to the number of bytes in IB, then IB will be empty after the removal of the command packet bytes (see step 328 hereunder).

Following, the client program checks if PB contains a valid, comprehensible command packet (step 320). If PB is invalid, then the client program checks if the command packet is critical, based on predefined criteria (step 322). These criteria may be hardwired into the client program or elected at any time by marking user preferences using the client program interface. Command packets that are considered critical may include, for example, command packets that contain information regarding the type of application or window loaded on the server computer, or dimensions of the object under examination in an "Imaging" window, as well as any other essential information. An example of command packets that may be considered non-critical, and as such may be ignored, are command packets containing digital samples representing a negligible portion of an A-scan, i.e. a portion of a received ultrasonic signal containing a number of digital samples that is smaller than a predefined critical length.

Returning now to step 322, if the command packet is found to be critical, then IB will be cleared (step 324), the client program will send a "resend" request to the server program (step 325), and the current DataArrival event will end (step 312). If PB is invalid but non-critical then the client program will ignore it and proceed to step 328. On the other hand, if PB is valid then the client computer will immediately execute the process command contained in it (step 326).

It is a particular feature of the present invention that each incoming command packet is executed immediately upon completion of its arrival, to the effect that the remote user receives on-site ultrasonic data in his own remote computer in real-time, as the ultrasonic data is being acquired; in other words, ultrasonic data is transferred to the remote user as early as immediately after the on-site ultrasonic scanning procedure starts.

Finally, the client program checks if IB has now remained empty (step 328), and if so the DataArrival event ends (step 312). If IB is not yet empty, then the computer returns to step 308, and repeats data processing algorithm 300 from there. Thus, the present invention enables a remote expert to view ultrasonic data in real-time, as it is acquired on-site. In addition, client computer 20 can store the incoming ultrasonic data, thus enabling a remote expert to retrieve the stored data for further off-line processing, to send the processed data back to the server computer or to a third location, as well as to print or otherwise output the data to any form of tangible or intangible media.

At any stage after a connection between server program 16 and client program 22 is established, apparatus 10 enables the remote expert to compose text or multimedia messages on client computer 20 which are sent by client program to server computer 14 via communications medium 30, so that the on-site operator can read, listen to or view them. Likewise, the on-site operator can compose text or other messages on the server computer, which are subsequently sent by the server program to the client computer for the remote expert to read, listen to or view. The server program and client program can further include any known audio and video conferencing capabilities to further facilitate communication between the end users.

Hence, the present invention enables an on-site operator to consult with a remote expert, and the remote expert to monitor and control an ultrasonic diagnostic process and to provide professional guidance and opinion to the on-site operator, all in real-time.

The present invention eliminates the need of prior art ultrasonic data transfer mechanisms to first store acquired ultrasonic data on-site, before it can be accessed by a remote user. The present invention provides the remote user not only an exact copy of the display or image produced on-site, but also the actual "raw data" (e.g. digitized A- scan). This feature allows the remote user to process and "fine-tune" the digitized ultrasonic data on his or her own computer, and reduces the dependency of the remote user on the on-site operator.

The present invention further provides a plurality of end users (operators, remote users etc.) the means to communicate with each other using text-based messages (such as email, SMS, IM, chat, peer2peer etc.), audio messages, multimedia messages or audio-visual conferencing means, in real-time, optionally together with the ultrasound data which is being acquired on-site and being transferred to the remote location. This feature increases the ability of a remote user to influence from his remote location the actual diagnostic process taking place on-site, and likewise, increases the ability of an on-site operator to consult with a remote expert on-line.

The present invention ensures system security by limiting access to on-site data to authorized remote users only. Security may be further improved by automatically changing the access code at each new session of the server program.

As opposed to prior art systems, the present invention is not limited to the field of medical diagnostic ultrasound systems, and may be applied in any other ultrasonic diagnostic environment, such as ultrasonic NDT.

Although the invention has been described in conjunction with specific embodiments thereof, it is evident that many alternatives, modifications and variations will be apparent to those skilled in the art. Accordingly, it is intended to embrace all such alternatives, modifications and variations that fall within the spirit and broad scope of the appended claims. All publications, patents and patent applications mentioned in this specification are herein incorporated in their entirety by reference into the specification, to the same extent as if each individual publication, patent or patent application was specifically and individually indicated to be incorporated herein by reference. In addition, citation or identification of any reference in this application shall not be construed as an admission that such reference is available as prior art to the present invention.

Claims

WHAT IS CLAIMED IS:

1. An apparatus for transferring, in real time, ultrasonic data from a first location to a second location, comprising: a- ultrasonic data acquisition hardware for acquiring ultrasonic data in the first location; b- a mechanism for transferring, in real time, said ultrasonic data, acquired by said ultrasonic data acquisition hardware, to the second location.

2. The apparatus of claim 1, wherein said ultrasonic data acquired comprises at least a portion of a digitized A-scan.

3. The apparatus of claim 1, wherein said mechanism further comprises: a- a communications medium for enabling transfer of digital data; b- a first computer coupled to said ultrasonic data acquisition hardware and having access to said communications medium; c- a second computer having access to said communications medium; and d- a computer executable code for generating and transferring, in real time, a digital representation of said ultrasonic data acquired by said ultrasonic data acquisition hardware, from said first computer to said second computer over said communications medium.

4. The apparatus of claim 3, wherein said first computer further comprises On- site Data Acquisition Software, for executing said computer executable code, and Resident Communication Software, for initiating communication of said digital representation of said ultrasonic data.

5. The apparatus of claim 4, wherein said Resident Communication Software requires user authentication before enabling transfer of said digital representation of said ultrasonic data to said second location.

6. The apparatus of claim 3, wherein said second computer further comprises

Data Acquisition and Processing Software, for processing and displaying said digital representation of said ultrasonic data.

7. The apparatus of claim 3, wherein said computer executable code enables conversion of said digital representation of said ultrasonic data acquired by said ultrasonic data acquisition hardware, to at least one command packet, said at least one command packet being configured to enable display, in real time, of said ultrasonic data on said second computer.

8. The apparatus of claim 7, wherein said at least one command packet comprises at least a part of said digital representation of said ultrasonic data, and at least one configuration command.

9. The apparatus of claim 8, wherein said at least one configuration command is determined according to preferences of a user of said apparatus.

10. The apparatus of claim 3, wherein said computer executable code enables filtering of said digital representation of said ultrasonic data, said filtering being determined according to preferences of a user of said apparatus.

11. The apparatus of claim 3, further comprising a communications means for communicating between a user of said first computer and a user of said second computer.

12. The apparatus according to claim 11, wherein said communications means is selected from the group consisting of email, SMS, IM, chat, pager, voice, multimedia, video-conferencing and peer 2 peer communications means.

13. The apparatus of claim 3, further comprising a communications means for communicating between a plurality of users of said apparatus.

14. The apparatus according to claim 13, wherein said communications means is selected from the group consisting of email, SMS, IM, chat, pager, voice, multimedia, video-conferencing and peer 2 peer communications means.

15. A method for enabling real-time ultrasonic data acquisition and transfer, comprising the steps of: a- acquiring ultrasonic data in a first location; b- digitizing said acquired ultrasonic data to produce a digital representation thereof; and c- transferring, in real-time, at least a portion of said digital representation of said acquired ultrasonic data to a second location, over a communications medium.

16. The method of claim 15, wherein said transferring procedure further comprises the steps of:

A. generating at least one digital command packet, said at least one digital command packet comprising at least a part of said digital representation of said acquired ultrasonic data and at least one configuration command; and

B. transferring, in real-time, said at least one digital command packet, to a second location.

17. The method of claim 16, further comprising:

C. processing said at least one digital command packet at said second location; and

D. displaying at least part of said digital representation of said acquired ultrasonic data, based on said at least one configuration command in said at least one digital command packet.

18. The method of claim 15, further comprising: d. displaying said at least a portion of digital representation in said second location.

19. The method of claim 15, further comprising the step of authenticating a user of the ultrasonic data.

20. The method of claim 15, wherein after the step of digitizing said ultrasonic data, filtering said digital representation according to preferences of a user of the ultrasonic data.

21. The method of claim 15, further comprising the step of providing means for communications between users of said ultrasonic data.

22. The method according to claim 21, wherein said means for communications is selected from the group consisting of email, SMS, IM, chat, pager, voice, multimedia, video-conferencing and peer 2 peer communications means.

23. A method for transferring digital data representing ultrasonic data acquired in a first location, to a second location, over a communications medium, the method comprising the steps of: i. forming in real time at least one command packet, said command packet representing: a. at least a portion of the digital data representing ultrasonic data acquired in the first location, and b. rules to display said packet according to preferences of a user; ii. placing in real time said at least one command packet within at least one data packet; and iii. transferring in real time said at least one data packet from said first location to said second location over said communications medium.

24. The method of claim 23, further comprising the step of checking whether a user at said second location is authorized, based on predetermined criteria.