[emblem:] WIPO/OMPI
`
`G06F 13/38
`
`A1
`
`PCT World International Patent Organization
`
`International office
`International patent application published according to the Patent Cooperation Treaty (PCT)
`(51) International patent classification6:
`(11) International publishing number: WO 98/39710
`
`
`(43) International
`publishing date: September 11, 1998 (09/11/98)
`(81) Designated states: AL, AM, AT, AU, AZ, BA, BB, BG,
`BR, BY, CA, CH, CN, CU, CZ, DE, DK, EE, ES, FI, GB, GE,
`GH, HU, IL, IS, JP, KE, KG, KP, KR, KZ, LC, LK, LR, LS,
`LT, LU, LV, MD, MG, MK, MN, MW, MX, NO, NZ, PL, PT,
`RO, RU, SD, SE, SG, SI, SK, SL, TJ, TM, TR, TT, UA, UG,
`US, UZ, VN, YU, ZW. ARIPO Patent (GH, GM, KE, LS,
`MW, SD, SZ, UG, ZW) Eurasian Patent (AM, AZ, BY, KG,
`KZ, MD, RU, TJ, TM), European Patent (AT, BE, CH, DE,
`DK, ES, FI, FR, GB, GR, IE, IT, LU, MC, NL, PT, SE), OAPI
`patent (BF, BJ, CF, CG, CI, CM, GA, GN, ML, MR, NE, SN,
`TD, TG).
`
`Published:
`With international research report.
`Prior to expiration of the term permitted for amended
`claims. If amendments are made, the publication will
`be repeated.
`
`
`
`
`
`
`(21) International reference: PCT/EP98/01187
`
`(22) International filing date: March 3, 1998 (03/03/98)
`
`(30) Priority data:
`197 08 755.8 March 4, 1997 (03/04/97) DE
`
`
`(71)(72) Applicant and inventor: TASLER, Michael
`[DE/DE]; Cronthalstr. 6c, D-97074 Würzburg (DE).
`
`(74) Representative: SCHOPPE, Fritz; Kanzlei Schoppe &
`Zimmermann, P.O. Box 71 08 67, D-81458 Munich (DE)
`
`
`
`
`(54)
`
`Title: FLEXIBLE INTERFACE
`
`ZTE (USA) 1004, Page 1/34
`
`

`
`
`
`
`
`[bilingual]
`
`FOR INFORMATION PURPOSES ONLY
`Codes for identifying PCT-contractually designated states on the letterheads of publications publishing international applications
`according to PCT.
`
`
`AL
`AM
`AT
`AU
`AZ
`BA
`BB
`BE
`BF
`BG
`BJ
`BR
`BY
`CA
`CF
`CG
`CH
`CI
`CM
`CN
`CU
`CZ
`DE
`
`Albania
`Armenia
`Austria
`Australia
`Azerbaijan
`Bosnia-Herzegovina
`Barbados
`Belgium
`Burkina Faso
`Bulgaria
`Benin
`Brazil
`Belarus
`Canada
`Central African Republic
`Congo
`Switzerland
`Ivory Coast
`Cameroon
`China
`Cuba
`Czech Republic
`Germany
`
`DK
`EE
`ES
`FI
`FR
`GA
`GB
`GE
`GH
`GN
`GR
`HU
`IE
`IL
`IS
`IT
`JP
`KE
`KG
`KP
`
`KR
`KZ
`
`Denmark
`Estonia
`Spain
`Finland
`France
`Gabon
`United Kingdom
`Georgia
`Ghana
`Guinea
`Greece
`Hungary
`Ireland
`Israel
`Iceland
`Italy
`Japan
`Kenia
`Kyrgyzstan
`Democratic People’s Republic of
`Korea
`Republic of Korea
`Kazakhstan
`
`LC
`LI
`LK
`LR
`LS
`LT
`LU
`LV
`MC
`MD
`MG
`MK
`
`ML
`MN
`MR
`MW
`MX
`NE
`NL
`NO
`NZ
`PL
`
`St. Lucia
`Liechtenstein
`Sri Lanka
`Liberia
`Lesotho
`Lithuania
`Luxemburg
`Latvia
`Monaco
`Republic of Moldovia
`Madagascar
`The Former Yugoslav Republic
`of Macedonia
`Mali
`Mongolia
`Mauretania
`Malawi
`Mexico
`Niger
`Netherlands
`Norway
`New Zealand
`Poland
`
`PT
`RO
`RU
`SD
`SE
`SG
`SI
`SK
`SN
`SZ
`TD
`TG
`TJ
`TM
`TR
`TT
`UA
`UG
`US
`UZ
`VN
`YU
`ZW
`
`Portugal
`Romania
`Russian Federation
`Sudan
`Sweden
`Singapore
`Slovenia
`Slovakia
`Senegal
`Swaziland
`Chad
`Togo
`Tadzhikistan
`Turkmenia
`Turkey
`Trinidad and Tobago
`Ukraine
`Uganda
`United States of America
`Uzbekistan
`Vietnam
`Yugoslavia
`Zimbabwe
`
`ZTE (USA) 1004, Page 2/34
`
`

`
`WO 98/39710
`
`
`
`
`
`
`Flexible interface
`
`
`
`Description
`
`PCT/EP98/01187
`
`The present device relates to the transmission of data and particularly to interface devices for the
`communication between a computer or host device and a data transceiver, from which data shall
`be obtained and/or with which a bilateral communication shall occur.
`
`Data collection systems for computers are largely limited in their range of use. In general, they
`can be divided into two groups.
`
`In the first group host devices or computer systems are connected via an interface to a device,
`whose data shall be gathered. The interfaces of this group are commonly standard interfaces
`which can be used via particular driver software for various host systems. One advantage of
`these interface devices is given in that they are largely independent from the host device.
`However, it is disadvantageous here that they generally require very expensive drivers, which are
`susceptible to malfunction and limit the data transmission rate between the device connected to
`the interface and the host device, and vice versa. Further implementations of these interfaces for
`mobile systems are possible with difficulty only in some cases and the options for adaptations
`are low, resulting in these systems showing little flexibility.
`
`The devices from which data shall be gathered cover the entire bandwidth of electro-technology.
`For example, in one typical scenario it must be assumed that a customer who for example
`operates an X-Ray diagnostics device in the field of medical technology, reports an error. A
`service technician of the device manufacturer will then go to said customer and read the system
`protocol data prepared by the X-Ray diagnostics device, for example via a mobile computer or
`laptop.
`
`
`
`
`
`ZTE (USA) 1004, Page 3/34
`
`

`
`WO 98/39710
`
`
`2
`
`PCT/EP98/01187
`
`If then the error cannot be localized, it will be necessary for the service technician not only to
`read an error protocol file but also data from ongoing operation. It is obvious that here rapid data
`transmission as well as quick data analysis are necessary.
`
`Another case for using an interface can for example be the connection of an electronic measuring
`device, e.g., a multimeter, to a computer system, in order to transfer data measured by the
`multimeter to the computer. In particular in case of long-term measurements or when large data
`volumes develop it is necessary that the interface allows a high data transmission rate.
`
`From these arbitrarily selected examples it is discernible that the potential applications of an
`interface can be entirely different from each other. It is therefore desirable that an interface is so
`flexible that via an interface very different electric or electronic systems can be connected to a
`host device. In order to avoid user errors, it is further desired that a service technician is not
`forced to operate different interfaces in a different fashion for each respective application, but
`that if possible a universal interface operation is generated for a large number of applications.
`
`In order to increase the data transmission rate via an interface the path was chosen in the second
`group of interface devices to strongly adapt the interface to individual host systems or computer
`systems. The advantage of this solution comprises that high transfer rates are possible. However
`it is disadvantageous that the drivers for the interfaces of the second group are largely adapted to
`a single host system, so that in general they cannot be used for other host systems, or only in a
`very ineffective fashion.
`
`
`
`
`
`ZTE (USA) 1004, Page 4/34
`
`

`
`WO 98/39710
`
`
`3
`
`PCT/EP98/01187
`
`Further, these types of interfaces show the disadvantage that they must be mounted in the
`computer housing because they access the internal host bus system in order to yield maximum
`data transmission rates. Therefore they are generally not suitable for mobile host systems in the
`form of laptops, which based on their size as small as possible show no available interior volume
`for plugging in an interface card.
`
`A solution for this problem is offered in the form of interface devices of the company IOtech
`(business address: 25971 Cannon Road, Cleveland, Ohio 44146, U.S.A.), which are suitable for
`laptops such as the model WaveBook/512 (registered trademark). The interface devices are
`connected by plugging in a perhaps credit card-sized chip-card with the PCMCIA-interface,
`which in the meantime has become standard for laptops. The plug-in card leads to a
`transformation of the PCMCIA interface to an interface IEEE 1284 known from prior art. The
`above-mentioned plug-in card generates a special printer interface, expanded with regards to data
`rates, which yields a data transmission rate of approximately 2 MB/s, compared to a rate of
`approximately 1 MB/s of printer interfaces of prior art. The interface device of prior art generally
`comprises a driver component, a digital signal processor, a buffer, and a hardware assembly,
`which ends in a connector at which a device is connected whose data shall be gathered. The
`driver component is directly connected to the expanded printer interface, allowing the known
`interface device to generate a connection between a computer and the device whose data shall be
`gathered.
`
`In order to work with the above-mentioned interface a driver, specific for said interface, must be
`installed in the host device so that the host device can communicate with the digital signal
`processor of the interface card. As already mentioned, the driver must be installed on the host
`device.
`
`
`
`
`
`ZTE (USA) 1004, Page 5/34
`
`

`
`WO 98/39710
`
`
`4
`
`PCT/EP98/01187
`
`If the driver is one designed especially for the host device it allows here a rapid data
`transmission, however the driver cannot easily be installed on another host system. If the driver
`is a rather flexible, general driver that can be used for many host devices, here compromises
`must be accepted with regards to the data transmission rate.
`
`Particularly in an application for multi-tasking systems in which several different tasks must be
`processed essentially simultaneously, such as data gathering, data display, or editing, commonly
`each task of the host system is allocated a certain priority. A driver supporting a particular task
`inquires in the central processing system of the host device if it can use processor resources in
`order to process its task. Depending on the respective priority allocation method and depending
`on the implementation of the driver a certain task then receives a certain portion of the processor
`resources at certain time slots. Conflicts can develop when one or more drivers are implemented
`such that they usually have the highest priority, i.e. that they are incompatible, as is the case in
`many applications in practice. Here it may occur that both drivers are set such that they have
`highest priority, which in the worst case scenario can even lead to the system crashing.
`
`EP 0685799 A1 discloses an interface by which several periphery devices can be connected to a
`bus. An interface is interposed between the bus of a host device and various periphery devices.
`The interface comprises a status machine as well as several branches respectively allocated to a
`periphery device. Each branch comprises a data manager, a cycle control, user logic, as well as a
`buffer.
`
`
`
`
`
`ZTE (USA) 1004, Page 6/34
`
`

`
`WO 98/39710
`
`
`5
`
`PCT/EP98/01187
`
`This known interface device generates an optimal adjustment between a host device and a special
`periphery device.
`
`The professional publication IBM Technical Disclosure Bulletin, Vol. 38, no. 05, p. 245;
`“Communication Method between Devices through FDD Interface” discloses an interface, which
`connects a host device via a disk drive interface to a periphery device. The interface particularly
`comprises an address generator, a MFM decoder/coder, a serial/parallel converter, and a format
`signal generator. With the interface it is possible to connect not only a disk drive to the FDD-host
`controller of a host device but also another periphery device. Here, the host device assumes that a
`disk drive is always connected to its disk drive control, with a communication beginning when
`the address is consistent. The paper fails to provide any indication, though, how any
`communication shall be possible when the interface is connected to a multipurpose interface
`instead to the disk drive control.
`
`The objective of the present invention comprises to create an interface device for the
`communication between a host device and a data transceiver, which can be used independent
`from the host device and allows high data transmission rates.
`
`This objective is attained in an interface device according to claim 1 or 12 as well as a method
`according to claim 15.
`
`The present invention is based on the acknowledgment that both a high data transmission rate as
`well as an application independent from the host device can be achieved when a driver for an
`input/output devices standard for a host device is used, which is commonly provided in most host
`devices available in the market.
`
`
`
`
`
`ZTE (USA) 1004, Page 7/34
`
`

`
`WO 98/39710
`
`
`6
`
`PCT/EP98/01187
`
`Drivers practically provided in every host device for input/output device common for host
`devices are for example drivers for hard drives, graphic devices, or printers. However, since the
`hard drive interfaces in common host devices, which may be for example IBM-PCs, IBM-
`compatible PCs, Commodore PCs, Apple computers, or also work stations, represent interfaces
`with the fastest data transmission rate, in the preferred exemplary embodiment of the interface
`device of the present invention the driver for the hard drive is used. Drivers for other storage
`devices, such as disk drives, CD-ROM drives, or tape drives, may be used as well in order to
`implement the interface device according to the present invention.
`
`As explained in the following, the interface device according to the invention shall be connected
`to a multipurpose interface of the host device, e.g. implemented as a SCSI-interface or expanded
`printer interface. Multipurpose interfaces comprise on the one hand an interface card and on the
`other hand driver software specialized for this purpose. The driver software can be embodied
`such that it can replace the BIOS-driver routines. The communication between the host device
`and the device connected to the multipurpose interface then occurs generally via driver software
`specific for the multipurpose interface and no longer predominantly by BIOS-routines of the host
`device. Recently, drives for multipurpose interfaces have already been integrated in the BIOS
`system of the host device, because multipurpose interfaces become more and more common in
`addition to classical input/output interfaces for host devices. Of course it is also possible to use
`BIOS routines parallel to specific driver software for the multipurpose interface, if so requested.
`
`
`
`
`
`ZTE (USA) 1004, Page 8/34
`
`

`
`WO 98/39710
`
`
`7
`
`PCT/EP98/01187
`
`The interface device according to the present invention comprises a processor device, a storage
`device, a first connection device for an interface-connection of the host device to the interface
`device, and a second connection device for an interface-connection of the interface device to the
`data transceiver. The interface device is configured by the processor device and the storage
`device such that the interface device, upon inquiry of the host device, via the first connection
`device which relates to the type of a device connected to the host device, sends independently
`from the type of the data transceiver a signal via the first connection device to the host device,
`which signals to the host device that it communicates with an input/output device. The interface
`system according to the present invention simulates therefore by both hardware as well as
`software the functionality of a common input/output device and preferably a hard drive. Due to
`the fact that the support of hard drives is implemented as a standard in all available host systems,
`for example the simulation of a hard drive can achieve independence from the host system used.
`The interface device according to the invention therefore communicates with the host device or
`computer no longer via a specially designed driver but via a program provided in the BIOS
`system (BIOS = Basic Input/Output System), which usually is adjusted precisely to the special
`computer system on which it is installed and/or via a program specific for the multipurpose
`interface. This way the interface device according to the present invention combines the
`advantages of both groups. On the one hand, data communication occurs between the computer
`and the interface via a BIOS-program specific for the host-device and/or via a driver program
`adjusted to the multipurpose interface, which could be considered a “device-specific driver”.
`
`
`
`
`
`ZTE (USA) 1004, Page 9/34
`
`

`
`WO 98/39710
`
`
`8
`
`PCT/EP98/01187
`
`On the other hand, the BIOS program and/or a respective multipurpose interface program which
`serves as one of common input/output interfaces in the host system, is provided in precisely
`every host system, causing the internet device according to the present invention to be
`independent from the host device.
`
`In the following, preferred exemplary embodiments of the present invention are explained in
`greater detail with reference to the attached drawings. It shows:
`
`Fig. 1 a diagram of the principle of the interface device according to the present invention; and
`
`Fig. 2 a detailed block diagram of an interface device according to a preferred exemplary
`embodiment of the present invention.
`
`Fig. 1 shows a block diagram of the principle of an interface device 10 according to the present
`invention. A first connection device 12 of the interface device 10 can be connected via a host line
`11 to a host device (not shown). The first connection device is connected both to a digital signal
`processor 13 as well as a memory 14. The digital signal processor 13 and the memory 14 are
`further coupled via bidirectional communication lines (in all lines indicated by two directional
`arrows) to a second connection device 15. The second connection device can be coupled via an
`output line 16 to a transceiver, which shall receive data from the host device or from which data
`shall be sampled, i.e. gathered, and transmitted to the host device. Via the first and the second
`connection device the transceiver itself can also actively communicate to the host device, as
`shown in greater detail in the following.
`
`The communication between the host system or host device and the interface device is based on
`the standard access commands of prior art, as supported by all known operating systems (e.g.,
`DOS, Windows, Unix).
`
`
`
`
`
`ZTE (USA) 1004, Page 10/34
`
`

`
`WO 98/39710
`
`
`9
`
`PCT/EP98/01187
`
`Preferably the interface device simulates according to the invention a hard drive with a root
`directory, with its entries representing “virtual” files, which can be generated for various
`functions. When the host device system, to which the interface device according to the present
`invention is connected, with the interface device 10 further being connected to a transceiver, is
`booted up, common BIOS routines or multipurpose interface programs issue a command to the
`input/output interfaces provided in the host device, which in professional circles is known as the
`command “INQUIRY”. The digital signal processor 13 receives this inquiry via the first
`connection device and a signal is generated, which in turn is transmitted via the first connection
`device 12 and the host line 11 to the host device (not shown). This signal indicates to the host
`device that at the respective interface, to which the command INQUIRY was sent, e.g., a hard
`drive is connected. Optionally the host device can transmit to the interface device the command
`“Test Unit Ready”, known to professionals, which requests more detailed information regarding
`the device inquired about.
`
`Independent of the fact which transceiver is connected at the output line 16 to the second
`connection device the digital signal processor 13 reports to the host device that the host device
`communicates with a hard drive. If the host device receives the response that a drive is available,
`it will now transmit the inquiry to the interface device 10, to read the boot sequence, which
`commonly is located in real hard drives on the first sectors thereof. The digital signal processor
`13, with its operating system being saved in the storage device 14, will respond to this command
`by sending a virtual boot sequence to the host device, which in actual drives comprises the type,
`the start position, and the length of the FAT (FAT = File Allocation Table), the number of
`sectors, etc., as commonly known by persons trained in the art.
`
`
`
`
`
`ZTE (USA) 1004, Page 11/34
`
`

`
`WO 98/39710
`
`
`10
`
`PCT/EP98/01187
`
`When the host device has received this data, it assumes that the interface device 10 according to
`a preferred exemplary embodiment of the present invention is a hard drive. Upon an inquiry of
`the host device to display the directory of the “virtual” hard drive which is simulated by the
`interface device 10 towards the host device, the digital signal processor can respond to the host
`device in the same fashion as a conventional hard drive would do, namely upon request by
`reading the data position table or FAT on a certain sector in the boot sequence, which is
`generally the first writable sector, and transmitting it to the host device, and by subsequently
`transmitting the directory of the virtual hard drive. It is further possible that the FAT is only read
`directly before the scanning or saving of data of the “virtual” hard drive, and not already during
`initialization.
`
`In a preferred exemplary embodiment of the present invention the digital signal processor 13,
`which may be embodied not necessarily as a digital signal processor but also as any arbitrary
`other microprocessor, comprises a first and a second command interpreter. The first command
`interpreter performs the just mentioned steps, while the second command interpreter performs
`the read/write allocation for certain functions. If now the user desires to read data from the
`transceiver via the line 16, the host device sends a command to the interface device, which could
`be called “read file xy” for example. As already mentioned, the interface device appears similar
`to a hard drive in reference to the host device.
`
`
`
`
`
`ZTE (USA) 1004, Page 12/34
`
`

`
`WO 98/39710
`
`
`11
`
`PCT/EP98/01187
`
`The second interpretation device of the digital signal processor interprets now the read command
`of the host processor by decoding, if “xy” represents for example a file “real time input”,
`“configuration”, or an executable file, as a data transmission command, causing it to start
`transmitting data from the transceiver via the second connection device to the first connection
`device and via the line 11 to the host device.
`
`Preferably, in a configuration file described in the following the volume of data to be gathered by
`a data transceiver is stated, by the user defining in the configuration file that a measurement shall
`extend over five minutes, for example. Then the file “real time input” shall appear for the host
`device like a file, with its length being equivalent to the data volume expected for the five
`minutes. Persons trained in the art are aware that the communication between a processor and a
`hard drive comprises that the processor transmits to the hard drive numbers of blocks or clusters
`or sectors in order to read their content. From the FAT the processor knows which information is
`located in what block. In this scenario the communication occurs from a host device to the
`interface device of the present invention and comprises therefore in a very rapid transmission of
`block numbers and preferably blocks number sections, because a “virtual” file “real time input”
`is not fragmented. If now the host device intends to read the file “real time input” it transmits a
`section of block numbers to the interface device, and then the receipt of data starts via the second
`transmission device and transmission via the first connection device to the host device.
`
`In addition to the command memory for the digital signal processor, which comprises the
`operating system and may be embodied as EPROM or EEPROM, the memory 14 may show an
`additional buffer, which serves for synchronization purposes between the data transmission from
`the transceiver to the interface device 10 and the data transmission from the interface device 10
`to the host device.
`
`
`
`
`
`ZTE (USA) 1004, Page 13/34
`
`

`
`WO 98/39710
`
`
`12
`
`PCT/EP98/01187
`
`Preferably the buffer is embodied as a rapid direct access memory or RAM-buffer.
`
`From the host device the user can further generate a configuration file on the interface device 10,
`which appears to the host device like a hard drive, with the entries thereof automatically
`adjusting and controlling various functions of the interface device 10. They may for example be
`amplification, multiplex, or scanning rate adjustments. By generating and editing a configuration
`file, which usually is a text file which is easily understood without extensive prior knowledge,
`the user of the interface device 10 can execute essentially the same operations for nearly any
`transceiver that can be coupled via the line 16 to the second connection device, eliminating a
`source for errors which arises from the requirement that the user knows many different command
`codes for various applications. For the interface device 10 according to the present invention it is
`only necessary that the user once notes the conventions of the configuration file, according to
`which he/she can use the interface device 10 as an interface between a host device and an almost
`arbitrary transceiver.
`
`By the option to save arbitrary files in various formats in consideration of the maximum storage
`capacity of the memory on the interface device 10 in the memory 14 here arbitrary expansions or
`completely new functions of the interface device 10 can even be realized without any time lag.
`Even files to be executed by the host device, such as batch files or executable files (BAT-files or
`EXE-files) or auxiliary files can be implemented in the interface device and thus achieve
`independence of the interface device 10 from any additional software (except for the BIOS
`routines) of the host device.
`
`
`
`
`
`ZTE (USA) 1004, Page 14/34
`
`

`
`WO 98/39710
`
`
`13
`
`PCT/EP98/01187
`
`This avoids on the one hand licensing and/or application problems. On the other hand
`installations of certain routines are unnecessary, which are frequently used, such as a FFT-
`routine, in order to for example allow analyzing time range data in the frequency range, because
`these EXE-files are already installed on the interface device 10 and appear in the virtual root
`directory, by which the host device can access any programs saved on the interface device 10.
`
`In one preferred exemplary embodiment of the present invention, in which the interface device
`10 simulates a hard drive in reference to the host device, it is already detected automatically
`when turning on or booting the host system and ready for operation. This is equivalent to the
`presently widely used “plug-and-play” standard. The user no longer needs to focus on the
`installation of the interface device 10 on the host device by drivers to be especially loaded, but
`the interface device 10 is automatically ready for operation upon booting the host system.
`
`For persons trained in the art it is however obvious that the interface device 10 is not necessarily
`reported to the computer upon booting, but that a special BIOS-routine or a driver can also be
`started for a multipurpose interface on the host device during the operation of the computer in
`order to connect the interface device 10 as an additional hard drive or to “mount” it. This
`exemplary embodiment is suitable for larger work station systems, which are essentially never
`shut down, because they perform for example mail functions or process monitoring in a
`“multitasking” environment and are constantly in operation.
`
`
`
`
`
`ZTE (USA) 1004, Page 15/34
`
`

`
`WO 98/39710
`
`
`14
`
`PCT/EP98/01187
`
`The interface device according to the present invention shows the enormous advantage of
`separating the actual hardware required for connecting the interface device 10 to the transceiver,
`as disclosed in the exemplary embodiment described in the following, from the communication
`unit, which is implemented by the digital signal processor 13, the memory 14, and the first
`connection device 12, such that various device types can be served parallel and in an identical
`fashion. Accordingly, may interface device 10 can be connected to a host device, which then
`detects various quasi “virtual” hard drives. On the other hand, potential changes of the specific
`hardware symbolized by the second connection device 15 can be realized essentially without
`changing the operation of the interface device according to the present invention. Further, an
`experienced user can engage at any time in the existing second connection device to an arbitrary
`depth, by using the above-mentioned option of generating a configuration file or by adding or
`saving new program parts for the second connection device.
`
`An essential advantage of the interface device 10 of the present invention further comprises that
`it allows extremely high data transmission rates, namely such that the BIOS-routines of the host
`device optimized by the manufacturer of the host device and/or the BIOS-system for each host
`device are used for data exchange and/or that driver programs are used commonly optimized and
`provided by the manufacturer of multipurpose interfaces. Additionally, the data based on the
`simulation of the virtual bulk memory is managed and rendered available such that it can be
`transmitted directly, quasi without any processor intervention of the host system, to other storage
`media, e.g., a real hard drive of the host device. The only limitation for a long-time data
`transmission with high speeds is therefore caused exclusively by the speed and memory capacity
`of the bulk memory of the host system.
`
`
`
`
`
`ZTE (USA) 1004, Page 16/34
`
`

`
`WO 98/39710
`
`
`15
`
`PCT/EP98/01187
`
`This is the case because the digital signal processor 13 already formats via the second connection
`device 15 the data imported by the transceiver into block sizes suitable for a hard drive of the
`host device, causing the data transmission speed to be limited only by the mechanic inertia of the
`hard drive system of the host device. At this point it shall be noted that usually a data flow from
`a host device must be formatted into blocks in order to allow writing them onto a hard drive and
`then permitting later access thereto, as commonly known to one trained in the art.
`
`By implementing direct memory access (DMA) or RAM-drives in the host system the above-
`mentioned data transmission rate can be further increased. As commonly known to one trained in
`the art the implementation of a RAM-drive requires however processor resources of the host
`device, thus the advantage is lost for the data to be written on the hard drive of the host device
`and essentially requiring no processor resources.
`
`As already mentioned, a data buffer may be implemented in the memory 14 which allows the
`temporary independence of the transceiver, which is coupled to the second connection device,
`from the host device which is coupled to the first connection device. This way even in time-
`sensitive applications the flawless operation of the interface device 10 is ensured even in multi-
`tasking host systems.
`
`Fig. 2 shows a detailed block diagram of an interface device 10 according to the present
`invention.
`
`
`
`
`
`ZTE (USA) 1004, Page 17/34
`
`

`
`16
`
`PCT/EP98/01187
`
`WO 98/39710
`
` A
`
` digital signal processor (DSP) 1300 represents quasi the core of the interface device 10. The
`DSP may be an arbitrary DSP, with it being preferred, though, that it shows an on-chip-direct
`access memory (RAM) of 20 KB. In the direct access memory, which is already integrated on
`the DSP, for example certain command sets may be saved. Connected to the DSP 1300 is an 80-
`MHz clock component 1320, in order to clock the DSP. The DSP implements a fast Fourier-
`transformation (FFT) in real time as well as an optional data compression for the data to be
`transmitted from the transceiver to the host device in order to yield higher efficiency, and in
`order to allow cooperating with host devices which show smaller memory capacities.
`
`The first connection device 12 of Fig. 1 includes in the preferred exemplary embodiment shown
`in Fig. 2 of the interface device 10 the following components: a SCSI-interface 1220 as well as a
`50-pin SCSI-connector 1240 to connect to a SCSI-interface provided in most host devices or
`laptops. The SCSI-interface (SCSI = Small Computer System Interface) 1220 convers data
`received via the SCSI connector 1240 into