PROVISIONAL APPLICATION COVER SHEET
`
`-CERTIFICATE OF EXPRESS MAILING
`I hereby certify that this paper and the documents and/or fees referred to
`as attached therein are being deposited with the United States Postal
`Service on October 19, 1999 in an envelope as "Express Mail Post
`Office to Addressee" service under 37 CFR § 1.1 0, Express Mail No.
`EE59118464SUS, addressed to the Assistant Commissioner for Patents,
`Washington, C 20231.
`
`Attorney Docket No.: IMM1P093+
`
`First Named Inventor: Adam C. Braun
`
`Assistant Commissioner for Patents
`Box Patent Application
`Washington, DC 20231
`
`D Duplicate for
`fee processing
`
`Sir:
`
`This is a request for filing a PROVISIONAL APPLICATION under 37 CFR 1.53( c).
`
`LAST NAME
`
`FIRST NAME
`
`MIDDLE INITIAL
`
`INVENTOR(S)/APPLICANT(S)
`
`RESIDENCE (CITY AND
`EITHER STATE OR FOREIGN
`COUNTRY)
`
`Braun
`Martin
`
`Adam
`Kenneth
`
`c.
`M.
`
`Sunnyvale, CA
`Palo Alto, CA
`
`~J 1I
`~~]
`,;.
`
`TITLE OF INVENTION (280 characters max)
`
`HYBRID CONTROL OF FORCE FEEDBACK FOR
`A HOST COMPUTER AND INTERFACE DEVICE
`
`CORRESPONDENCE ADDRESS
`
`HICKMAN STEPHENS & COLEMAN, LLP
`P.O. Box 52037
`Palo Alto, CA 94303-0746
`(650) 470-7430
`
`ENCLOSED APPLICATION PARTS (check all that apply)
`
`____X_ Specification, Number of Pages ---""24'-'-----
`
`X
`
`Drawings Number of Pages
`
`4
`
`__ Small Entity Statement
`__x___ Other (specify) _C=ov_,_,e=r__,S=h=ee=t'-------
`
`_X_ A check or money order is enclosed to cover the Provisional filing fees.
`_x_ The commissioner is hereby authorized to charge any additional fees which
`may be required or credit any overpayment to Deposit Account No. 50-0384
`(Order No. IMMIP093+).
`
`Provisional Filing Fee Amount ($) 150
`
`At least some of the inventions were made under a contract with an agency of the United States Government.
`
`__ _ No
`
`----"-'X"-- Yes, the name of the U.S. Government agency and the contract number are:
`
`Department of Defense, Contract No. M67004-97-C-0026
`
`Respectfully Submittt6ed,~
`-~~~~~-P~~/~~---------
`SIGNATURE
`TYPED NAME
`Sl..J=::es:::...=R::.. . .:::;R:::;ie::.z:g=-=e~l _ _____ _
`
`DATE 10/19/99
`REGISTRATION NO. =36::..l.,6=5;.;:;,1 ___ _
`
`PROVISIONAL APPLICATION FILING ONLY
`
`APPLE INC.
`EXHIBIT 1015 - PAGE 1
`
`

`
`HYBRID CONTROL OF FORCE FEEDBACK
`FORA HOST COMPUTER AND INTERFACE DEVICE
`
`BY INVENTORS
`Adam C. Braun
`Kenneth M. Martin
`
`BACKGROUND OF THE INVENTION
`
`"
`
`Force feedback interface devices are currently available to interface a person with a
`host computer device such as a personal computer, game console, portable computer, or other
`type of computer. Several different types of consumer level force feedback devices are
`available, including joysticks, mice, steering wheels, gamepads, etc. The computer displays a
`graphical environment such as a game, graphical user interface, or other program and the user
`controls a graphical object or other aspect of the environment by inputting data using the
`interface device, typically by moving a manipulandum or "user manipulatable object" such as
`a joystick handle or steering wheel. The computer also may output force feedback
`information to the interface device which controls the device to output force feedback to the
`user using motors or other actuators on the device. The force feedback is in the form of
`vibrations, spring forces, textures, or other sensations conveyed to the user who is physically
`grasping or otherwise contacting the device. The force feedback is correlated to events and
`interactions in the graphical environment to convey a more immersive, entertaining, and
`functional environment to the user.
`
`In most commercially available force feedback interface devices, the goal has been to
`reduce the processing loading on the host computer by offloading as much of the processing
`as possible to the device itself. Thus, while force feedback devices may have significant
`differences, most of the more sophisticated devices share a common feature: a local
`rnicrocontroller on the device that is able to compute and output forces as directed by high(cid:173)
`level commands from the host computer. This results in devices that produce very high
`quality force feedback output while presenting a minimal processing load on the host system.
`
`However, in order to achieve these capabilities on the device, there is a price to pay.
`The force computations that are required to generate the output can be computationally
`expensive operations. As a result, the rnicrocontroller that is embedded into the interface
`device needs to be sufficiently powerful in order to handle this processing. The end result is
`that the device rnicrocontroller is expensive and the completed interface products have a
`significant cost to consumers. While this extra cost is bearable when the market for these
`devices is new, the cost of these consumer devices is constantly being driven to lower levels
`as the market continues to mature.
`
`In order to reduce the processing power (and thereby the cost) of the device
`rnicrocontroller and maintain the product quality level, other alternate solutions should be
`explored.
`
`1
`
`APPLE INC.
`EXHIBIT 1015 - PAGE 2
`
`

`
`SUNIMARY OF INVENTIONS
`
`A method of the present invention for reducing the processing power of the device
`microcontroller and maintaining the quality of force feedback includes sharing the force
`processing loading between the device microcontroller and the processor of the host
`computer. This sharing of processing results in a "hybrid" device that functions much like
`existing devices but allows a more limited, inexpensive processor to be used in the device and
`allows the host computer to handle enough of the computations to maintain the overall
`quality of the force feedback system. Several inventive embodiments and aspects of a hybrid
`system are described herein.
`
`DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS
`
`FIGURE 1 is a block diagram illustrating a force feedback interface system 10
`suitable for use with the present invention controlled by a host computer system. Interface
`system 10 includes a host computer system 12 and an interface device ("device") 14.
`
`Host computer system 12 is preferably a personal computer, such as a PC or
`Macintosh personal computer, or a workstation, such as a SUN or Silicon Graphics
`workstation. Alternatively, host computer system 12 can be one of a variety of home video
`game systems, such as systems available from Nintendo, Sega, or Sony, a television "set top
`box" or a "network computer", a portable computer, game device, or personal digital
`assistant, etc. Host computer system 12 preferably implements a host application program
`with which a user 22 is interacting via peripherals and interface device 14. For example, the
`host application program can be a video game, medical simulation, scientific analysis
`program, operating system, graphical user interface, or other application program that utilizes
`force feedback. Typically, the host application provides images to be displayed on a display
`output device, as described below, and/or other feedback, such as auditory signals.
`
`Host computer system 12 preferably includes a host microprocessor 16, random
`access memory (RAM) 17, read-only memory (ROM) 19, input/output (I/0) electronics 21, a
`clock 18, a display screen 20, and an audio output device 21. Display screen 20 can be used
`to display images generated by host computer system 12 or other computer systems, and can
`be a standard display screen, CRT, flat-panel display, 3-D goggles, or any other visual
`interface. Audio output device 21, such as speakers, is preferably coupled to host
`microprocessor 16 via amplifiers, filters, and other circuitry well known to those skilled in
`the art (e.g. in a sound card) and provides sound output to user 22 from the host computer 18.
`Other types of peripherals can also be coupled to host processor 16, such as storage devices
`(hard disk drive, CD ROMIDVD-ROM drive, floppy disk drive, etc.), printers, and other
`input and output devices. Data for implementing the interfaces of the present invention can
`be stored on computer readable media such as memory (RAM or ROM), a hard disk, a CD(cid:173)
`ROM or DVD-ROM, etc.
`
`An interface device 14 is coupled to host computer system 12 by a bi-directional bus
`24. The bi-directional bus sends signals in either direction between host computer system 12
`and the interface device, and can be a serial bus, parallel bus, Universal Serial Bus (USB),
`Firewire (IEEE 1394) bus, wireless communication interface, etc. An interface port of host
`computer system 12, such as an RS232 or Universal Serial Bus (USB) serial interface port,
`parallel port, game port, etc., connects bus 24 to host computer system 12.
`
`2
`
`APPLE INC.
`EXHIBIT 1015 - PAGE 3
`
`

`
`,•
`
`Interface device 14 includes a local microprocessor 26, sensors 28, actuators 30, a
`user object 34, optional sensor interface 36, an optional actuator interface 38, and other
`optional input devices 39. Local microprocessor 26 is coupled to bus 24 and is considered
`local to interface device 14 and is dedicated to force feedback and sensor I/0 of interface
`device 14. Microprocessor 26 can be provided with software instructions to wait for
`commands or requests from computer host 16, decode the commands or requests, and
`handle/control input and output signals according to the commands or requests. In addition,
`processor 26 preferably operates independently of host computer 16 by reading sensor signals
`and calculating appropriate forces from those sensor signals, time signals, and stored or
`relayed instructions selected in accordance with a host command. Suitable microprocessors
`for use as local microprocessor 26 include the I-Force Processor from Immersion Corp., the
`MC68HC711E9 by Motorola, the PIC16C74 by Microchip, and the 82930AX by Intel Corp.,
`for example, or more lower-end microprocessors in some embodiments (e.g. if the host is
`sharing significant force processing according the present invention). Microprocessor 26 can
`include one microprocessor chip, or multiple processors and/or co-processor chips, and/or
`digital signal processor (DSP) capability. In some embodiments, the microprocessor 26 can
`be more simple logic circuitry, state machines, or the like.
`
`Microprocessor 26 can receive signals from sensors 28 and provide signals to
`actuators 30 of the interface device 14 in accordance with instructions provided by host
`computer 12 over bus 24. For example, in a preferred local control embodiment, host
`computer system 12 provides high level supervisory commands to microprocessor 26 over
`bus 24, and microprocessor 26 manages low level force control loops to sensors and actuators
`in accordance with the high level commands and independently of the host computer 18. The
`force feedback system thus provides a host control loop of information and a local control
`loop of information in a distributed control system. This operation is described in greater
`detail in U.S. Patent No. 5,739,811 and patent application serial nos. 08/877,114 and
`08/050,665 (which is a continuation of U.S. Patent No. 5,734,373), all incorporated by
`reference herein. The microprocessor 26 is preferably operative to implement local closed
`loop effects dependent on position (and/or velocity, acceleration) of the user manipulatable
`object, as well as operative to receive commands for open loop effects which are calculated
`and directly output when conditions are appropriate, although the host can share in this
`processing according to the present invention, as described in detail below. Microprocessor
`26 can also receive commands from any other input devices 39 included on interface
`apparatus 14, such as buttons, and provides appropriate signals to host computer 12 to
`indicate that the input information has been received and any information included in the
`input information. Local memory 27, such as RAM and/or ROM, is preferably coupled to
`microprocessor 26 in interface device 14 to store instructions for microprocessor 26 and store
`temporary and other data. In addition, a local clock 29 can be coupled to the microprocessor
`26 to provide timing data.
`
`Sensors 28 sense the position, motion, and/or other characteristics of a user object
`34 of the interface device 14 along one or more degrees of freedom and provide signals to
`microprocessor 26 including information representative of those characteristics. Rotary or
`linear optical encoders, potentiometers, optical sensors, velocity sensors, acceleration sensors,
`strain gauge, or other types of sensors can be used. Sensors 28 provide an electrical signal to
`an optional sensor interface 36, which can be used to convert sensor signals to signals that
`can be interpreted by the microprocessor 26 and/or host computer system 12.
`
`3
`
`APPLE INC.
`EXHIBIT 1015 - PAGE 4
`
`

`
`Actuators 30 transmit forces to user object 34 of the interface device 14 in one or
`more directions along one or more degrees of freedom in response to signals received from
`microprocessor 26. In some embodiments, the actuators 30 transmit forces to the housing of
`the device 14 (instead of or addition to object 34) which are felt by the user. Actuators 30
`can include two types: active actuators and passive actuators. Active actuators include linear
`current control motors, stepper motors, pneumatic/hydraulic active actuators, a torquer
`(motor with limited angular range), voice coil actuators, and other types of actuators that
`transmit a force to move an object. Passive actuators can also be used for actuators 30, such
`as magnetic particle brakes, friction brakes, or pneumatic/hydraulic passive actuators.
`Actuator interface 38 can be optionally connected between actuators 30 and microprocessor
`26 to convert signals from microprocessor 26 into signals appropriate to drive actuators 30.
`Optionally, some or all of the functionality of the sensor interface 36 and/or actuator interface
`38 can be incorporated into the microprocessor 26, such as pulse width modulation (PWM)
`controllers for actuators, encoder processing circuitry, etc.
`
`Other input devices 39 can optionally be included in interface device 14 and send
`input signals to microprocessor 26 or to host processor 16. Such input devices can include
`buttons, dials, switches, levers, or other mechanisms. For example, in embodiments where
`user object 34 is a joystick, other input devices can include one or more buttons provided, for
`example, on the joystick handle or base. Power supply 40 can optionally be coupled to
`actuator interface 38 and/or actuators 30 to provide electrical power. A safety switch 41 is
`optionally included in interface device 14 to provide a mechanism to deactivate actuators 30
`for safety reasons.
`
`User manipulable object 34 ("user object" or "manipulandum") is a physical object,
`device or article that may be grasped or otherwise contacted or controlled by a user and
`which is coupled to interface device 14. By "grasp", it is meant that users may releasably
`engage a grip portion of the object in some fashion, such as by hand, with their fingertips, or
`even orally in the case of handicapped persons. The user 22 can manipulate and move the
`object along provided degrees of freedom to interface with the host application program the
`user is viewing on display screen 20. Object 34 can be a joystick, mouse, trackball, stylus
`(e.g. at the end of a linkage), steering wheel, sphere, medical instrument (laparoscope,
`catheter, etc.), pool cue (e.g. moving the cue through actuated rollers), hand grip, knob,
`button, gamepad, gamepad control, or other article. Many types of mechanisms and linkages
`can also be employed to provide the degrees of freedom to the user manipulatable object, as
`well as amplification transmissions such as gears, capstan drives, and belt drives, to amplify
`movement for increased sensor resolution and amplify forces for output.
`
`Hybrid Architecture
`
`The "hybrid" architecture of the present invention allows sharing of the force
`processing between the force feedback interface device and the host computer. In a hybrid
`architecture, the host computer computes at least some of the force values that are sent to the
`actuators of the device, thus reducing the processing requirements of the local microprocessor
`26 on the device. A "force value" is a value that indicates a magnitude and direction of a
`force and which can be directly translated into that force by the actuator and/or by an actuator
`interface, such as a PWM circuit. For example, a force value can be provided for each axis or
`degree of freedom for a device (including direction on that axis), or a force value can include
`In
`a magnitude portion and a direction portion for a force in a multi-dimensional space.
`
`4
`
`APPLE INC.
`EXHIBIT 1015 - PAGE 5
`
`

`
`.-
`
`.·
`
`preferred hybrid embodiments, force values sent from the host system to the device can be
`summed with any force values computed on the device. In some embodiments, the device
`can then perform post-processing on the total force value to implement such features as
`kinematics, linearization, and safety ramping, if such features are present, and the processed
`force value is sent to an actuator as an appropriate signal to be output as a force.
`
`Implementing a hybrid device presents several technical challenges that need to be
`overcome to make this invention feasible. The first significant issue to deal with is the
`architecture of the hybrid system. The basic goal of the hybrid architecture is to employ
`some of the host processing power in order to compute force values over time. One solution
`is to allow the host to precompute the force output values for each time step of a force effect
`that is to be output and transfer this data to the device before the force effect is to be output,
`where the device can output the effect when it is required. This approach allows some
`variance in the time of delivery of the force values to the device as long as the host sends
`values before they are needed to be output. However, since high quality force output requires
`updating the output on the order of hundreds of times a second, this would require the device
`to have sufficiently large memory to store the force samples for a large portion of the effect,
`such as an entire period. The cost of this additional memory, which would likely be
`comparable to the savings obtained by scaling the device microcontroller back, makes this
`option potentially less desirable.
`
`Another solution is to have the host system compute the force outputs in "real time"
`and send this data to the device at a fixed periodic rate. This method would not require the
`extra device memory, as the data is delivered to the device from the host as it is required and
`is directly output by the device. However, the host system would be required to compute the
`output at relatively high output rates.
`
`Another issue that exists, regardless of the system architecture, is the processing
`loading that would be added to the host system. Because the computation of the force output
`values is a relatively complex process, moving this computation loading to the host system
`could have a significant impact on the host system performance. This may be especially true
`in processor-intensive host applications such as a gaming environment, where the host
`processor is already significantly loaded performing the computations to handle the graphics
`and audio output.
`
`Despite these issues, there are two industry trends that will make the shared
`processing architecture become more feasible over time. First, the processing power of
`computer systems is growing rapidly. If we assume that the computations required to handle
`force feedback output remain relatively consistent, then the percentage of the processing
`power required from the host system will only decrease over time. This will continue to
`reduce the impact of any force processing on the host system.
`
`The second trend that aids the shared processing architecture is the introduction of
`newer peripheral communication busses that are designed to support the concept of an
`isochronous or streaming data channel. If the host system were to attempt to generate a fixed
`period output stream using traditional peripheral busses, it would greatly complicate the host
`software. This is especially true for a desktop operating system, such as Microsoft
`WindowsTM, as it is not a goal of these systems to allow true real time operation. Busses that
`have built in support for isochronous data transfers greatly aid the host system and
`significantly reduce the processing burden required to ensure the data transfers occur at a
`
`5
`
`APPLE INC.
`EXHIBIT 1015 - PAGE 6
`
`

`
`.·
`
`,'
`
`fixed frequency. Examples of peripheral busses that provide support for isochronous data
`transfers include Firewire (IEEE 1394) and the Universal Serial Bus (USB).
`
`Embodiments
`
`The following description details investigative work concerning the issues and
`implementations of a consumer force feedback device that uses a shared processing, or
`hybrid, architecture. A basic architecture of host computer and device processor, such as
`shown in Fig. 1, are also described in greater detail in Patent No. 5,734,373 and in Patent No.
`5,959,613 (and copending application no. 09/322,245), which are all incorporated herein by
`reference.
`
`Basic Architecture
`
`The fundamental goal of this invention is to increase the capabilities of a simple, low(cid:173)
`cost force feedback device connected to a host computer by using some of the host system's
`processing to emulate a device with increased processing power. An "emulation layer"
`("emulator") can be implemented on the host to handle this emulation of a highly capable
`device. Many different implementations of the emulator can be provided. However, in some
`systems (such as Microsoft Windows), significant advantages are gained if a very low level
`driver on the host implements the emulation layer on the host system, e.g. a driver situated
`below most other programs running on the host computer in the hierarchy of programs
`running. There are several reasons for this.
`
`;1~
`
`One reason is that, since the host operating system cannot determine whether the
`capabilities being enumerated are being emulated or not, it will treat a fully capable device
`and an emulated device identically. This means that any software that can use the fully
`capable device will be able to use the emulated device without any changes. Another reasons
`is that, by performing the emulation processing at a very low level in the system, there is
`reduced overhead to perform the transfers from the host to device. Since these transfers are
`occurring very frequently, this processing reduction will result in an increase in system
`performance.
`
`FIGURE 2 shows a hierarchy of levels implemented in host software at a general
`leveL An application program is running at the top level, and other application programs
`may also be running in a multi-tasking environment. An application program interface (API)
`communicates with the application to implement function calls and other tasks. For example,
`in the Windows operating system, the Directlnput API can be used with force feedback
`interface devices. Below the API, a force feedback driver is running, which typically is
`specific to a particular device or a class of devices. The force feedback driver can implement
`particular calls and commands to a force feedback device based on API and/or application
`commands and interface with the device at a lower level. The Device Class Driver can be
`situated below the force feedback driver, and is used to determine a class of input device
`based on information provided from the device. For example, in a Windows™ system, the
`Hid.dll and the HidClass.sys files can perform this function. Below the device class driver is
`the preferred position for the emulation layer of the present invention. Below the emulation
`layer is the communication driver which uses the communication hardware to communicate
`directly with the force feedback device over a bus. For example, in a Windows USB system,
`
`6
`
`APPLE INC.
`EXHIBIT 1015 - PAGE 7
`
`

`
`the USBD interface can be used as the communication driver to communicate with the device
`using communication hardware such as the OHCI or UHCI host controllers.
`
`Even though the emulation may function better if it is lower in the system driver
`stack, it is possible to handle the emulation at a different, e.g. higher, level and still function.
`For example, the application program itself could handle the host effects, or a driver just
`below the application program. Herein, the term "driver" is intended to mean any program
`running on the host computer below the application program level.
`
`The methods and embodiments described below, such as the emulator functionality,
`may be implemented with program instructions or code stored on or transferred through a
`computer readable medium. Such a computer readable medium may be digital memory chips
`or other memory devices; magnetic media such as hard disk, floppy disk, or tape; or other
`media such as CD-ROM, DVD, PCMCIA cards, etc. The program instructions may also be
`transmitted through a channel to the host computer (or device, where appropriate) from a
`different source.
`
`Streaming Processing
`
`In order for the host system to effectively perform emulation for the device, it will
`need to execute computational processing to generate the force output in a timely manner.
`Since many other processes are operating on the host system in addition to this force
`processing, generating this timely execution presents several issues.
`
`Determining the frequency of execution for the emulation processing is a bit of a
`tradeoff. It needs to be fast enough that the device appears to be responsive to the requests of
`the host software. However, each execution of the emulation processing will generally have
`some overhead processing time involved. This can take many forms on the host system
`including an interrupt context switch or a thread context switch.
`In determining the final
`frequency of execution, these 2 factors must be balanced against one another in a
`compromise.
`
`There are several ways to implement the timing of the execution of the emulation
`processing. In one embodiment, a timer on the system (derived from the host system clock or
`some other source) can be used to trigger the processing. In another embodiment, the force
`feedback device can generate messages at a specific time interval which are sent to the host
`system to trigger the emulation and to trigger the emulator to send a force value to the device.
`
`However, when communications interfaces that have built in support for fixed period
`streaming channels are used, it is far more efficient to control the timing of the emulation
`based on the communication channel. The way this is done is that the emulator will work to
`try to keep the streaming channel filled with data to be sent to the device. In some operating
`system implementations (e.g., Windows), it is also a requirement that streaming channels are
`continuously filled with data after they are initiated. As each streaming request is completed,
`the emulator is triggered to generate new data to be sent to the device.
`
`the OS
`the emulator and
`illustrates communication between
`FIGURE 3
`communication driver of the host system in one embodiment. If the operating system or
`device driver for the host controller can handle it, it may be possible to submit several
`
`7
`
`APPLE INC.
`EXHIBIT 1015 - PAGE 8
`
`

`
`.·
`
`transfer requests to the lower level driver that are queued to be transmitted to the device
`sequentially. This is important when operating under an operating system, such as Windows
`98, where the emulator layer may be delayed too long in submitting a streaming transfer
`request due to the emulation layer processing to refill the translation layer. The processing
`delay can be caused by other processes running on the host system which use host processing
`time, such as disk drive drivers, audio drivers, communication (e.g. network) drivers, etc. If
`such other processes are running at an equal or higher priority to the emulation layer, then the
`refill processing can be delayed. Thus, by having multiple requests pending in the
`communication driver, the emulation processor will have the time that it takes to completely
`transmit one transfer request in order to refill the other transfer request for transmission.
`
`As shown in Figure 3, the emulation process can provide two transfer requests, A and
`B. Transfer Request A is provided to and begun to be processed immediately by the
`communication driver (e.g., to output data to the device), while Request B is provided to the
`communication driver during the processing of Request A. When Request A is complete, the
`communication driver indicates this completion to the emulator with a trigger, and the
`emulator begins runtime processing (refilling) of Transfer Request A. Meanwhile, after it has
`sent the trigger to the emulator, the communication driver processes Transfer Request B.
`During the processing of Request B by the communication driver, the emulator finishes
`refilling Request A and provides the Request A to the driver. When the communication
`driver finishes Request B and triggers the emulator, the driver can then process the refilled
`Request A and the emulator can begin refilling Request B. This process repeats to allow
`delays to have minimal effect in streaming data to the device.
`
`The implementation of the trigger to cause the emulator to perform subsequent
`computations (such as refilling a request) can be accomplished in many ways. One way is to
`include an interrupt response routine that is executed when the transfer to the device is
`completed. However, in most operating systems, the host controller driver (communication
`hardware) handles interrupts, not the communication driver, so the interrupts are not exposed
`high enough to be acted upon and thus the interrupt option is often unavailable. In a different
`embodiment, a callback routine can be executed when the communication driver has
`completed the transfer. However, callback routines execute with very high priority. If the
`callback routine takes an excessive time to complete, some other processes could be starved
`of processing time. Furthermore, since the callback routine is at an elevated priority, it may
`not be able to access all the memory it needs (paged out) or use all the system services, e.g. it
`may be too high a priority to be able to access paged memory which is intended for lower(cid:173)
`level priority processes.
`
`A preferred implementation provides an execution thread (on a multi-threaded
`system) that is awakened from a suspended state by a synchronization object indicating that a
`pending transfer is completed. This implementation does not have the restrictions of a
`callback routine, as is well known to those skilled in the art.
`
`Processing Sharing
`
`When an emulation driver is being used for a device, it enables a wide spectrum of
`"loading sharing" possibilities. These possibilities can range from the emulation driver
`performing essentially no processing (for a highly capable device) to the emulation driver
`
`8
`
`APPLE INC.
`EXHIBIT 1015 - PAGE 9
`
`

`
`.·
`
`handling all the force effect computations and sending only a raw force output to the device.
`As more of the processing is handled in the emulation driver, the processing power of the
`microprocessor used in the device can be increasingly reduced. For example, if the emulation
`driver handles substantially all force computation, the microcontroller on the force feedback
`device can be as simple as a state machine or simple logic circuitry. However, for a variety
`of reasons, the most effective and preferred solution is one that divides the force effect
`computation/processing between the host system and the device based on the type of the
`effects being generated. This sharing of the processing presents a few issues that must be
`dealt with.
`
`Effect Types
`
`When controlling force feedback devices, the force commands that are sent to the
`device are commonly executed as "effects" or "force effects", which herein is used to indicate
`any type of force sensation, i.e., each effect is a description of a force sensation to be output
`on the device that is represented by the effect's parameters. Some parameters are common to
`all effects. These include values such as the effect type, the duration of the