Abstract
A method for integrating a non-supported dental imaging device into dental imaging software operates on a computer which is coupled to a display that is capable of displaying dental x-rays and dental photographs. An originally supported dental imaging device has an API binary file with an original filename accessible to the computer. The method includes the steps of creating a replacement alternate API binary file which contains equivalent functionality as the API binary file of the original supported dental imaging device and placing the replacement alternate API binary file either onto or accessible to the computer. The replacement alternate API binary file has the same filename as does the original filename of the API binary file of the originally supported dental imaging device. The method also includes the step of having the replacement alternate API binary file operated on by the dental imaging software by means of the computer. The dental imaging software is not aware the dental imaging software is not communicating with the originally supported dental imaging device. The replacement alternate API binary file delivers image data acquired by the non-supported imaging device to the dental imaging software.
Claims
1. A computer-implemented method for integrating a non-supported dental imaging device into dental imaging software operating on a computer coupled to a display being capable of displaying dental x-rays and dental photographs wherein an originally supported dental imaging device has an API binary file or files with an original filename or filenames, respectively, either directly or indirectly accessible to the computer, said computer-implemented method comprises the steps of: a. creating a replacement alternate API binary file or files which contain equivalent functionality as the API binary file or files of the original supported dental imaging device; b. placing said replacement alternate API binary file or files either onto or accessible to the computer wherein said replacement alternate API binary file or files have the same filename or filenames as do the original filename or filenames of the API binary file or files of the originally supported dental imaging device; c. having said replacement alternate API binary file or files operated on by the dental imaging software by means of the computer wherein the dental imaging software is not aware the dental imaging software is not communicating with the originally supported dental imaging device; and d. having said replacement alternate API binary file or files deliver image data acquired by the non-supported imaging device to the dental imaging software.
2. A computer-implemented method for integrating a non-supported dental imaging device into dental imaging software operating on a computer according to claim 1 wherein said computer-implemented method includes the step of renaming the original filename or filenames of the API binary file or files of the originally supported dental imaging device on the computer.
3. A computer-implemented method for integrating a non-supported dental imaging device into dental imaging software operating on a computer according to claim 1 wherein said computer-implemented method includes the step of deleting the original filename or filenames of the API binary file or files of the originally supported dental imaging device on the computer.
4. A computer-implemented method for integrating a non-supported dental imaging device with dental imaging software operating on a computer according to claim 1 wherein the computer includes a hardware-based microprocessor and a memory coupled to the microprocessor.
5. A computer-implemented method for integrating a non-supported dental imaging device with dental imaging software operating on a computer according to claim 1 includes a non-transitory computer-readable medium storing computer-executable application programming interface (API) for use with the computer that includes a set of instructions which allows integration of the non-supported dental imaging devices into a dental imaging software.
6. A computer-implemented method for integrating a non-supported dental imaging device with dental imaging software operating on a computer according to claim 1 wherein the dental imaging software is a legacy dental imaging software application.
7. A computer-implemented method for integrating a non-supported dental imaging device with dental imaging software operating on a computer according to claim 1 wherein the dental imaging software application is a proprietary dental imaging software application.
8. A computer-implemented method for integrating a non-supported dental imaging device with dental imaging software operating on a computer according to claim 1 wherein a Markush group of non-supported dental imaging devices consists of 2D intraoral x-ray sensors, 3D intraoral x-ray sensors, 2D extraoral x-ray sensors, 3D extraoral x-ray sensors, dental camera, dental image data sources, dental imaging acquisition devices, dental images stored in a non-volatile memory such as either a hard disk drive or a flash drive, imaging plate scanner sensors and other diverse dental image sources.
9. A computer-implemented method for integrating a non-supported dental imaging device with dental imaging software operating on a computer according to claim 1 wherein a computer operates to communicate, translate, forward, delete input received or sent to the dental imaging software by means of said replacement alternate API binary file or files in order to create expected requests and responses to and from the dental imaging software thereby allowing support for a specific previously unsupported dental imaging device by the dental imaging software while the dental imaging software is configured to support an originally supported imaging device.
10. A computer-implemented method for integrating a non-supported dental imaging device with dental imaging software operating on a computer according to claim 1 wherein an alternate application programming interface (API) controls two or more connected dental imaging devices simultaneously.
11. A computer-implemented method for integrating a non-supported dental imaging device into dental imaging software operating on a computer coupled to a display being capable of displaying dental x-rays and dental photographs wherein an originally supported dental imaging device has an API binary file with an original filename accessible to the computer, said computer-implemented method comprises the steps of: a. creating a replacement alternate API binary file which contains equivalent functionality as the API binary file of the original supported dental imaging device; b. placing said replacement alternate API binary file either onto or accessible to the computer wherein said replacement alternate API binary file has the same filename as does the original filename of the API binary file of the originally supported dental imaging device; c. having said replacement alternate API binary file operated on by the dental imaging software by means of the computer wherein the dental imaging software is not aware the dental imaging software is not communicating with the originally supported dental imaging device; and d. having said replacement alternate API binary file deliver image data acquired by the non-supported imaging device to the dental imaging software.
12. A computer-implemented method for integrating a non-supported dental imaging device into dental imaging software operating on a computer according to claim 11 wherein said computer-implemented method includes the step of renaming the original filename of the API binary file of the originally supported dental imaging device on the computer.
13. A computer-implemented method for integrating a non-supported dental imaging device into dental imaging software operating on a computer according to claim 11 wherein said computer-implemented method includes the step of deleting the original filename of the API binary file of the originally supported dental imaging device on the computer.
Description
DESCRIPTION OF THE DRAWINGS
[0045] FIG. 1 is a conceptual diagram of a networking system including a desktop computer, a laptop computer, a server, a server, a network, a server, a tablet device and a private network group according to U.S. Patent Publication No. 2013/0226993.
[0046] FIG. 2 is a conceptual diagram of a cloud-based server engine of the networking system of FIG. 1.
[0047] FIG. 3 is a conceptual diagram of a cloud-based client coupled to the networking system of FIG. 1.
[0048] FIG. 4 is a schematic diagram of a networking system including a desktop computer, a laptop computer, a server, a server, a network, a server, a tablet device and a private network group according to U.S. Pat. No. 5,434,418.
[0049] FIG. 5 is a schematic diagram of an x-ray diagnostics installation having a computer and a display according to U.S. Pat. No. 6,091,982.
[0050] FIG. 6 is a schematic diagram of the computer and the display of the x-ray diagnostics installation of FIG. 5.
[0051] FIG. 7 is a schematic diagram of a mobile signal pick-up unit at a remote computer of the x-ray diagnostics installation of FIG. 5.
[0052] FIG. 8 is a schematic diagram of a universal image capture manager according to U.S. Patent Publication No. 2011/0304740.
[0053] FIG. 9 is a schematic diagram of a software module architecture used in the universal image capture manager of FIG. 8.
[0054] FIG. 10 is a schematic diagram of a system for imaging a patient's body part according to U.S. Patent Publication No. 2014/0350379.
[0055] FIG. 11 is a schematic diagram of a server of the system for imaging a patient's body part of FIG. 10.
[0056] FIG. 12 is a schematic diagram of an apparatus 1201 for the acquisition and visualization of dental radiographic images according to U.S. Pat. No. 7,505,558
[0057] FIG. 13 is a schematic diagram of a dental office that uses proprietary or legacy dental imaging software and which is integrated to an originally supported imaging device but is not capable of integrating with an originally unsupported imaging device and is not using the claimed invention.
[0058] FIG. 14 is a schematic diagram of a dental office that uses proprietary or legacy dental imaging software and which is capable of integrating with an originally unsupported imaging device according to the present invention.
[0059] FIG. 15 is a schematic diagram of a flowchart of a method that integrates originally unsupported imaging devices into either legacy or proprietary dental imaging software according to the present invention.
GLOSSARY OF TERMS
Application Programming Interface (API)
[0060] An application programming interface (API) is a term used to describe a set of protocols, routines, functions and methods that specify the inputs, outputs, operations and underlying types of data and information for a specific software component and which component is meant to be integrated/used by another software component or application. API is a generalized term and includes interfacing via an executable, a control, or a library such as a dynamic link library. Functions, methods, parameters, messages are all API related references and are common types of methods used in APIs. The application programming interface (API) is a set of routines, protocols, and tools for building software.
Binary API File
[0061] A Binary API File is defined as the physical API file that is physically located on the file system of a computing device and/or coupled to a computing device from another storage device.
Renaming Binary API File
[0062] Renaming Binary API File is the physical act of renaming the Binary API file to another name on the file system or storage device.
Replacement Binary API File
[0063] A Replacement Binary API File is a newly created physical file which is placed upon the computing device file system or coupled to it via another storage device and which physical file has identical name of the Binary API File. The Replacement API File has identical functions (APIs) exposed as the Binary API File. In other words, the Replacement API file is a Clone of the Binary API File from an API point of view.
Selected/Current/Originally Supported/Native Dental Imaging Acquisition Device
[0064] A Selected/Current/Originally Supported/Native dental imaging acquisition device is referencing which specific proprietary dental imaging device or devices the dental imaging software is expected to acquire from; and which were originally programmed into that dental imaging software as a supported dental imaging device. This is a preference or setting in the dental imaging software that defines what acquisition device or devices can be used by the user of the imaging software. This may be a fixed setting (the dental imaging application software only supports a single or limited set of devices) or it may be from a menu or other means of user or system selection of supported non-standards based image acquisition devices. The selected or current device means the currently configured setting for a specific proprietary dental imaging device in the imaging software.
Computer/Computing Device
[0065] A computer is a hardware microprocessor based computing device. Computer, computer device, computing device, computer hardware device terms are interchangeable. The computer is a physical hardware device and has a microprocessor, a RAM and a non-volatile memory. The computer has the ability to execute software. A display may be a monitor, computer screen or a display monitor. These terms are interchangeable. The computer is directly or indirectly coupled to the display.
Legacy Imaging Software or Application
[0066] Legacy Imaging Application is an existing/older dental imaging software that is not updated regularly and/or is not updated to support specific imaging devices that have been released since the software has been in existence.
Proprietary Imaging Software or Application
[0067] Proprietary Imaging Software or Application is a dental imaging software that via proprietary means supports dental imaging acquisition devices. The proprietary imaging application may support open standards as well such as Twain/Dicom communication and/or others but at a minimum at least one specific dental imaging device is supported via non-open standards via using an API to the specific imaging device.
DESCRIPTION OF THE PREFERRED EMBODIMENT
[0068] Referring to FIG. 13 a dental office 1300 includes a computer 1310 and a display 1311. The computer 1310 includes a microprocessor 1312, a memory 1313, such as a random access memory (RAM), and a non-volatile storage or memory 1314, such as either a hard disk or a flash memory, for storing software or data. The computer 1310 may be coupled either directly or indirectly to the display 1311. The display 1311 is capable of displaying dental images including dental x-rays and dental photographs. The computer 1310 has an operating system 1315 which may be either a Windows based operating system or a Mac OS X based operating system or another compatible operating system. The computer 1310 may also be a mobile computer, such as an iPad, an Android based tablet, a Microsoft Surface based tablet, a phone, or any other proprietary device with an adequate microprocessor, an operating system and a display which is capable of displaying dental images including dental x-rays and dental photographs.
[0069] Still referring to FIG. 13 the dental office 1300 also includes dental imaging software 1320 having a sub-section 1330 which integrates and acquires images from a specific supported or proprietary imaging device using the API binary file 1340 of the specifically supported proprietary imaging device. The dental imaging software 1320 is either legacy dental imaging software or proprietary dental imaging software. The first imaging device 1350 is a specifically originally supported native imaging device. The second imaging device 1360 is also a specifically supported native imaging device. The first imaging device 1350 may be either a 2D intraoral or a 2D extraoral dental imaging device. The second imaging device 1360 may be either a 3D intraoral or a 3D extraoral dental imaging device. The group of supported dental imaging devices may consist of 2D intraoral x-ray sensors, 3D intraoral x-ray sensors, 2D extraoral x-ray sensors, 3D extraoral x-ray sensors, dental camera, dental image data sources, dental imaging acquisition devices, dental images stored in a non-volatile memory such as either a hard disk drive or a flash drive, imaging plate scanner sensors and any other diverse dental image sources.
[0070] Referring still further to FIG. 13 the dental office 1300 does not use the claimed invention. The computer 1310 operates imaging software 1320. The dental imaging software 1320 may be either running locally on the computer 1310 or displaying the results of software operating upon a remote server, such as either web-based dental imaging software or cloud-based dental imaging software. The imaging software 1320 may be either directly controlling or indirectly controlling the first imaging device 1350 using sub-section 1330 of the dental imaging software 1320. The dental imaging software 1320 may also be either directly or indirectly controlling the second imaging device 1360 using sub-section 1330 of the dental imaging software 1320. The sub-section 1330 communicates with the API binary file 1340 which in turn communicates with at least one of the first and second imaging devices 1350 and 1360 to direct imaging or receive images. The API binary file 1340 is stored in either the non-volatile storage 1314, or the memory 1313 on the computer 1310 or in another either non-volatile storage or memory either coupled to the computer 1310 or accessible by computer 1310. The Imaging software 1320 communicates to the sub-section 1330 for the purpose of controlling the actions of at least one of the first and second imaging devices 1350 or 1360 using the API binary file 1340 thereof. The sub-section 1330 receives communication or status from the specific imaging device by means of its API binary file 1340 which communicates directly or indirectly with the device driver of one of the first and second imaging devices 1350 and 1360. The communications between the imaging software 1320 and sub-section 1330 and to binary imaging device API binary file 1340 are proprietary in nature. The API binary files are not universal for imaging devices and no two imaging devices typically have the same functions, parameters, or overall operation in their API binary file for that specific imaging device. Dental imaging software 1320 commands the computer 1310 to initiate and/or receive image or image data from either the first imaging device 1350 or the second imaging device 1360 by means of communication through sub-section 1330 and its API binary file 1340. After either an image or image data has been enacted by API binary file 1340 it is made available to the dental imaging software 1320 by means of the sub- section 1330 or other means for any additional processing, storage and ultimately display upon computer 1310.
[0071] Referring to FIG. 14 a dental office 1400 includes a computer 1410 and a display 1411. The computer 1410 includes a microprocessor 1412, a memory 1413, such as a random access memory (RAM), and a non-volatile storage or memory 1414, such as either a hard disk or a flash memory, for storing software or data. The computer 1410 may be coupled either directly or indirectly to the display 1411. The display 1411 is capable of displaying dental images including dental x-rays and dental photographs. The computer 1410 has an operating system 1415 which may be either a Windows based operating system or a Mac OS X based operating system, or another compatible operating system.
[0072] Referring still to FIG. 14 the dental office 1400 uses the claimed invention. The computer 1410 operates imaging software 1420. The computer 1410 may also be a mobile computer, such as an iPad, an Android based tablet, a Microsoft Surface based tablet, a phone or any other proprietary device with an adequate microprocessor, operating system and display capability. The dental office 1400 also includes imaging software 1420 having a sub-section 1430 which integrates and acquires images from a specific or proprietary imaging device using the API binary file 1440 of the specific or proprietary imaging device. The first imaging device 1460 is an originally unsupported 2D imaging device. The second imaging device 1470 is also an originally unsupported 3D imaging device. The first imaging device 1460 may be a 2D intraoral or extraoral dental imaging device. The second imaging device 1470 may be a 3D intraoral or extraoral dental imaging device. Originally supported dental imaging devices may consist of 2D intraoral x-ray sensors, 3D intraoral x-ray sensors, 2D extraoral x-ray sensors, 3D extraoral x-ray sensors, dental camera, dental image data sources, dental imaging acquisition devices, dental images stored in a non-volatile memory such as either a hard disk drive or a flash drive, imaging plate scanner sensors, PSP devices and any other diverse dental image sources. Originally non-supported dental imaging devices that become supported using the claimed invention may consist of 2D intraoral x-ray sensors, 3D intraoral x-ray sensors, 2D extraoral x-ray sensors, 3D extraoral x-ray sensors, dental camera, dental image data sources, dental imaging acquisition devices, dental images stored in a non-volatile memory such as either a hard disk drive or a flash drive, imaging plate scanner sensors, PSP devices and any other diverse dental image sources.
[0073] Referring still further to FIG. 14 the imaging software 1420 may be either running locally on the computer 1410 or displaying the results of software operating upon a remote server, such as web/cloud based imaging software. The imaging software 1420 is communicating and/or controlling an originally/natively supported 2D intraoral or extraoral imaging device 1480 and/or an originally supported 3D intraoral or extraoral imaging device 1490. Sub-section 1430 of the imaging software includes integration to a specific proprietary imaging device API binary file 1440. The original specific imaging device API binary file 1440 that sub-section 1430 communicated with has been renamed to a different filename on computer 1410 or on another device accessible to computer 1410. The renamed original API binary 1450 is accessible to replacement API binary file 1440. The filename of replacement binary API file 1440 is named the same as the original specific proprietary imaging device API binary filename and contains identical or near-identical functions as original API binary which are called by the decoupled imaging software to support the specific imaging device natively. The specific imaging device is a previously supported 2D intraoral or extraoral dental imaging device 1480 or 1490 3D imaging device and/or the imaging device is a previously unsupported 2D imaging device 1460 or 3D intraoral or extraoral dental imaging device 1470.
[0074] Referring yet still further to FIG. 14 the subsection 1430 of the imaging software 1420 includes a replacement API binary file 1440 and shows the dental imaging software sub-section 1430 communicating with the replacement API binary and controlling either the original natively supported imaging devices 1480 and/or 1490 or the non-natively supported imaging devices 1460 and/or 1470. The imaging software is unaware that it is not communicating with the original natively supported imaging device API binary as the function/parameters called and values returned are identical to the original natively supported API binary file in the replacement API binary file 1440. When the imaging software sub-section 1430 communicates with replacement API binary 1440, the said API binary file 1440 communicates with the renamed original API binary file 1450 and relays the same functions and parameters as were communicated to it by means of the imaging software 1420 and its sub-section 1430; and which allows the original natively supported imaging devices 1480 and 1490 to continue to be supported in imaging software 1420. Replaced binary API file 1440 also communicates with non-supported imaging device 1460 and 1470 API/devices. Replacement API 1440 translates, forwards, adds and deletes functions or parameters received from the imaging software to be compatible with the previously non-supported imaging device 1460 or 1470 and their API. Replaced binary API file 1440 also translates or converts imaging device 1460 or 1470's API return codes, messages, or image data to be compatible with what sub-section 1430 of imaging software 1420 expects for functions, return values, and messages from the API binary file 1440. The imaging software subsection 1430 calls the same functions and/or parameters and/or methods for the originally natively supported device via the replacement API binary 1440 which has the same functions as the original renamed API binary 1450. The imaging software is not aware of any changes or that it is not communicating with the natively supported imaging devices via the original API binary file or files. The existing natively supported imaging devices 1480 and 1490 continue to operate and non-natively supported devices 1460 and 1470 can now operate within the decoupled imaging software. This is one hundred per cent (100%) transparent to the imaging software so that no changes are required to the legacy or proprietary imaging software application.
[0075] Referring to FIG. 15 and referencing FIG. 14 a computer-implemented method for integrating a non-supported dental imaging device into dental imaging software operates on the computer 1410 coupled to the display 1411 which is capable of displaying dental x-rays and dental photographs. An originally supported dental imaging device has either an API binary file or API binary files with either an original filename or filenames, respectively, either directly or indirectly accessible to the computer 1410. The computer-implemented method 1500 includes the steps of operating a legacy or proprietary dental imaging software application which controls acquisition from a 2D or 3D imaging device upon a computing device. In step 1510 the proprietary or legacy imaging software has been programmed to support specific 2D and/or 3D imaging devices using proprietary API's, and where the imaging software is configured to acquire images from one or more of the supported imaging devices. In step 1520 the original binary API file or files for an originally supported device has been renamed to another filename. In step 1530 a replacement API file with the same filename as the original API filename has been created and placed onto or accessible to the computing device. In step 1530 the replacement API file is enacted upon by the imaging software to acquire images and is not aware it is not communicating with the original supported device API. In step 1540 communication is received or initiated between the imaging software and the replacement binary API. In step 1550 any messages sent or received from devices or the legacy application are arbitrated to the proper proprietary API/device. In step 1560 any communicated between the API and the imaging software are translated, converted, etc. . . . transparently to the imaging application software. In step 1570 the image or image data is delivered from the previously supported or un-supported device transparently in that the imaging software does not know it is not receiving images or communication from the originally supported device and device API. Thereby allowing support for a specific previously unsupported dental imaging device by the dental imaging software while the dental imaging software is configured to support an originally supported imaging device. The computer-implemented method may include either the step of renaming the original filename or filenames of either the API binary file or the API binary files of the originally supported dental imaging device on the computer 1410 or the step of deleting either the original filename or the original filenames of either the API binary file or the API binary files of the originally supported dental imaging device on the computer 1410. An alternate application programming interface (API) may control two or more connected dental imaging devices simultaneously. The computer-implemented method includes a non-transitory computer-readable medium storing computer-executable application programming interface (API) for use with the computer. The non-transitory computer-readable medium includes a set of instructions which allows integration of the non-supported imaging devices into dental imaging software.
[0076] From the foregoing it can be seen that integration of non-supported dental imaging devices into legacy and proprietary dental imaging software has been described. It should be noted that the sketches are not drawn to scale and that distances of and between the figures are not to be considered significant.
[0077] Accordingly it is intended that the foregoing disclosure and showing made in the drawing shall be considered only as an illustration of the principle of the present invention.
