U.S. patent application number 11/982300 was filed with the patent office on 2008-07-03 for dynamically specifying a view.
This patent application is currently assigned to ALIGN TECHNOLOGY, INC.. Invention is credited to Anil Kumar V. Chillarige, Bradley A. Davis, Samuel J. Kass, Malia Smith.
Application Number | 20080163100 11/982300 |
Document ID | / |
Family ID | 35188192 |
Filed Date | 2008-07-03 |
United States Patent
Application |
20080163100 |
Kind Code |
A1 |
Kass; Samuel J. ; et
al. |
July 3, 2008 |
Dynamically specifying a view
Abstract
Systems and methods to provide a UI includes providing a program
with a dynamic content to specify a view; and rendering the view
based on the dynamic content.
Inventors: |
Kass; Samuel J.; (Santa
Clara, CA) ; Davis; Bradley A.; (Santa Clara, CA)
; Chillarige; Anil Kumar V.; (Milpitas, CA) ;
Smith; Malia; (Mountain View, CA) |
Correspondence
Address: |
BROOKS, CAMERON & HUEBSCH , PLLC
1221 NICOLLET AVENUE, SUITE 500
MINNEAPOLIS
MN
55403
US
|
Assignee: |
ALIGN TECHNOLOGY, INC.
Santa Clara
CA
|
Family ID: |
35188192 |
Appl. No.: |
11/982300 |
Filed: |
October 31, 2007 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10836757 |
Apr 29, 2004 |
|
|
|
11982300 |
|
|
|
|
Current U.S.
Class: |
715/780 |
Current CPC
Class: |
G06G 7/48 20130101; G06F
9/451 20180201 |
Class at
Publication: |
715/780 |
International
Class: |
G06F 3/048 20060101
G06F003/048 |
Claims
1. A method of interacting with a user interface (UI), comprising:
presenting a user with a review of a proposed treatment plan by
using the UI, where the review includes a series of panes
presenting different views associated with the proposed treatment
plan; for one or more of the series of panes, providing the user
with at least one input field to receive a user input based on a
dynamic content associated with a particular view presented for
consideration by the user; prompting the user to enter a comment in
response to one or more of the received user inputs; and providing
a change request associated with the proposed treatment plan in
response to at least one of: the one or more of the received user
inputs; and the comment entered in response to the one or more of
the received user inputs.
2. The method of claim 1, where the method includes providing the
user with a review of a proposed orthodontic treatment plan.
3. The method of claim 1, where the method includes preventing the
user from continuing to a subsequent pane of the series of panes
until the user enters the comment when prompted.
4. The method of claim 1, where the method includes providing, via
the UI, a number of questions to be answered as to the user's
satisfaction with a number of aspects of the treatment plan.
5. The method of claim 4, where the method includes entering text
regarding one or more of a number of aspects when the user
indicates dissatisfaction in response to one or more of the number
of questions.
6. The method of claim 5, where the method includes updating a
number of case settings in a proposed treatment plan file in
response to the user's answers to one or more of the number of
questions.
7. The method of claim 1, where the method includes embedding the
dynamic content in a browser.
8. A method for specifying a view, comprising: providing a program
with a dynamic content to specify the view; and rendering the view
based on the dynamic content; where the content relates to a
treatment plan; where the program includes an animation routine
that provides a series of panes downloaded from a server; where at
least one of the panes has at least one tool to change the view and
at least one of the panes provides a treatment plan review; where
the treatment plan review includes putting forth a number of items
for consideration and comment by a user; and where the user is
prompted to enter a comment in response to one or more of the
number of items for consideration.
9. The method of claim 8, where the method includes allowing the
user to cycle through the series of panes via a number of control
buttons associated with the animation routine.
10. The method of claim 8, where the method includes integrating
the series of panes in a display area of the program.
11. The method of claim 8, where the method includes checking
whether the user wishes to modify one or more case settings
associated with the treatment plan in response to the comment of
the user.
12. The method of claim 8, where the method includes providing a
different view for each of the series of panes.
13. The method of claim 8, where the method includes providing a
program that includes dynamic content related to a proposed
orthodontic treatment plan.
14. The method of claim 8, where the method includes presenting a
3D model in each pane of the series of panes.
15. The method of claim 14, where the method includes allowing the
user to change the 3D model in the panes via the animation
routine.
16. A system to provide a UI, comprising: means for providing a
program with a dynamic content to specify a view; and means for
rendering the view based on the dynamic content; where the dynamic
content relates to a treatment plan; where the program serves to
present a series of panes downloaded from a server; where the
treatment plan review includes a number of questions to be answered
by a user as to the user's satisfaction with a number of aspects of
the treatment plan; and where the user is prompted to enter text
regarding one or more of the number of aspects when the user
indicates dissatisfaction in response to one or more of the number
of questions.
17. The system of claim 16, where the view and a number of case
settings are updated in response to the user's answers to the
number of questions.
18. The system of claim 16, where the treatment plan is an
orthodontic treatment plan.
19. The system of claim 16, where the system includes means for
embedding the dynamic content in a browser in the program.
20. The system of claim 16, where the program will not continue
unless all questions have a response.
Description
PRIORITY DATA
[0001] This application is a continuation of U.S. application Ser.
No. 10/836,757, filed Apr. 29, 2004, the entire content of which is
incorporated herein by reference
BACKGROUND
[0002] The invention relates generally to the field of orthodontics
and, more particularly, to computer-automated development of an
orthodontic treatment plan and appliance.
[0003] Orthodontics is the branch of dentistry that deals with the
straightening of crooked teeth. Although there are many types of
appliances that can be used by an orthodontist to straighten the
teeth, the most common appliance is braces. Braces include a
variety of appliances such as brackets, archwires, ligatures, and
O-rings, and attaching braces to a patient's teeth is a tedious and
time consuming enterprise requiring many meetings with the treating
orthodontist. Consequently, conventional orthodontic treatment
limits an orthodontist's patient capacity and makes orthodontic
treatment quite expensive.
[0004] Before fastening braces to a patient's teeth, at least one
appointment is typically scheduled with tile orthodontist, dentist,
and/or X-ray laboratory so that X-rays and photographs of the
patient's teeth and jaw structure can be taken. Also during this
preliminary meeting, or possibly at a later meeting, an alginate
mold of the patient's teeth is typically made. This mold provides a
model of the patient's teeth that the orthodontist uses in
conjunction with the X-rays and photographs to formulate a
treatment strategy. The orthodontist then typically schedules one
or more appointments during which braces will be attached to the
patient's teeth.
[0005] The formulation of the treatment strategy is typically a
trial-and-error process where the orthodontist arrives at the
treatment strategy using a mental model based on the orthodontist's
experience and skill. Because an exact model is not available, the
formulation of the treatment strategy is an art which is highly
dependent on the estimates and judgments of the treating
orthodontist or a dental appliance fabricator on behalf of the
treating orthodontist. Once the treatment strategy has been
generated, it is difficult to communicate the treatment plan and
the expected result between the orthodontist and the dental
appliance fabricator.
SUMMARY
[0006] In one aspect, systems and methods to provide a UI includes
providing a program with a dynamic content to specify a view; and
rendering the view based on the dynamic content.
[0007] Advantages of the above system may include one or more of
the following. A combination of mark-up language (such as HTML)
forms and control tags affect how information is presented. Since
the mark-up language forms and tags are can be modified on the fly
without shipping a new version of the program, a new form can be
published quickly and conveniently. The close integration of the
program and the mark-up language elements allows the review UI to
be modified at any point in time without re-releasing the
program.
[0008] Advantages of the invention include one or more of the
following. Visualization is used to communicate treatment
information in a computer-automated orthodontic treatment plan and
appliance. The invention generates a realistic model of the
patient's teeth without requiring a user to possess in-depth
knowledge of parameters associated with a patient dental data
capture system. Additionally, expertise in 3D software and
knowledge of computer architecture is no longer needed to process
and translate the captured medical data into a realistic computer
model rendering and animation.
[0009] The invention thus allows treatment visualization to be
generated in a simple and efficient manner. It also improves the
way a treating clinician performs case presentations by allowing
the clinician to express his or her treatment plans more clearly.
Another benefit is the ability to visualize and interact with
models and processes reducing the attendant danger, impracticality,
or significantly greater expense that may be encountered in the
same environment if it were an unstructured review of the treatment
plan. Thus, money and time are saved while the quality of the
treatment plan is enhanced.
BRIEF DESCRIPTION OF THE DRAWINGS
[0010] FIG. 1A shows an exemplary user interface with dynamic
specification of a view.
[0011] FIG. 1B shows another exemplary user interface that provides
dynamic specification of a view, in this case a dental view.
[0012] FIG. 2 shows an exemplary process for supporting
interactions among a program, a dynamic content to specify a view;
and a server in rendering the view based on the dynamic
content.
[0013] FIG. 3 shows an exemplary process for the user interface of
FIG. 1B.
[0014] FIGS. 4-7 show various exemplary user interface panes that
provide dynamic contents.
DESCRIPTION
[0015] Referring now to FIG. 1A, an exemplary user interface is
shown. In the UI of FIG. 1A, a program 2 provides a view window 4.
The program 2 also provides a dynamic content region 6. The output
of the dynamic content region 6 is provided to the program 2 and
influences the display of the view window 4.
[0016] The program 2 includes an animation routine that provides a
series of images showing the positions of the teeth at each
intermediate step along a treatment path. A user such as a
clinician controls the animation routine through a VCR metaphor,
which provides control buttons similar to those on a conventional
video cassette recorder. In particular, the VCR metaphor includes a
"play" button that, when selected, causes the animation routine to
step through all of the images along the treatment path. A slide
bar can be used to request movement by a predetermined distance
with each successive image displayed. The VCR metaphor also
includes a "step forward" button and a "step back" button, which
allow the clinician to step forward or backward through the series
of images, one key frame or treatment step at a time, as well as a
"fast forward" button and a "fast back" button, which allow the
clinician to jump immediately to the final image or initial image,
respectively. The clinician also can step immediately to any image
in the series by typing in the stage number.
[0017] As described in commonly owned U.S. Pat. No. 6,227,850, the
content of which is incorporated by reference, the viewer program
receives a fixed subset of key positions, including an initial data
set and a final data set, from the remote host. From this data, the
animation routine derives the transformation curves required to
display the teeth at the intermediate treatment steps, using any of
a variety of mathematical techniques. One technique is by invoking
the path-generation program described above. In this situation, the
viewer program includes the path-generation program code. The
animation routine invokes this code either when the downloaded key
positions are first received or when the user invokes the animation
routine.
[0018] The program 2 displays an initial image of the teeth and, if
requested by the clinician, a final image of the teeth as they will
appear after treatment. The clinician can rotate the images in
three dimensions to view the various tooth surfaces, and the
clinician can snap the image to any of several predefined viewing
angles. These viewing angles include the standard front, back, top,
bottom and side views, as well as orthodontic-specific viewing
angles, such as the lingual, buccal, facial, occlusal, and incisal
views. The viewer program allows the clinician to alter the
rendered image by manipulating the image graphically. The clinician
also can provide textual feedback to the remote host through a
dialog box in the interface display. Text entered into the dialog
box is stored as a text object and later uploaded to the remote
host or, alternatively, is delivered to the remote host immediately
via an existing connection.
[0019] In one embodiment shown in FIG. 1B, the program 2A is an
orthodontic treatment program known as ClinCheck.RTM., available
from the dental appliance fabrication company Align Technology,
Inc. of Santa Clara, Calif. In this embodiment, a series of dynamic
pages collectively called a Review Wizard 6A specified in HTML are
integrated in a display area of ClinCheck.RTM.. The Review Wizard
6A leads the user through a review of an orthodontic treatment,
causing the 3D model shown in a window 4A and settings to be
updated appropriately for each page of questions. The updating of
the settings and the 3D model are done through a series of commands
embedded in the HTML as an HTML comment. They are ignored by a
typical HTML renderer, but are obeyed by ClinCheck.RTM. program to
aid in the review of an orthodontic treatment.
[0020] A user such as a clinician or doctor is led through a series
of yes/no questions that ask them to make certain observations
concerning the case. While entering comments, each time the doctor
moves to the next page, or clicks the "Save Draft" button, the
server is updated with the draft comments. If the doctor leaves and
returns later, on the same or another machine, the ClinCheck.RTM.
program 2A is in the last state that the doctor was in prior to his
or her last use.
[0021] For each question, a "No" response must be explained by a
textual description. A doctor cannot continue to the next page
unless every question is answered. If the doctor finds that each
aspect of the case meets his or her satisfaction, the case is
submitted for manufacturing. If the doctor is dissatisfied with any
aspect of the case, the doctor is prompted to enter a comment about
that aspect, and at the end of the review wizard the change
requests are submitted back to the dental company for
refinement.
[0022] Turning now to FIG. 2, an exemplary process for interactions
among a program, a dynamic content to specify a view; and a server
in rendering the view based on the dynamic content is shown. In
this example, a program such as ClinCheck.RTM. requests a new
Review Wizard page 6A (11) from a server (not shown). The requested
page is provided (12). Next, the process checks whether any
unprocessed commands remain (13). If so, the command is processed
(14A) and a render or render engine is updated (14B). This is done
until all commands have been processed. From 13, once all commands
have been processed, the mark-up page is displayed and user
responses are captured (15). The responses are sent to the server
for storage, and the process waits another request for a review
wizard page (11).
[0023] The commands that can be directed to the ClinCheck program
are as follows: [0024] CameraPosition Fx Fy Fz Tx Ty Tz Ux Uy Uz:
This sets the camera's position, point that it's looking at, and
which direction is up. [0025] CameraViewpoint Name: Change the
camera position to a named viewpoint. [0026] GridVisible on/off:
Turn the grid on or off. [0027] GridPosition Px Py Pz Fx Fy Fz:
Move the grid to P(x,y,z), with the "flat" side facing F(x,y,z).
[0028] OverCorrectionVisible on/off: Turn overcorrection stages on
or off. [0029] AttachmentsVisible on/off: Turn attachments on or
off. [0030] IPRVisible on/off: Turn on or off IPR information.
[0031] SetResolution high/low: Set the display resolution to high
or low. [0032] JawUpperVisible on/off: Turn on or off upper jaw
visibility. [0033] JawLowerVisible on/off: Turn on or off lower jaw
visibility. [0034] ZoomLevel percent: Set zoom level to percent %.
[0035] Stage stage: Set the case's stage to stage. Stage can either
be an integer, or the string "first", "last", or "lastnooc", which
sets it to the first stage, the last stage, or the last stage
without overcorrection. [0036] PrintScreen: Brings up a print
dialog that, when accepted, prints the 3D image displayed. [0037]
SaveScreen: Brings up a save dialog that, when accepted, saves the
3D image as a JFIF (JPEG) file. [0038] StateChanged: Is present if
state has changed. [0039] RefreshComments: Is present if comments
have changed. [0040] CloseClinCheck: Commands ClinCheck to close
itself and release all resources. [0041] ControlAttribute controlid
attribute: Allows the review wizard to enable/disable/set/activate
a UI control's value or function.
[0042] In one embodiment, the Review Wizard content is displayed in
an enhanced browser control that supports a set of embedded
commands to perform certain operations within ClinCheck program.
These embedded commands will allow the Review Wizard to control
features such as the Viewpoint display, the camera position, the
grid, etc. All embedded commands in a pane are executed when the
pane is displayed. Commands will be performed in the order on which
they occur in the pane. One embodiment of the Review Wizard 6A has
12 panes:
[0043] 1. Introduction/Information
[0044] 2. Anterior View
[0045] 3. Anterior Overjet View
[0046] 4. Upper Occlusal View
[0047] 5. Lower Occlusal View
[0048] 6. Left Buccal View
[0049] 7. Right Buccal View
[0050] 8. Posterior (Lingual) View
[0051] 9. Staging
[0052] 10. Attachments
[0053] 11. Other (if Applicable)
[0054] 12. Finish
[0055] Each pane allows the user to perform a set of actions and/or
enter a set of comments that pertain to the pane. Each pane is
associated with a particular view or feature (attachments, staging,
etc) i.e. the view will change on each pane according to the title
of the pane. The default view for the feature pages is
Anterior.
[0056] Referring now to FIG. 3, an exemplary process for capturing
user acceptance of a proposed dental treatment is shown. First, the
Review Wizard is initiated (20). Next, a Review Wizard page is
loaded from a server (22). The responses to the Review Wizard page
is received (24), and the next page is loaded and shown to the user
to capture comments (26). The comments are saved (28), and the
program state is updated (30). Next, the process of FIG. 3
determines whether additional pages remain to be reviewed (32). If
so, the process loops back to 22 and other wise, the process checks
whether "No" responses have been entered (34). If not, the process
checks for acceptance (36). If accepted, the case acceptance is
logged (38). Otherwise, the process loops back to 20 to continue
case review. From 34, if the user has entered a "No" response, the
process checks whether the user wishes to modify the case settings
(40). If so, a case modification is requested (42) and if not, the
process loops back to 20 to continue case review.
[0057] FIGS. 4-7 show various exemplary panes. Each pane will have
a number of questions with Yes and No options. Some of the
questions may also have a `Not Available` (NA) option. If a doctor
selects a No options, he will not be allowed to navigate away from
the page unless he enters some comments. Each page will contain an
info button to Clinical Communication Guideline which will appear
on selecting any No option and will open a new window containing
the guidelines. Some of the questions will have info buttons and
help buttons associated with them which will either display message
boxes or open new windows pointing to other documents.
[0058] FIG. 5 shows an exemplary UI for a pane about the interior
view. The HTML code for the pane is shown in APPENDIX B. The pane
of FIG. 5 provides two exemplary commands to ClinCheck.RTM. program
2A in the form of an HTML comment as follows:
[0059] <!--ALIGNTECH:CameraViewpoint AnteriorOverjet:-->
[0060] <!--ALIGNTECH:RefreshComments all:-->
[0061] The HTML comment is ignored by the browser, but is processed
and sent to ClinCheck.RTM. software when it is preceded by the
ALIGNTECH: token. The commands CameraViewpoint AnteriorOverjet and
RefreshComments are processed by ClinCheck to provide an anterior
overjet view of the models of the teeth. Additionally, a series of
questions are provided to the user in the Review Wizard region
6A.
[0062] Thus, the system provides a UI includes providing a program
with a dynamic content to specify a view; and rendering the view
based on the dynamic content. Moreover, the dynamic content also
can be a web page to display information or collection information
from the user. In this case, the information is collected from the
user as to whether the overjet is satisfactory.
[0063] Comment processing is captured in an Accept/Reject Panel
having three command buttons that allow the user to select Accept,
Reject, or Review Wizard. One exemplary comment process is as
follows:
1. A Case is submitted from a dental company to the Doctor.
[0064] a. New cases will have comments from Dental company to the
Doctor.
2. The Doctor will use the Accept/Reject Panel to choose Accept,
Reject or Review Wizard
[0065] a. Accepted cases will be submitted to Dental company with
no additional comments [0066] i. The doctor will click the Accept
Case button. [0067] ii. A message will appear saying the Case has
been accepted [0068] iii. ClinCheck will close.
[0069] b. A Rejected case will be submitted to Dental company with
a set of New comments. [0070] i. The Doctor will click the
Modify/Reject button [0071] ii. The Accept/Reject Panel will be
replaced by a Modify Case Panel that will contain a comment entry
text box and three buttons; Submit Comment, Confirm Modify, and
Cancel. [0072] 1. Clicking the Submit Comment will send the
contents of the comment text box to the server. This will create a
New Comment. It will also trigger a refresh of the Comment Grid
control. [0073] 2. Clicking the Confirm Modify button will send the
contents of the text box to the server, trigger the ModifyCase web
service to confirm, trigger a refresh of the Comment Grid control,
and close the Modify Case Panel. [0074] 3. Clicking the Cancel
button deletes all New Comments, close the Modify Case Panel,
restore the Accept/Reject panel, and trigger a refresh of the
Comment Grid control.
[0075] c. A Review Wizard case will be submitted to Dental company
with a set of New Comments [0076] i. The Doctor will click the
Review Wizard button [0077] ii. The Accept/Reject Panel will be
replaced by the Review Wizard Panel (enhanced Browser control)
[0078] iii. During the Review Wizard process, the doctor must
navigate to all pages of the Review Wizard to complete all
questions. [0079] iv. Each pane of the review wizard will have a
single Comment entry text box. When the doctor navigates away from
a Pane or clicks the Save Draft Comment button on the pane, the
contents of the text box will be written to the server as a New
Comment using the Web Service. [0080] v. On the final Pane of the
Review Wizard, the doctor will be asked confirmation to Modify
(Reject) Case if he has answered a No for at least one question.
Otherwise, he will be asked for confirmation of Case Accept. The
doctor can cancel the wizard at anytime by clicking on the close
button. [0081] 1. Clicking the Modify (Reject) Case button will
trigger the CaseModify web service, close the Review Wizard Panel,
and Close ClinCheck. [0082] 2. Clicking the Accept Wizard button
will trigger the CaseAccept web service, close the Review Wizard
Panel, and Close ClinCheck. [0083] 3. Reject and Review Wizard
Cases are further processed:
[0084] a. Once the case has been formally Rejected or Modified, the
comments will become Permanent Comments.
[0085] b. If the doctor's comments are not in English, they will
automatically be submitted for translation (Translation Queue).
[0086] c. The Rejected/Modified Case will be sent back to Clinical
Operations team for processing.
[0087] d. The translated comments will be available for the
Clinical Operations team to review.
[0088] e. Another ClinCheck with additional clinical comments will
be created and sent to the doctor.
[0089] A simplified block diagram of a data processing system that
may be used to develop orthodontic treatment plans is discussed
next. The data processing system typically includes at least one
processor which communicates with a number of peripheral devices
via bus subsystem. These peripheral devices typically include a
storage subsystem (memory subsystem and file storage subsystem), a
set of user interface input and output devices, and an interface to
outside networks, including the public switched telephone network.
This interface is shown schematically as "Modems and Network
Interface" block, and is coupled to corresponding interface devices
in other data processing systems via communication network
interface. Data processing system could be a terminal or a low-end
personal computer or a high-end personal computer, workstation or
mainframe.
[0090] The user interface input devices typically include a
keyboard and may further include a pointing device and a scanner.
The pointing device may be an indirect pointing device such as a
mouse, trackball, touchpad, or graphics tablet, or a direct
pointing device such as a touch-screen incorporated into the
display, or a three dimensional pointing device, such as the
gyroscopic pointing device described in U.S. Pat. No. 5,440,326,
other types of user interface input devices, such as voice
recognition systems, can also be used.
[0091] User interface output devices typically include a printer
and a display subsystem, which includes a display controller and a
display device coupled to the controller. The display device may be
a cathode ray tube (CRT), a flat-panel device such as a liquid
crystal display (LCD), or a projection device. The display
subsystem may also provide non-visual display such as audio
output.
[0092] Storage subsystem maintains the basic required programming
and data constructs. The program modules discussed above are
typically stored in storage subsystem. Storage subsystem typically
comprises memory subsystem and file storage subsystem.
[0093] Memory subsystem typically includes a number of memories
including a main random access memory (RAM) for storage of
instructions and data during program execution and a read only
memory (ROM) in which fixed instructions are stored. In the case of
Macintosh-compatible personal computers the ROM would include
portions of the operating system; in the case of IBM-compatible
personal computers, this would include the BIOS (basic input/output
system).
[0094] File storage subsystem provides persistent (non-volatile)
storage for program and data files, and typically includes at least
one hard disk drive and at least one floppy disk drive (with
associated removable media). There may also be other devices such
as a CD-ROM drive and optical drives (all with their associated
removable media). Additionally, the system may include drives of
the type with removable media cartridges. The removable media
cartridges may, for example be hard disk cartridges, such as those
marketed by Syquest and others, and flexible disk cartridges, such
as those marketed by Iomega. One or more of the drives may be
located at a remote location, such as in a server on a local area
network or at a site on the Internet's World Wide Web.
[0095] In this context, the term "bus subsystem" is used
generically so as to include any mechanism for letting the various
components and subsystems communicate with each other as intended.
With the exception of the input devices and the display, the other
components need not be at the same physical location. Thus, for
example, portions of the file storage system could be connected via
various local-area or wide-area network media, including telephone
lines. Similarly, the input devices and display need not be at the
same location as the processor, although it is anticipated that
personal computers and workstations typically will be used.
[0096] Bus subsystem is shown schematically as a single bus, but a
typical system has a number of buses such as a local bus and one or
more expansion buses (e.g., ADB, SCSI, ISA, EISA, MCA, NuBus, or
PCI), as well as serial and parallel ports. Network connections are
usually established through a device such as a network adapter on
one of these expansion buses or a modem on a serial port. The
client computer may be a desktop system or a portable system.
[0097] Scanner is responsible for scanning casts of the patient's
teeth obtained either from the patient or from an orthodontist and
providing the scanned digital data set information to data
processing system for further processing. In a distributed
environment, scanner may be located at a remote location and
communicate scanned digital data set information to data processing
system via network interface.
[0098] Fabrication machine fabricates dental appliances based on
intermediate and final data set information received from data
processing system. In a distributed environment, fabrication
machine may be located at a remote location and receive data set
information from data processing system via network interface.
[0099] The invention has been described in terms of particular
embodiments. Other embodiments are within the scope of the
following claims.
TABLE-US-00001 APPENDIX A AVAILABLE COMMANDS CameraPosition This
sets the camera's position, Fx Fy Fz Tx Ty point that it's looking
at, Tz Ux Uy Uz: and which direction is up. CameraViewpoint Name:
Change the camera position to a named viewpoint. Possible Views 1.
RightBuccal 2. LeftBuccal 3. Anterior 4. Posterior 5.
MandibularOcclusal 6. MaxillaryOcclusal 7. RightBuccalOverjet 8.
AnteriorOverjet 9. LeftDistalMolar 10. LeftBuccalOverjet 11.
LeftLingual 12. LingualIncisor 13. RightLingual 14.
RightDistalMolar GridVisible on/off: Turn the grid on or off.
GridPosition Move the grid to P(x, y, z), with the Px Py Pz Fx Fy
Fz: "flat" side facing F(x, y, z). OverCorrectionVisible Turn
overcorrection stages on or off. on/off: AttachmentsVisible on/off:
Turn attachments on or off. IPRVisible on/off: Turn on or off IPR
information. SetResolution high/low: Set the display resolution to
high or low. JawUpperVisible on/off: Turn on or off upper jaw
visibility. JawLowerVisible on/off: Turn on or off lower jaw
visibility. ZoomLevel percent: Set zoom level to percent %. Stage
stage: Set the case's stage to stage. Stage can either be an
integer, or the string "first", "last", or "lastnooc", which sets
it to the first stage, the last stage, or the last stage without
overcorrection. StateChanged: Is present if state has changed.
State is a numerical value that is defined as. 1. "Waiting for
Doctor's Approval", 2. "Accepted", 3. "Modification in Progress",
4. "Modification Requested", and 5. "Review Wizard In Progress".
PrintScreen: Brings up a print dialog that, when accepted, prints
the 3D image displayed. SaveScreen: Brings up a save dialog that,
when ac- cepted, saves the 3D image as a JFIF (JPEG) file.
TABLE-US-00002 Additional Commands RefreshComments (all, new,
Trigger to tell the Comment Grid Control old) to retrieve comments
from the server ControlAttribute(controlid, Pass a control
attribute to a control in attribute) CC 2.0. (Used to disable or
turn off buttons.) CloseClinCheck( ) Trigger to close
ClinCheck.
* * * * *