WO2000025468A2 - Direct communication link between a plurality of users independent of a server - Google Patents
Direct communication link between a plurality of users independent of a server Download PDFInfo
- Publication number
- WO2000025468A2 WO2000025468A2 PCT/IB1999/001865 IB9901865W WO0025468A2 WO 2000025468 A2 WO2000025468 A2 WO 2000025468A2 IB 9901865 W IB9901865 W IB 9901865W WO 0025468 A2 WO0025468 A2 WO 0025468A2
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- user
- user station
- server
- data
- address
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/2866—Architectures; Arrangements
- H04L67/289—Intermediate processing functionally located close to the data consumer application, e.g. in same machine, in same home or in same sub-network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/45—Network directories; Name-to-address mapping
- H04L61/4535—Network directories; Name-to-address mapping using an address exchange platform which sets up a session between two nodes, e.g. rendezvous servers, session initiation protocols [SIP] registrars or H.323 gatekeepers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
Definitions
- the present invention relates to direct communication links between a plurality of users.
- a business network that provides services to users globally on a global network typically includes one or more central servers, for example, for providing centralized access control, file access, and resource management to the plurality of users. Consequently, a user desiring to establish a communication link to another user employing the same service must direct all communications to the server. The server then relays the messages to the other user. Similarly, when a response is necessary, the other user must also direct all communications to the server, wherein the server relays the messages to the appropriate user(s) to receive the messages. Because all communications from the plurality of users must be handled and redirected by the server, a major bottleneck is frequently created at the server, degrading performance and causing failure of the server computer. As a result, the users are often prevented from communication with each other. Moreover, communicating through a server invariably creates an increase in network traffic resulting in time delay for users to communicate.
- the present invention provides a direct communications link between at the two users independent of the common server once the direct communication link is established. Accordingly, the transmission of psychophysiological data in real time can be achieved.
- An aspect of the present invention provides a method for establishing a direct connection between at least two users having access to a registry server located on a global network.
- the method includes registering a first IP address associated with a proxy server with a registry server.
- the proxy server being locally connected to at least one first user station.
- the method also includes receiving a request from a second user station to communicate with the first user station and transmitting the first IP address to the second user station by the registry server.
- the method also includes establishing a direct communication link from the second user station to the first user station via the proxy server using the first IP address without having to connect to the registry server.
- Another aspect of the present invention provides a method for establishing a direct connection between at least two users having access to a registry server located on a global network to enable a first user to monitor a second user remotely.
- the method includes registering a first user station with a registry server using a proxy IP address.
- the first user station locally connected to a proxy server having the proxy IP address.
- the method also includes initiating communications with at least one sensor for monitoring activities of a user such as physiological and psychophysiological activities at the first user station.
- the method also includes notifying a second user station remotely connected from the first user station to receive the proxy IP address to communicate with the first user station and establishing a direct communication link from the second user station to the first user station via the proxy IP address.
- the method also includes receiving data signals from the sensor as a result of monitoring the activities such as physiological and psychophysiological activities of the user at the first user station and transmitting the data signals to the second user station via the direct communication link.
- Yet another aspect of the present invention provides a system for establishing a direct connection between at least two users having access to a registry server located on a global network.
- the system includes a registry server for registering IP addresses of at least one user and a proxy server having a first IP address connected to at least one first user station.
- the proxy server receives a request from the first user station to register with the registry server, the proxy server registers the first IP address.
- the registry server receives a communications request from a second user station to communicate with the first user station, the registry server provides the second user station with the first IP address.
- the second user station is allowed to establish a direct communication link bypassing the registry server to the first user station via the proxy server.
- FIG. 1 is an exemplary embodiment of a system of the present invention for establishing a direct connection between a plurality of users.
- FIG. 2 is an exemplary embodiment of a diagram illustrating establishing direct communication between a plurality of users in accordance with the present invention.
- FIG. 3 is an exemplary embodiment of a system of the present invention for establishing direct communication between a health provider unit and client unit.
- FIG. 4 is an exemplary embodiment of a block diagram for establishing a connection to receive data from a device independent of the server once the communication link is established in accordance with the present invention.
- FIG. 5 illustrates an example of a block diagram showing the Data Server of the present invention having two devices and two client applications.
- FIG. 1 illustrates an exemplary embodiment of a system for establishing a direct connection between a plurality of users not having well-known Internet Protocol (IP) addresses.
- IP Internet Protocol
- users A-D 110, 120, 130, 140 may not have well- known IP addresses.
- Users 110, 120, 130, 140 for example may be clients or users of clients having a client program such as a user interface. The client program may run and register services on behalf of the client. Further, users 110, 120, 130, 140 may connect to the Internet, for example, using a dial up connection through an Internet provider.
- IP Internet Protocol
- the Internet provider usually assigns a temporary Internet address to the user. This temporary address is usually unknown to other users, that may want to contact to another user. Further, multiple processes can run on one machine, each handling Internet connections. Thus, a user can sign on to a plurality of services under the user's name. A user can also specify other users that have access to a specific service which the user signed on. Other users not specified in an access control list, will not be provided with any information indicative of whether the specified service is available or the address of the service from, for example, a registry server such as Server H 180. In an exemplary embodiment of the present invention, the system is supplemented with password authentication.
- Proxy Server H 180 may have a well-known IP address. Proxy Servers 150, 160, 170, however, need not have well- known IP addresses. For example, a proxy server may access Server H 180 through an ISP and be provided with a temporary Internet address. Proxy Servers, for example, establish and maintain connections between users of different networks and tracks local users and their local addresses.
- Proxy Servers 150, 160, 170 may include a program, for example, UMGate, designed to run on a proxy computer that connects a local area network (LAN) with the Internet.
- the LAN may be connected to the Internet via one or more stations, which can be used as a gateway (or proxy) by the other LAN stations.
- User C 130 goes through Proxy Server F 160 and Proxy Server G 170 as shown in FIG. 1 to access Server H 180 which may be located at a web site on the Internet. Further, User C 130 may include a plurality of users on a LAN accessing the same Proxy Servers F and G. Accordingly, the other LAN users access the Internet through the proxy server and do not get an Internet address of their own.
- proxy servers 150. 160, 170 are transparent, e.g., a specific communication link between two users may go through one or more proxy servers without the users being provided with information indicative that the proxy servers are involved.
- Regular operations including, but not limited to, listing online users, retrieving user data, and broadcasting, all work as if there were no proxy servers 150, 160, 170. Accordingly, all the messages are provided to the appropriate users whether they are connected directly to the Internet or behind one or more proxy servers.
- Server H 180 may include a registry server located on the Internet for registering IP addresses and tracking online services and a file transfer protocol (FTP) server for transferring files in response to requests.
- FTP file transfer protocol
- a direct connection may be established between User A 110 and User B 120 independent of Server H 180 once the direct connection is established.
- User B not having a well-known IP address, locally connects to Proxy Server E having an address such as a temporary IP address or a well-known IP address.
- Proxy Server E 150 may receive a request from User B 120 to register with Server H 180. Accordingly, Proxy Server E 150 registers its IP address with Server H 180.
- FIG. 1 may include a registry server located on the Internet for registering IP addresses and tracking online services and a file transfer protocol (FTP) server for transferring files in response to requests.
- FTP file transfer protocol
- a direct connection may be established between User A 110 and User B 120 independent of Server H 180 once the direct connection is established.
- Proxy Server E not having a well-known IP
- User A 110 communicates with Server H 180 without going through a proxy server.
- User A 110 may be access Server H through an ISP and be provided with a temporary IP address.
- Server H 180 Upon Server H 180 receiving a communications request from User A 110 to communicate with User B 120, Server H 180 provides User A 110 with the well-known IP address of Proxy Server E 150 for allowing User A 110 to establish a direct communications link to User B 120 via Proxy Server E 150 in which Server H 180 is bypassed.
- multiple users directly or indirectly connected to a network such as the Internet may communicate with each other through a direct communication link independent of a registry server, e.g., Server H 180, once the direct communication link is established.
- direct communication links may be established with more than two users, each having direct communication with each other.
- the direct communication being independent of the common server 180 once the direct communication is established. Accordingly, communication can be established with each other without having to continuously pass through increased network traffic at a common server.
- FIG. 2 illustrates an exemplary embodiment of a method of the present invention for establishing a direct connection between at least two users enabling one of the users to monitor another one of the users.
- Each of the users 110, 120, 130, 140 have access to a registry server 180 located on a global network such as the Internet.
- a registry server 180 located on a global network such as the Internet.
- User B 120 is registered with Server H 180 by signing in 201 with Proxy Server E 150.
- Proxy Server E 150 transfers the sign in information from User B 120 and the IP address of Proxy Server E 150 to Server H 180.
- Server H 180 receives IP address information
- User B 120 sets a device such as a sensor connected to or at the location of User B 120 for providing data corresponding to activity such as psychophysiological data of, for example, User B 120.
- Sensors may include, but are not limited to, EDA sensor, finger temperature sensor, core temperature sensor, pulse sensor, respiration Luzi sensor, blood pressure sensor, EKG sensor and weight sensor.
- Psychophysiological data reflects psychological behaviour and psychological state. Mind/body interactions, relaxation methods and diagnostic information with emphasis on self behaviour modification and improvement can be achieved.
- Proxy Server E 150 receives the set device information and transfers the information to Server H 180 which records the device information in 206.
- Communication is initiated with the device and User B 120.
- User B 120 provides information to Proxy Server E 150 allowing data provided by the device previously set to be viewed by User A 110.
- Proxy Server E 150 transfers the information provided by User B 120 to Server H 180 and Server H 180 record this information in 209.
- User B 120 can be registered in a client mode allowing, for example, the activities such as physiological and psychophysiological activities of the user as indicated by the device to be monitored by a specified user or users.
- Server H notifies User A 110, for example, remotely connected from User B 120, to receive the proxy IP address to establish a direct communication link between User A 110 and User B 120 independent of Server H 180 once the direct communication link is established.
- User A 110 signs in with Server H 180.
- User B 120 sets and/or modifies user information with Proxy Server E 150 which transfers the user information to Server H 180 in 213 to be recorded in 214.
- User A 110 requests user data from Server H 180 which provides the user data to User A 110 in 216.
- User B 120 receives the user data from Server H 180. The user data can be read whether or not the user, which originally stored the data, is currently online.
- User A 110 requests to monitor User B 120, for example, establish a communication link to receive data provided by the device previously set by User B 120 in 218
- User B 120 sets a local server and provides notification in 219.
- Raw data from the device is sent to User A 110 through IP address of Proxy Server E 150 in 220.
- the raw data may be displayed for User A 110 using a selected application.
- User A 110 may monitor the activities such as physiological and psychophysiological activities of User B 120 through a direct communication link.
- the information of User B 120 transmitted to Server H 180 may be retrieved by User A 110.
- User A 110 may, for example, analyse the information of User B 120 with the data signals received.
- 222b User A 110 and User B 120 may chat with each other through respective IP addresses associated with each other through the direct communication link independent of Server H 180 once the direct communication link is established.
- An exemplary embodiment of the present invention as shown in FIG. 3, provides a Client/Server based environment that uses networks such as the Internet for a comprehensive connected health application.
- a plurality of users can be, for example, a doctor 310 and a patient 320.
- the doctor 310 and patient 320 can connect to the Internet through, for example, a direct connection or a LAN.
- the patient 320 can transfer data such as physiological data directly to the doctor 310 in realtime or place data on a server unit 330 that can be retrieved by other authorised users, for example, a doctor 310 which has access to the patient 320.
- the data placed on the server can be retrieved whether or not the user that placed the data is currently online.
- a user can use the server unit 330 to broadcast a message to all users which are currently online and which have access to the broadcasting user.
- patient data may be provided to, for example, the server unit 330 and/or other users through sensors associated with the patient 320. If any of the sensors are changed, a message such as the sensor being changed may be provided to all of the doctors 310 of the patient 320 currently online.
- the health application including the attachment of several low cost, easy to use sensors that relate to a specific medical parameter as disclosed in European
- the health application also includes registration of patients with appropriate data such as name, address, phone number, etc.; on the fly measurement and recording of medical data received from at least one of the sensors; viewing of physiological data from a session or historical perspective; sending the data received from the at least one sensor on the fly or at a later time; sending other medical data to the same server and/or user such as a health provider 310 and automatic process of notification between respective users such as a patient and a health provider.
- Table One identifies the communication between users such as the physicians 310 and patients 320, and the server unit 330.
- the server unit 330 may be a registry server 180 located at a web site that can be accessed, for example, through a dial-up connection and a continuous connection will be established with a local ISP.
- the client unit 320 includes the following capabilities: registration, accepting and displaying other users such as health providers 310, sensor attachment and accepting physiological data therefrom by using, for example, a graphing application such as UMGraph; sending informative data and medical data; setting sensors; sending and receiving instructions and messages via chatting channel and view recorded data by using, for example, a viewing application such as UMView.
- a graphing application such as UMGraph
- sending informative data and medical data setting sensors
- a user is identified through registration and establishes a password to log in to the server. Further, the first time a user registers additional information may be requested such as telephone number, address, birthday and names of health providers. For existing users, only a password may be required to enable sign-in . Existing users may modify their data previously provided by again using the registration process as shown in 212 of FIG. 2.
- the client unit 320 may receive the status of providers registered thereto. For example, an initial list may be provided to the client unit 320 and a modification notification may be provided each time the initial list changes.
- the patient 320 may be connected to a sensor and set the type of sensor. Graphs may be displayed by a graph application as shown in 221 of FIG. 2 and the raw data may be recorded for future assessments.
- the user may send data files to the server addressing it to another user such as a health provider 310. If the health provider 310 is signed-in, it will receive an automatic notification about the sent files.
- the client unit 320 may send recorded medical data to the server unit 330 and health providers 310 of the client unit 320 and download files provided by the respective health providers 310.
- the recorded medical data may be, for example, a set of previously stored sessions, a file of an integrated external application and a specific session from previously recorded sessions for Internet data viewing.
- the client unit 320 defines the sensor, checks the connection and informs others as shown in 204 of FIG. 2.
- the client unit 320 receives and sends text data to a health provider 310 that is currently signed in and associated with the client unit 320. Further, health providers 310 may send messages to other health providers 310 or their patients 320. The patient 320 will be able to view the respective data that has already been recorded. Data that passed through the graph application may automatically be recorded.
- the server unit 330 may be, for example, an Internet site system written in Java including the following services: accept data of users, accept registration requests, sign-in and out, accept and send information regarding sensors, connect users together for interactive operation, store data files of patients 320, send data files of patients 320 to their respective health providers 310 and accept user data.
- the server unit 330 receives registration data from the various users and records it.
- the registration data may include, for example user code name, first name, last name, birthday, health provider, name, telephone number and password.
- the server unit 330 accepts and stores registration in a database.
- the user IP will be kept for future connections.
- the sign-in/out process informs the server unit 330 of whether a user is presently connected.
- the server unit 330 manages a connected-user table that includes communication data such as a user name and associated IP address.
- the server unit 330 will send respective notification messages to users connected to the network. For example, a client unit 320 is notified when health providers 310 of the client unit 320 are signed in and the health provider 310 is notified that its patients 320 are signed in. Further, at the end of a sign-in process, the user signing in gets the initial data including the status of the associations of users.
- the server unit 330 provides the health provider 310 with the sensor type previously provided by the client unit 320 prior to the health provider 310 connecting to the client unit 320. Interactive operation between users is accomplished by at least one of the users getting the IP of the other user from the server unit 330.
- the server unit 330 stores and sends data files of patients 320 to the respective health providers 310.
- the health provider unit 310 may include the following capabilities: registration; open data channel with a patient 320 to receive data on the fly; download patient data from the server unit 330; send and receive instructions and messages via chatting channel; receive sensor type; view recorded data; view external data files using, for example, a viewing application and send files such as reports or analysis of the patient data to patients 320.
- the health provider unit 310 may open a data channel with a patient 320 by selecting the patient 320 from a list of patients presently signed in. When a data channel is established the relevant client units 320 receive an automatic notification from the health provider 310 via the chatting mechanism.
- the health provider unit 310 may ask to download patient data form, for example, the Internet.
- the health provider unit 310 may be allowed to do so from its patients only. By using the chatting channel, the health provider unit 310 can direct the patient to take specific actions or obtain current information. For example, instruct the patient 320 to relax or to turn on a sensor. The health provider unit 310 will be able to view the data of patients 320 that has been sent. The health provider unit 310 selects the relevant patient 320 out of the list and gets a list of recorded sessions attached to the chosen patient. A sessions list may be provided and sorted by sensor type, session date or duration.
- data from each of the respective sessions is stored through, for example, a header file including patient's user name and sensor code to recognise patient and sensor type; management of several raw data files, a manual procedure for import from and export to external files and a session data table.
- the system of the present invention may include a viewing application, a graphing application and a displaying application.
- the viewing application may include enabling the recording and assessment mechanism to support several sensors and devices together with multiple patient management includes using header file to recognise patient and sensor type, selecting several raw data files, select patients and sensors, and viewing weight and EKG data of a patient.
- the graphing application may include selecting a device such as a sensor, saving raw data and scaling the graph at least based on the type of sensor. Each graph application window may be used with one sensor. For simultaneous display of several sensors, the user may run several windows, each set to one sensor. Further, the graph application saves the data including headers, events and raw data of non-EDA RP sensor.
- the client data is saved only at the client unit 320.
- the health provider 310 may view that data after it has been sent from the client unit 320 and received by the health provider 310.
- the display application may include displaying the core temperature measured from a sensor such as a forehead sensor over a channel.
- the core temperature measurement includes a sensor calibration stage and a measurement stage.
- the display application includes a setting function for setting and calibrating a sensor, measurement and result presentation, and saving results.
- saving results includes indicating in a data file a beginning event, an ending event and a code event in which the final temperature will be stored. Further, respective notification messages may be sent to the server unit 330.
- server unit 330 such as a Data Server is responsible for acquiring data from various devices such as sensors attached via serial ports and sending the data to client applications.
- Data Server provides communications to the devices and optional saving of device data.
- Data Server includes two components-DataServer.exe and
- DataServer.exe is responsible for acquisition and buffering of the device data
- DataServerDLL.dll provides functional interface to the client.
- the client application loads the DataServerDLL into its (client) address space and directly calls functions for managing of the device.
- the calls to the function are made through a virtual function table and compliant with COM interface.
- Client notification about new data arriving from the device may include setting of a callback function or custom Windows Message notification.
- the callback function may be called from contexts of a thread, providing more uniform processing of data by client unit 320.
- a second thread is created in client process by DataServerDLL.
- Figure 4 is a flow diagram 400 illustrating the operations of the Data Server of the present invention in one exemplary embodiment.
- connection to the DataServer.exe is made.
- the DataServerDLL checks if DataServer.exe is already running and if not, executes it. Then the Local Procedure Call (LPC) connection is established with DataServer.exe.
- LPC Local Procedure Call
- the DataServerDLL also can communicate through Remote Procedure Call (RPC) with a remote computer, thus allowing retrieving of the data from the device connected to remote computer. Communication with local or remote computer is transparent to client application. For example, the client only needs to provide the name of the remote computer.
- Data Server allows connection of multiple clients to any one of the devices. Each client is given its own buffering of data, and therefore, one client application runs independent of another.
- device is opened for communication.
- the client typically specifies the name of the port the device is connected to, for example C0M1. If the client doesn't specify the port, providing NULL pointer instead, the Data Server automatically looks for connected devices and opens the first one found. Typically, the four first COM ports are checked.
- channel for data acquisition is opened.
- the client application creates the channel object.
- the client may set the callback function or handle of window for notifications.
- the callback function is generally called each time the specified amount of the data is placed in the internal buffer in DataServer.exe.
- the Data Server may separate data and provide data in multiple channels separately.
- data from the device is receive at the client.
- the client may temporary disable and re-enable data acquisition on a specified channel.
- the client may temporary disable the data acquisition on open channel by calling "EnableChannel" function with TRUE or FALSE.
- the client does not obtain notification and data is not transferred through RPC.
- the data may be saved locally by Data Server to file.
- the client may enable or disable the data save during the session.
- the data may be also transferred through a local network.
- the functionality of Data Server is provided through COM interface. For accessing of Data Server the application obtains a header file with declaration of interface and function for creating of first interface pointer, this function, for example, is called "DataServerCreate" .
- This function creates the instance of CDataServer class, casts its pointer to IDataServer interface and returns it. Through this pointer the client application can open devices and create communication channels for data acquisition.
- the interface is an abstract base class with declarations of pure virtual functions. Using the interface pointer, the client can call these virtual functions.
- the server internally creates instance of the class derived from interface.
- This class includes implementation of functions declared in interface. The functions declared in interface are virtual functions, thus the call to interface functions is made through pointer in virtual function table. If the class that implements the interface is provided in DLL, the application doesn't need to implicitly import interface function from DLL. If the DLL implementing the interface is changed, the existing client application can work with new DLL.
- IDataServer - interface to Data Server Object interface IDataServer: public IUnknown ⁇ virtual HRESULT
- the client uses this interface to open available devices, for example, at 404. Typically, it opens the device on specified port and check if the device has specified ID. If the IpszPortName port name is NULL, then the Data Server looks for connected devices and opens the first device found. If there are no devices connected, it returns an error.
- this interface may include emulation of devices and testing of available ports. For example, if instead of the port name the first parameter obtains name of the file, the device is emulated by the data from the file.
- OpenDevice function first checks if the current port is already opened with some device, if not, it opens it. Then it checks that the valid data arrive from the device. If it obtains valid UM batch, then the interface pointer is returned to the client application.
- the Release member function of IDataServer interface closes connection of client process to DS process and closes all communication channels and open devices created by client process. If the last client called to release, the DS process is unloaded from memory.
- the pointer to IDataServer interface is typically obtained through a function that initiates the Data Server, for example, DataServerCreate function.
- DataServerCreate function is executed, for example, at 402, when connecting to the Data Server of the present invention:
- HRESULT DataServerCreate (LPCSTR IpszCompupterName, IDataServer **lplpDataServer)
- the first parameter is the name of the computer with Data Server Process. NULL pointer in this parameter indicates a local computer. Then this function first checks if DS Process is already running. If it cannot find already running DS process, then creates new and binds to it. Then DataServerCreate creates instance of DataServer object and return pointer to it. If this function is called the second time, it returns the same pointer and increases the lock count.
- the DataServerCreate has a static linkage to client applications 320. It typically calls CoCreatelnstance API with class ID of IDataServer interface . IDevice - interface to device object
- a device may have a few data channels, one channel or none.
- the device is typically described by its internal ID and name of port to which it is connected.
- the data channel object controls flow from specific sensor to a client application.
- the interface for device is as follow: interface IDevice : public IUnknown
- Virtual HRESULT GetDevicelD (int *lpDeviceID) ; // Fills the buffer with name of the port the device connected to virtual HRESULT GetPortName (LPSTR
- OpenDataChannel creates new data channel object and returns interface pointer to it.
- a client application may retrieve data from a sensor and get notification when data is ready. Few different processes may be attached to the same data channel in which case the process typically receive the same data concurrently.
- This call is used, for example, at 406, for opening data acquisition channels.
- EnableFileSave enables or disables writing of data to file, for example, if the function is called with TRUE to enable and FALSE to disable. Initially the device interface pointer may be created with saving to file disabled.
- the data received from the sensor may be saved into a data file. Typically, the data is saved in local directory with a predetermined or pre-specified file name.
- the Release function of IDevice interface deletes the device object in current process and closes all its data channels.
- GetPortName returns the port name to which the device is connected.
- Data Server object i.e., pointer to IDataServer
- a communication channel to the device is created.
- IDataChannel pointer an application may set notification callback function or a handle of a window to start receiving data as described with reference to 408.
- a ring data buffer is created for each new data channel. If the is already opened by other process, the client is attached to an existing ring buffer.
- SetNotificationHWND function obtains the handle of window for notifications.
- the second parameter indicates the number of samples stored in a buffer before notification is sent to a client application.
- the notifications are sent to application in a form of WM_LJN1D_DATA message.
- the WPARAM includes the number of data items acquired, while LPARAM points to the data.
- the notification callback function works exactly in the same way as message response function for WM_UMD_DATA message. It also obtains number of samples and pointer to sampled data. It also gets the pointer to user data, the same pointer as was provided in SetNotificationCallback.
- the main difference between processing of WM_UMD_DATA message and use of callback function is that the last one is called from contents of additional thread, thus the data can be processed concurrently with updating of the screen or other user operations.
- DisableChannel stops data acquisition on channel or sending of data ready notifications for this channel .
- the Data Server include two components.
- the first component includes the process that implements the data acquisition and buffering and is referred to, for example, as a Data Server Process ("DS Process") .
- DS Process Data Server Process
- Functions such as the opening of the serial port, reading, validation and buffering of data is typically provided in this process.
- the second component, the DLL includes an implementation of interface functions.
- the DLL is directly loaded into address space of client process and provides the communication with DS Process through Local Procedure Call (LPC) or Remote Procedure Call (RPC) .
- LPC Local Procedure Call
- RPC Remote Procedure Call
- the code for LPC and RPC is the same except for the difference in transport protocol name when registering and binding to a server. If the performance of LPC is not satisfactory, for example, the call time may take more than 1 to 1.5 milliseconds.
- the transferring of data from DS Process to application may be done through memory mapped file.
- the advantage of LPC is that the same server can work on local as well as on remote computer .
- Transfer of raw data from server to client application is based on standard producer-consumer model.
- the producer thread adds the data to the buffer while the consumer thread is blocked until in the buffer contains enough data for single consumer notification.
- the producer thread checks whether some clients have enough data for notification.
- Each client thread is blocked on event, waiting for new data.
- Each time there is enough data the event is pulsed by provider thread for the client to get its chance to read its data from the buffer.
- the circular buffer in the present invention includes a buffer with data, one write pointer and dynamic array of read pointers for each client.
- the following data structure is maintained: (1) current "read” pointer; (2) event object signaling that enough data for notification of specific client 320 is placed in the buffer; and (3) minimum number of data items for notification.
- FIG. 5 illustrates an example of a block diagram 500 showing the Data Server of the present invention having two devices and two client applications.
- the DS process 516 opens one provider thread 518, 520 for each open serial port or device 502, 504.
- This provider thread 518, 520 is responsible for reading data from a serial port, multiplexing the data according to channels and placing the data to a corresponding channel. Also, it pulses or signals an event for the clients that have enough data for notification.
- Each client 512, 514 has the consumer thread 522, 524, 526, 528 for each opened channel 506, 508, 510.
- These consumer threads are typically created by DS DLL attached to the client process. The consumer thread 522, 524, 526, 528 is blocked on event, waiting for new data.
- the producer thread 518, 520 pulses or signals the event, if there is enough data in the circular buffer.
- the consumer thread 522, 524 reads the data from the buffer and calls the callback in application with pointer to acquired data or sends a message to the application window.
- two devices 502, 504 have three channels 506, 508, 510, and two client applications 512, 514 retrieve the data from the channels 506, 508, 510.
- each client application 512, 514 retrieves data from two channels 506, 508 and 508, 510.
- the DS process creates separate thread that acquires data from the port. This thread is blocked waiting while data arrives on serial port. The data is analyzed, validated, sorted according to channel and stored in ring buffer. Thus data is stored continuously for each channel in its own ring buffer. Creating of separate thread for each serial device enables independence of data acquisition on separate devices .
- the Data Server provides data from UM sensor to client applications. It acquire and buffers data from serial port. This data is polled by client applications.
- data acquisition is based on producer-consumer scheme.
- the producer thread reads the data from serial port, checks its validity and places data into the buffers for each channel. The producer thread waits on the channel for new data from the serial port .
- the producer thread is implemented in class "CDevice".
- class "CDevice” For each new device connected to serial port new instance of "CDevice” is created and new thread is run.
- the "CDevice” class is based on CWinThread class and "IDevice” interface; IDevice is based in IUnknown.
- RunDevice function of the CDevice, BOOL CDevice: :RunDevice (LPCSTR IpszPortName, int BaudRate, int devicelD) , obtains the port name, BaudRate and device signature. This function tries to open specified port and checks whether it gets the valid data from port. It returns TRUE only if the open of port successful and valid UM batch is received. Inside of this function the new thread for data acquisition is created.
- CDevice is based in IDevice - thus it implements the IDevice interface and supports reference count.
- the instance of this class is deleted through call to Release function that decreases the reference count, breaks the acquisition loop if necessary and deletes the CDevice object .
- CDevice includes the instance of "CUMDSerPort" class, based on CSerial . Port .
- Serial port in DataServer is opened for overlapped I/O. This class is used for encapsulation of data and function for serial port. It includes the function, OpenDevCommun, that obtains the name of the port and baud rate. It opens the port in overlapped I/O mode. The data from port is read through the Receive function.
- int CSerialPort Receive (void* IpBuf, DWORD nBufLen, DWORD timeout, DWORD retryPeriod) Receive function reads the data from port synchronously, even in the case the port is open for overlapped I/O. It obtains the buffer, number of bytes to read, time out and retry check period. The function returns either a time out or a specified number of bytes received on serial port. It returns a number of bytes actually read from the serial port. The port is automatically closed by constructor of CSerialPort.
- CDevice class is derived from CWinThread it has three key overridables - Initlnstance.Run and Exitlnstance .
- the Run function includes the main loop with acquisition. The loop is broken only when the reference count of the device reaches zero. In the loop, data is read from serial port, the validity of the data checked and the data put to channel (s) buffers, one buffer for each channel. Also in the loop, data saving to a file may be performed.
- the DataServer can automatically find a sensor device on one of the serial port and open it. This action is supplied through global function,
- HRESULT OpenDevice (/* [string] [in] */ _LPCSTR IpszPortName, int devicelD, /* [out]* IDEV_ PTR_ RPC_FAR *lplpIDevice)
- This function obtains the name of serial port (if the string is "NULL", four first ports are searched ) , device signature (currently not checked) and address of variable with result. It returns S_OK if the device was found and run successfully.
- the acquired data from UMDevice is kept in the buffer until the client applications retrieve it.
- the data is kept in instances of CChannel class. Each instance of this class keeps buffer with corresponding data. This buffer is updated by producer thread, run by CDevice: : Run function.
- CDevice class keeps dynamic array of pointers to instances of CChannel class.
- the loop inside of CDevice : Run dispatches data between the buffer in instances of different channels.
- Each instance of CChannel class keeps the buffer for the data and list of clients retrieving the data from this channel.
- CChannel (int channellD, int samples_size) ; All the data is kept in the array of mailboxes, declared according Moshe specifications: CArray ⁇ MAILBOX, MAILBOX& > m_SamplesBuffer; In the constructor the proper size of array with mail boxes is allocated.
- Each instance of CChannel keeps the information about clients connected to specific channels. Information about clients is kept in the CClientlnfo structure, the CChannel keeps the dynamic array of pointers to those structures. Each time new client is connected, the new instance of CClientlnfo is created, the client application obtains its index in the array.
- HRESULT CChannel : ReadSamples (int hClient, int samples, MAILBOX *pMailBoxes, int *pFilledBoxes )
- ReadSamples function obtains the index of the client in the array of CClientlnfo structures, number of samples the client intends to get, pointer to buffer (pMailBoxes) , and address of the integer to be filled with actual number of data read. It waits on synchronization object, so the CPU time is not wasted. Depending on the number of requested samples, it waits and then obtains the batch with a few samples in the buffer pointed by pMailBoxes.
- the CChannel class keeps the current "write” position, while each client has the "read” position in CClientlnfo structure.: struct CClientlnfo ⁇ public:
- the client keeps the index of its CClientlnfo structure and this structure keeps information about the client for DataServer.
- CChannel: :AddNewClient (int *hClient) is called.
- This function return the index in new CClientlnfo through the hClient parameter, this index is used later in ReadSamples function.
- the DataServer application keeps the lock count of the client connections as a global variable _ - m_ NumberOfClients - public data member of the CDataServerApp class based on CWinApp.
- Two global functions used for managing of reference count include ULONG AddRefO and ULONG Release (). When Release function is called it decrements a reference count. When the reference count reaches zero, the function posts WM_COMMAND with IDOK to the dialog, which operation closes the DataServer application.
- the DataServer is registered as RPC server through the function, RegisterDataServer ( ) .
- This function reads the name of the protocol from umd.ini file.
- UnregisterDataServer ( ) called during shutdown of DataServer closes the RPC service.
Abstract
Description
Claims
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
AU10708/00A AU1070800A (en) | 1998-10-27 | 1999-10-27 | Method and apparatus for providing a direct communication link between a plurality of users independent of a server |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10579498P | 1998-10-27 | 1998-10-27 | |
US60/105,794 | 1998-10-27 |
Publications (2)
Publication Number | Publication Date |
---|---|
WO2000025468A2 true WO2000025468A2 (en) | 2000-05-04 |
WO2000025468A3 WO2000025468A3 (en) | 2000-10-05 |
Family
ID=22307820
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/IB1999/001865 WO2000025468A2 (en) | 1998-10-27 | 1999-10-27 | Direct communication link between a plurality of users independent of a server |
Country Status (2)
Country | Link |
---|---|
AU (1) | AU1070800A (en) |
WO (1) | WO2000025468A2 (en) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107423247A (en) * | 2016-05-20 | 2017-12-01 | 北京迪文科技有限公司 | A kind of method of Intelligent treatment serial data |
CN115277707A (en) * | 2022-07-15 | 2022-11-01 | 京东科技信息技术有限公司 | Service processing method, device, electronic equipment and storage medium |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO1993002622A1 (en) * | 1991-08-07 | 1993-02-18 | Software Solutions Limited | Operation of computer systems |
WO1998040009A1 (en) * | 1997-03-08 | 1998-09-17 | Graham Francis Murphy | Diagnostic apparatus |
US5810747A (en) * | 1996-08-21 | 1998-09-22 | Interactive Remote Site Technology, Inc. | Remote site medical intervention system |
EP0967764A2 (en) * | 1998-06-25 | 1999-12-29 | Siemens Information and Communication Networks, Inc. | Improved apparatus and methods to realize H.323 proxy services |
-
1999
- 1999-10-27 AU AU10708/00A patent/AU1070800A/en not_active Abandoned
- 1999-10-27 WO PCT/IB1999/001865 patent/WO2000025468A2/en active Application Filing
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO1993002622A1 (en) * | 1991-08-07 | 1993-02-18 | Software Solutions Limited | Operation of computer systems |
US5810747A (en) * | 1996-08-21 | 1998-09-22 | Interactive Remote Site Technology, Inc. | Remote site medical intervention system |
WO1998040009A1 (en) * | 1997-03-08 | 1998-09-17 | Graham Francis Murphy | Diagnostic apparatus |
EP0967764A2 (en) * | 1998-06-25 | 1999-12-29 | Siemens Information and Communication Networks, Inc. | Improved apparatus and methods to realize H.323 proxy services |
Non-Patent Citations (1)
Title |
---|
SCHULZRINNE H ET AL: "Signaling for Internet telephony" PROCEEDINGS SIXTH INTERNATIONAL CONFERENCE ON NETWORK PROTOCOLS (CAT. NO.98TB100256), PROCEEDINGS SIXTH INTERNATIONAL CONFERENCE ON NETWORK PROTOCOLS, AUSTIN, TX, USA, 13-16 OCT. 1998, pages 298-307, XP002139514 1998, Los Alamitos, CA, USA, IEEE Comput. Soc, USA ISBN: 0-8186-8988-9 * |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107423247A (en) * | 2016-05-20 | 2017-12-01 | 北京迪文科技有限公司 | A kind of method of Intelligent treatment serial data |
CN115277707A (en) * | 2022-07-15 | 2022-11-01 | 京东科技信息技术有限公司 | Service processing method, device, electronic equipment and storage medium |
Also Published As
Publication number | Publication date |
---|---|
AU1070800A (en) | 2000-05-15 |
WO2000025468A3 (en) | 2000-10-05 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US5897498A (en) | Ultrasonic diagnostic imaging system with electronic message communications capability | |
EP0844581B1 (en) | Ultrasonic diagnostic imaging system with data access and communications capability | |
US5891035A (en) | Ultrasonic diagnostic imaging system with data access and communications capability | |
US5938607A (en) | Ultrasonic diagnostic imaging system with access to reference image library | |
US6871211B2 (en) | Intranet-based medical data distribution system | |
JP2001516930A (en) | A packet-based telemedicine system that communicates information between a central monitoring station and a remote patient monitoring station | |
CA2216123A1 (en) | Ultrasonic diagnostic imaging system with universal access to diagnostic information and images | |
EP1015967A1 (en) | Method and system for synchronized acquisition, processing and sharing of instrumentation data and for synchronized control in a client-server network | |
US20050216311A1 (en) | Communications system and a method of processing medical data | |
JP2003319913A (en) | Method and system for distributing biological information | |
CN110867257A (en) | Remote consultation system | |
WO2000025468A2 (en) | Direct communication link between a plurality of users independent of a server | |
US7383358B1 (en) | System and method for remote servicing of in-field product | |
JP2003116796A (en) | Medical examination-guidance support system and medical examination-guidance support method of in-home treatment adaptable patient | |
US20030055682A1 (en) | Remote medical system | |
JP2018147472A (en) | Medical device control in remote medical care system | |
WO2005008490A2 (en) | A communication system supporting communication between executable applications | |
US6581091B1 (en) | Program parameter updating method | |
JPH11120261A (en) | Home medical treatment system | |
US8650308B2 (en) | Methods and apparatus for client-side context managers | |
Sclabassi et al. | The multi-media medical monitoring, diagnosis, and consultation project | |
JP7122723B1 (en) | mobile automatic notification system | |
EP1349101A2 (en) | Ultrasonic diagnostic imaging system with electronic message communications capability | |
Sims et al. | An architecture for the automatic acquisition of vital signs by clinical information systems | |
CN117153314A (en) | Medical patient receiving information synchronization system and application method thereof |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
ENP | Entry into the national phase |
Ref country code: AU Ref document number: 2000 10708 Kind code of ref document: A Format of ref document f/p: F |
|
AK | Designated states |
Kind code of ref document: A2 Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GD GE GH GM HR HU ID 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 UZ VN YU ZW |
|
AL | Designated countries for regional patents |
Kind code of ref document: A2 Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG |
|
121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
AK | Designated states |
Kind code of ref document: A3 Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GD GE GH GM HR HU ID 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 UZ VN YU ZW |
|
AL | Designated countries for regional patents |
Kind code of ref document: A3 Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG |
|
DFPE | Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101) | ||
REG | Reference to national code |
Ref country code: DE Ref legal event code: 8642 |
|
122 | Ep: pct application non-entry in european phase |