Title of Invention

A METHOD OF STORING A DENTAL IMAGE OF A PATIENT S DENTAL REGION

Abstract A method of storing a dental image of a patient's dental region, comprising receiving, at a dental image storage and retrieval system (32), a patient identity of the patient for whom the dental image is to be stored, receiving, at the dental image storage and retrieval system, the dental image from an input device (94), automatically, by a programmed computer (78), determining a source of the dental image, generating, by the programmed computer, a prompt for an image identifier' that describes at least one characteristic of the dental image, receiving, at the programmed computer, the image identifier in response to the prompt, generating, by the programmed computer, a generated file name for the dental image, the generated file name having the patient identity, the source, and the image identifier as text characters, the patient identity separated from each of the source and the image identifier by respective instances of a reserved character and providing the dental image for storage on a storage device (74) in association with the generated file name, whereby the file name on the storage device indicates characteristics of the dental image in a manner that can be automatically parsed, thereby improving searching efficiency.
Full Text The present invention relates to a method of storing a dental image of a patient's dental region.
[0001] The present invention relates to generally to medical imaging in the field of
dentistry and more particularly relates to a method and system for storing and manages dental images on a computer or a computer network.
Background of the Invention
[0002] Dentists have long benefited from recorded images of their patient's teeth. For
some time now, X-ray technology has provided a straightforward and cost-effective means for dentists to capture images of their patient's teeth. At a minimum, X-ray images are an important diagnostic tool, allowing the dentist to "see inside" the mouth, a single tooth and/or several teeth of the patient. X-ray dental images have a number of other benefits, in that pictures can then be stored in the patient's file for future reference, to allow the dentist to track problems in a patient's teeth over time. X-ray pictures can also be used to show a patient where defects may exist in the patient's teeth, and to help the dentist explain suggested treatments to address those defects.
[0003] Dental imaging has come a long way since the X-ray. Digital imaging of dental
images is now becoming commonplace. Now dentists can choose to use a variety of imaging devices, such as intra-oral cameras, scanners, digital video and the like to capture images of their patient's teeth. The above-described benefits of X-rays have been improved with these modem imaging devices. Of course, one problem that has arisen in conjunction with the increase in imaging technology is the need for equipment that will effectively manage those images. As the sheer volume of those images increase, enormous strain can be placed on the limited computer resources that are often present in dental offices.
[0004] A variety of prior art solutions are available to dentists to assist in managing
dental images. One well-known software package that can be used to manage dental images is Vipersoft, by Integra Medical, 727 E. Utah Valley Dr. Ste 500, American Fork, Utah 84003.
(http://www.vipersort.coni). Vipersoft is essentially an index based database package (using C TREE database on DentriX software package) that can be used to store, retrieve and otherwise manage a plurality of dental images. In a typical larger-scale dental office, the Vipersoft data file will be stored on a central file server in the administration area of the dental office. This central file server will be connected to a plurality of client machines in the dental operating suites. The client machines in each of the suites will then be able to access the centrally stored data file. However, one problem with the prior art is that, due to the nature of Index databases, any time a dentist needs to access even a single image on the centrally stored data file from a client machine in a dental suite, the entire database is loaded from the central file server to the client machine. This can be an enormous strain on the otherwise limited computing resources of the dental office, straining the bandwidth of the local area network within the dental office, and stressing the CPU and RAM of the local client machine. A further problem with Vipersoft is the proprietary nature of the database file name system, which can require a dentist to undergo an expensive and complicated file conversion should the dentist decide to switch to another dental image storage and retrieval system. Furthermore, a corruption of even a small part of the Vipersoft database index file could result in the loss of an entire collection of dental images.
Summary of the Invention
[0005] It is therefore an object of the present invention to provide a novel dental image
storage and retrieval apparatus that obviates or mitigates at least one of the above-identified disadvantages of the prior art.
[0006] In a first aspect of the invention there is provided a method of storing a dental
image comprising:
receiving an identity of a patient for whom the dental image is to be stored; capturing a dental image from the patient's dental region; generating a unique file name for the image; and,
outputting the image file for storage on a file storage device under the unique file name to identify the image on the file device.
[0007] In a particular implementation of the first aspect, the image file is stored as a
single file using a native file system of the storage device. The native file system can be any known native file system such as FAT32, NTFS, Macintosh File System, or the Linux File System.
[0008] In a particular implementation of the first aspect, the capturing step is performed
using an image capture device selected from the group of intra oral cameras, scanners, and X-Rays.
[0009] The unique file name can includes a first identifier respective to the patient and
a second identifier respective to a dental region captured in the dental image. The selected dental region can be a specific tooth respective to the patient and the second identifier includes a code representing the specific tooth. The unique file name can include another identifier representing the date and/or time when the dental image was captured or created. The unique file name can also include an additional identifier representing the date and/or time when the dental image was modified. The unique file name can also include a fifth identifier representing a type of imaging device used to perform the capturing step.
[0010] In a second aspect of the invention, there is provided a method of retrieving a
dental image comprising:
receiving an identity of a patient;
retrieving at least a portion of dental images respective to the patient from a storage device that are stored under a native file system of the storage device according 10 the identity;
presenting a plurality of the retrieved dental images to a user for browsing;
retrieving a dental image for processing when the user selects one of the presented dental images; and
identifying a next portion of the images from the storage device when the user declines to select one of the presented dental images; and
repeating the presenting, retrieving the dental image and identifying steps until a criteria is established for terminating the method.
[0011] In a third aspect of the invention, there is provided a system for storing and
retrieving dental images comprising a dental image file server for storing a plurality of dental images. The dental images are stored on the file system using a unique file name for each image. The file server is connected to at least one dental image client that is for delivering dental images to the server in order to store the images on the server. The dental image client is also operable to retrieve dental images from the dental image file server. A dental image input device, such as an intra-oral camera or the like, is connected to the client for receiving a captured dental image from a patient. A dental image output device is connected to the client for presenting the dental images to a user, such as a dentist.
Brief Description of the Drawings
[0012] The present invention will now be explained, by way of example only, with
reference to certain embodiments and the attached Figures in which:
Figure 1 is a schematic representation of a dental image storage and retrieval system in accordance with an embodiment of the invention;
Figure 2 is a schematic representation of the RAID storage device of Figure 1;
Figure 3 is a flow-chart of a method for storing dental images in accordance with another embodiment of the invention; and,
Figure 4 is a How-chart of a method for retrieving dental images in accordance with another embodiment of the invention.
Detailed Description of the Invention
[0013] Referring now to Figure 1, a dental image storage and retrieval system is
indicated generally at 30. System 30 includes a dental image file server 34 in a server room 38, located in, or otherwise connected to, a dental office. File server 34 is connected via a network 40 lo a plurality of denial image clients 42 (shown on Figure 1 as clients 42a, 42b ... 42n) which are each located in their own dental operating suite 46 (shown on Figure 1 as suites 46a, 46b ... 46n) located within the denial office. Clients 42 are typically ergonomically accessible to a patient 54 and/or a dentist 56, when they are located within the suite 46, so that the dentist 56 can operate on the client 42, and/or the patient 54 can view information displayed by the client 42.
[0014] Dental image file server 34 comprises a CPU tower 58 that interconnects a
monitor 62 (and/or other output devices), a keyboard 66, a mouse 70 (and/or other input devices), and a redundant array of inexpensive discs 74 or RAID 74 (and/or other storage devices). Tower 58 further includes a network interface card (or other network interface means) for managing incoming and outgoing communications with clients 42. As will be explained in greater detail below, RAID 74 stores a plurality of dental images that can be accessed by clients 42 via network 40. Thus, the size of RAID 74 will typically depend on the number of images lhat the particular dental offices wishes to maintain. Further details about RAID 74 will be discussed in greater detail below.
[0015] The hardware and protocol to implement network 40 is not particularly limited,
and can include an Hthernet local area network, a wide area network, and 802.lib wireless network, the Internet, an intranet or the like.
[0016] Dental image clients 42 comprise a CPU tower 78 that interconnects a monitor
82 (and/or other output devices), a keyboard 86, a mouse 90, an intra-oral camera 94 (and/or
other input devices), "lower 78 further includes a network interface card (or other network interface means) for managing incoming and outgoing communications with server 34 via network 40. In general terms, client 42 is operable to retrieve images stored on RAID 74 and present such retrieved images on monitor 82. Similarly, client 42 is operable to capture dental images of patient 54 using intra-oral camera 94 and send those images to server 34 for storage on, and later retrieval from, RAID 74.
[0017] The file system used to store dental image files on RAID 74 is based on the
chosen or native operating system used to operate server 34. For example, where the operating system for server 34 is Microsoft WindowsXP, then the file storage system used to store dental image files on RAID 74 can be based on FAT32 (i.e. File Allocation Table that supports partitions larger than two gigabytes and pathnames greater that 256 characters) or NTFS (i.e. NT File System, the native file system of Windows NT). Other file systems will occur to those of skill in the art, such as the Macintosh file system or Linux file system. In general, it is presently preferred that the images stored on RAID 74, regardless of their file type (e.g. TIFF, JPKG, MPEG, PCX etc.) are stored as atomic files according to the file system of RAID 74.
[0018] Referring now to Figure 2, a tree diagram of a file structure of RAID 74 is
indicated at 100. In a present embodiment, file structure 100 is based on NTFS, and includes a parent directory 104 and a plurality of sub-directories 108 thereunder. Parent directory 104 can either be the root directory of RAID 74, or it can be a directory, or sub-directory thereunder as desired. In any event, it is presently preferred that, wherever parent directory 104 is located on RAID 74, parent directory 104 should be reserved for storing sub-directories 108 that are for storing a plurality of dental image files 110.
[0019] Sub-directories 108 are created and then reserved for individual patients 54 of
the dental office associated with system 30. Thus, the directory name format of each subdirectory 108 will include a unique patient identifier 112 for that particular patient 54, which can include any number of indicia such as the patient's name, social security number, and/or a unique file number assigned by the dental office, and/or a combination thereof. Whichever
indicia or indicium arc used for the identifier, it is presently preferred that a consistent format be used, based on accepted characters for the file system (in this case NTFS) used for RAID 74. Where multiple indicia are used, it is presently preferred that such indicia are delimited as separate fields by using particular reserved characters, such as hyphens "-", or underscores "_", and that such reserved characters are omitted from use in the actual indicia themselves. In this manner, the directory name can be parsed using its known name format, and the dental image directories therein searched and utilized, by individuals manually accessing RAID 74 (either through server 34 or through clients 42), or by software packages that may automatically search or otherwise utilize dental image directories of RAID 74 according to its NTFS file structure. In order to more consistently achieve the desired consistent directory name format, it is presently preferred, but not required, that such directory names on RAID 74 be automatically created by software executing on server 34 or client 42, rather than by manual creation of such directory names.
[0020] An exemplary naming format for patient identifier 112 is of the format shown in
Table I:
TABLE I
Directory Naming Format
SURNAME-Given name-Patient number
As can be seen by examining this format, it contains three text fields, each delimited by a hyphen "-". The first text field, SURNAME means the last name, or family name of the patient, and is typed in capital letters. The second text field, Given_name, means the patient's given name, typed in lower-case letters but with an initial capital letter for the given name. The third field, Patient number, is a unique number assigned to that patient by the dental office, which can be helpful to distinguish patients having identical surnames and given names.
[0021] Dental image files 110 of a particular patient 54 are thus stored under the sub-
directory 108 created for that particular patient. The file name format of each dental image file 110 will typically include a number of indicia such as a patient identifier, a file creation date, a
file creation time, a modification date, a description of the source from which the image was derived, and an image description. Also, as typically found in the NTFS file system, and the like, the image file name will also include a file type, which is typically indicated by the final three (or more) characters of the file name, preceded by a period or ".". (i.e. X.tif, X.jpg , X.pcx, X.gif etc., where X is the remainder of the file name.) The patient number can be the patient's social security number, and/or a unique file number assigned by the dental office, and/or a combination thereof. Whichever indicia for the file name is used, it is presently preferred that a consistent format be used, based on accepted characters for the file system (in this case NTFS) used for RAID 74. It is presently preferred that such indicia are delimited as separate fields by using particular reserved characters, such as hypens "-", or underscores "_", and that such reserved characters are omitted from use in the actual indicia themselves. In this manner, the file name can be parsed using its known file name format, and the dental images therein searched and utilized, by individuals manually accessing RAID 74 (either through server 34 or through clients 42), or by software packages that may automatically search or otherwise utilize dental images stored on RAID 74 according to the NTFS file structure. In order to more consistently achieve the desired consistent file name format, it is presently preferred, but not required, that such file names on RAID 74 be automatically created by software executing on server 34 or client 42, rather than by manual creation of such file names.
[0022] An exemplary file naming format for dental image 110 is of the format shown in
Cable II:
TABLE II
Filing Naming Format
SURNAMF-CYealion_date-Creation_time-Modification_date-Image_Source-
Image identification
As can be seen by examining this format, it contains six text fields, each delimited by a hyphen "-". The first text field, SURNAME is the last name, or family name of the patient, and is typed in capital letters, and is common with the SURNAME found in the name of the subdirectory 108 where the image resides. The second text field, Creation^date, is the date on
t which the image file was actually created, and will typically correspond with the day that the image was obtained from the patient. By the same token, the third field, Creation_time, is the time of the day on which the image file was created. Modification_date means a date on which the image was accessed and modified. While a record of file modification can also be seen in the modification information inherent to NTFS, it is presently preferred to hard-code this information into the file name, so that multiple modifications of the image file can be retained on RAID 70, and/or to distinguish from system maintenance modifications to the file, such as might occur during back-up procedures of RAID 70 and/or to allow for transport of such information should images be moved to another storage device based on another file system other than NTFS. hnage_Source refers to the particular device used to obtain the dental image, which could be comprised of codes such as, for example, "IOC" to refer to intra-oral camera 94, or "SCA" to mean a scanned image of an X-ray. Other types of image sources will occur to those of skill in the art. Finally, the Image identification is used to identify the actual image, and is typically comprised of a unique code common in the dental profession, such codes being used to identify a particular tooth, or set of teeth and/or the angle from which such images were taken. However, the particular structure of information used in Image identification is not particularly limited.
[0023] Referring now to Figure 3, a method for storing dental images is indicated
generally at 200. In order to assist in the explanation of method 200, it will be assumed that method 100 is performed using system 30. It is to be understood that the following discussion of method 200 will lead to further understanding of system 30. (However, it is to be further understood that system 30 and/or method 200 can be varied, and/or that method 200 need not be performed according the exact sequence shown in Figure 3, and/or that system 30 and method 200 need not work exactly as discussed herein in conjunction with each other, and that such variations are within the scope of the present invention.)
[0024] At step 210, the identity of the patient is received. When implemented on
system 30, this step can be implemented a number of ways. For example, when a patient 54 becomes a patient of the dental office associated with system 30, during the collection of his
initial intake data, his identity can be entered into file server 34, and as part of creating a database record on server 34 for patient 54, a sub-directory 108 is created for that particular patient 54 according to the above-described format. Another way step 210 can be implemented is directly by a dentist 56 (or other dental professional) who is working with a patient 54 by manually inputting the data using a client 42 in the suite 46 where the dentist 56 and patient 54 arc located. Other ways of receiving the identity of patient 54 will now occur to those of skill in the art. For purposes of explaining method 200, it will be assumed that sub-directory 108a shown on Figure 2 for patient 54a in suite 46a was created on RAID 74 on some previous date when patient 54a became a patient of the dental office associated with system 30. Thus, the step of receiving the identity of patient 54a will be assumed to occur on client 42a, through the act of dentist 56a selecting patient 54a's name from a menu of names of existing patients 54 belonging to the dentist office associated with system 30.
[0025] At step 220, a image of a dental feature of the patient is captured. When using
system 30, using the example of patient 54a in suite 46a, this step can be implemented by dentists 56a directing intraoral camera 94a towards a specific location in the mouth of patient 54a, and activating camera 94a to collect the desired image. Having activated camera 94a the image is transferred to CPU tower 78a. (Step 220 can be implemented in other ways however, depending on (he type of image capture equipment available on system 30.)
[0026] Next, at step 230 a file name unique to the patient and the captured image is
generated. When implemented on system 30 using the example of patient 54a in suite 46a, it is contemplated that CPU tower 78a will execute software that will create a file name for the captured image according to the format shown in Table 11.
Filing Naming Format
SURNAMK-Creation datc-Creation_time-Modification_date-Image_Source-
Image^ identification
When CPU lower 78a generates this file name, it will assemble the SURNAME from the SURNAME of patient 54a as obtained at step 210, it will assemble the Creation_date and Creation_time from the system clock of CPU tower 78a, and it will use the code "IOC", to represent intra-oral camaera 94a, which tower 78a will inherently know as being the source to capture the image at step 220. The final field, "Imagejdentification", will be manually inputted by dentist 56a, based on a prompt generated by tower 78a. Dentist 56a will effect such manual input by either by typing in the information using keyboard 86a, or using mouse 90a to select a predefined code from a menu offered by tower 78a via display 82a.
[0027] At step 240, the captured image will be outputted for storage on a file storage
device under the name generated at step 230. When step 240 is implemented on system 30 according to the foregoing example, CPU tower 78a will attach the file name generated at step 230 to the image captured at step 220, and, using the network protocols of network 40, deliver the image and the file name to file server 34, which in turn will save the image on RAID 74 under sub-directory 108a.
[0028] Referring now to Figure 4, a method for retrieving one or more dental image in
accordance with another embodiment of the invention is indicated generally at 300. Prior to execution of this method, it is assumed that the particular patient is already a patient of the dental office associated with system 30, and that a directory 108 containing dental images of that patient is stored on RAID 74 in accordance with file structure 100 - such images having been stored using method 200 or the like. Beginning at step 310, the identity of the patient is received. When implemented on system 30, this step can be implemented a number of ways, however, in one example it is assumed that patient 54a is in dental suite 46a, and that dentist 56a enters in the name of patient 54a into keyboard 86a, and this input is received by tower 78a.
[0029] Next, at step 320 at least a portion of the dental images of the identified patient
are retrieved from the directory associated with that patient. When implemented on system 30 according to the assumptions made above, tower 78a will send an instruction to server 34 to access directory 108a associated with patient 54a. A predefined number of images stored in directory 108a will then be downloaded over network 40 to tower 78a. The number of images that comprise the portion that are retrieved can depend on a number of factors. For example, where the directory 108a contains only one image, then the portion will be simply that one image. Where there are multiple images in directory 108a, then it is presently preferred to only retrieve only those number of images that can be presented as a plurality of thumbnails on display 82a, of a si/e that dentist 56a can make use of the thumbnail to determine which image or images the dentist 54a ultimately wishes to work with. Another criteria that can be used to determine what portion of directory l()8a to download is based on the bandwidth capacity of network 40, and/or other hardware resources of system 30. For example, where multiple dentists 56 are attempting to simultaneously execute method 300 on system 30, it can be desired to limit the portion of images that are downloaded as a portion of directory 108a, so as to reduce wailing times for each dentist. Other hardware constraints of system 30 can also used as criteria to determine how many images are retrieved at a given time from RAID 74 to a given client 42.
[0030] At step 330, the portion of images retrieved at step 320 are presented to the
dentist. Continuing with the above example, when using system 30 the images are presented on display 82a, typically as a plurality of thumbnails all on a single screen. The dentist 56a can then use mouse 9()a to browse through, and/or select one or more of the presented images.
[0031] Next at step 340, a determination is made of which browsing instruction was
received at step 330 by the dentist. If it is determined that the dentist selected one of the dental images that was presented at step 330, then the method advances to step 350 where the dental image is processed according to input received from the dentist. Such processing can include: magnifying, cutting portions therefrom, marking, highlighting or other editing functions as desired. Those of skill in the art will appreciate that at this step 340, the dentist 56a has the opportunity to show the dental image, such as a particular tooth, of patient 54a, and to discuss with patient 54a possible corrective steps that may be taken with that particular tooth. In method 300, once the dentist 56a finishes processing the image, the method ends, but the
method could simply begin a new again at 210 in order to retrieve another image, or simply return to step 330 in order to retrieve another image of that patient 54a. In general, it will now be understood by those of skill in the art that known or future dental image processing software can be used at step 350, thereby making the database of images stored on RAID 74 independent of such dental image processing software, allowing the dentist the opportunity to upgrade or change lo different operating systems or dental imaging software programs without the need to convert the database of images on RAID 74 into a format understandable to the different dental image processing software.
[0025] However, if it is determined at step 340 that the dentist did not select any
particular image presented at step 330, but instead wishes look at other images stored on RAID 74, then the meihod advances to step 360 where another portion of images from the patient directory (in this example directory 108a) are identified, and the method returns to slep 220, at which point that another portion of images are retrieved as previously described.
[0026] While only specific combinations of the various features and components of
the present invention have been discussed herein, it will be apparent to those of skill in the art that desired subsets of the disclosed features and components and/or alternative combinations of these features and components can be utilized, as desired. For example, it is to be understood thai the particular suggested formats for patient identifier 112 and dental image 110 arc merely exemplary, and that other formats can be used as desired.
[0027] The above-described embodiments of the invention are intended to be
examples of the present invention and alterations and modifications may be effected thereto, by those of skill in the art, without departing from the scope of the invention which is defined solely by the claims appended hereto.





We Claim
1. A method of storing a dental image of a patient's dental region, comprising:
receiving, at a dental image storage and retrieval system (32), a patient identity of the patient for whom the dental image is to be stored;
receiving, at the dental image storage and retrieval system, the dental image from an input device (94);
automatically, by a programmed computer (78), determining a source of the dental image;
generating, by the programmed computer, a prompt for an image identifier that describes at least one characteristic of the dental image;
receiving, at the programmed computer, the image identifier in response to the prompt;
generating, by the programmed computer, a generated file name for the dental image, the generated file name having the patient identity, the source, and the image identifier as text characters, the patient identity separated from each of the source and the image identifier by respective instances of a reserved character; and
providing the dental image for storage on a storage device (74) in association with the generated file name,
whereby the file name on the storage device indicates characteristics of the dental image in a manner that can be automatically parsed, thereby improving searching efficiency.
2. The method of claim 1, wherein the dental image is stored in a single file without other dental images using a native file system of the storage device.
3. The method of claim 1, wherein the source is an image capture device selected from an intra-oral camera, a scanner, and an x-ray imager, and the programmed computer uses a respectively different character string for each source.
4. The method of claim 1, wherein the image identifier identifies at least one of a particular tooth, a set of teeth and an angle at which the dental image was captured.

5. The method of claim 1, wherein the generating generates a generated file name also having at least one of an image creation date and an image modification date as text characters separated from the patient identity and the image identifier by the reserved character.
6. The method of claim 1, wherein the reserved character is a hyphen or an underscore.
7. The method of claim 1, wherein the storage device is remote from a location where the image identifier is received.
8. The method of claim 1, wherein the patient identity is a surname or a unique alphanumeric character string.
9. The method of claim 1, further comprising storing the dental image in the storage device in a directory associated with the patient.


Documents:

4024-DELNP-2005-Abstract-(08-05-2009).pdf

4024-delnp-2005-abstract.pdf

4024-DELNP-2005-Claims-(08-05-2009).pdf

4024-delnp-2005-claims.pdf

4024-DELNP-2005-Correspondence-Others-(08-05-2009).pdf

4024-delnp-2005-correspondence-others.pdf

4024-DELNP-2005-Description (Complete)-(08-05-2009).pdf

4024-delnp-2005-description (complete).pdf

4024-DELNP-2005-Drawings-(08-05-2009).pdf

4024-delnp-2005-drawings.pdf

4024-DELNP-2005-Form-1-(08-05-2009).pdf

4024-delnp-2005-form-1.pdf

4024-delnp-2005-form-18.pdf

4024-DELNP-2005-Form-2-(08-05-2009).pdf

4024-delnp-2005-form-2.pdf

4024-DELNP-2005-Form-3-(08-05-2009).pdf

4024-delnp-2005-form-3.pdf

4024-delnp-2005-form-5.pdf

4024-DELNP-2005-GPA-(08-05-2009).pdf

4024-delnp-2005-gpa.pdf

4024-delnp-2005-pct-237.pdf

4024-delnp-2005-pct-326.pdf

4024-delnp-2005-pct-373.pdf

4024-DELNP-2005-Petition-137-(08-05-2009).pdf


Patent Number 240511
Indian Patent Application Number 4024/DELNP/2005
PG Journal Number 21/2010
Publication Date 21-May-2010
Grant Date 13-May-2010
Date of Filing 08-Sep-2005
Name of Patentee ALBADENT LIMITED, a Canadian company of 464 English Rose Lane, Oakville, Ontario L6H 7A3, Canada
Applicant Address 464 ENGLISH ROSE LANE, OAKVILLE, ONTARIO L6H 7A3, CANADA.
Inventors:
# Inventor's Name Inventor's Address
1 TED KALTANJI, a Canadian national 464 ENGLISH ROSE LANE, OAKVILLE, ONTARIO L6H 7A3, CANADA.
PCT International Classification Number A61C 13/00
PCT International Application Number PCT/CA2004/000171
PCT International Filing date 2004-02-09
PCT Conventions:
# PCT Application Number Date of Convention Priority Country
1 10/371,735 2003-02-21 U.S.A.
2 2,420,259 2003-02-27 U.S.A.