(12) United States Patent
`US 6,779,185 B1
`(10) Patent N0.:
`Roukbi et al.
`(45) Date of Patent:
`Aug. 17, 2004
`
`USOO6779185B1
`
`(54) BLUETOOTH MINIPORT DRIVER MODEL
`
`(75)
`
`Inventors: Husni Roukbi, Seattle, WA (US);
`Louis J. Giliberto, Redmond, WA
`(US); D0r0n J. Holan, Seattle, WA
`(US); Kenneth D. Ray, Redmond, WA
`(US)
`
`(73) Assignee: Microsoft Corporation, Redmond, WA
`(US)
`
`( * ) Notice:
`
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 576 days.
`
`(21) Appl. No.: 09/587,749
`
`(22)
`
`Filed:
`
`Jun. 5, 2000
`
`Related US. Application Data
`
`Udell, Windows NT Up Close: An in—depth look at
`Microsoft’s
`next—generation operating
`system,
`1996,
`McGraw—Hill.*
`
`Specification of the Bluetooth System, V.1.0B, Dec. 1, 1999.
`Riku Mettala et al., Bluetooth Protocol Architecture (White
`Paper), V1.0, Nokia Mobile Phones, Sep. 29, 1999.
`Brent Miller et al., Mapping SalutationArchitecture APIs to
`Bluetooth Service Discovery Layer (White Paper), V. 1.0,
`IBM Corporation, Jul. 1, 1999.
`IEEE Standard, 802.11, Part 11: Wireless LAN Medium
`Access Control (Ii/(AC) and Physical Layer (PHY) Specifi-
`cations, 1“ Ed. 1999, and Supplements 802.11a—1999 and
`802.11b—1999.
`Bob O’Hara and Al Petrick, IEEE 802.11 Handbook A
`Designer’s Companion, Dec. 1999.
`Pat Megowan et al., IrDA Object Exchange Protocol, V1.2,
`Counterpoint Systems Foundry, Inc. Microsoft Corporation,
`Mar. 18, 1999.
`Universal Plug and Play Device Architecture, v1.0,
`Microsoft Corporation, Jun. 8, 2000.
`Golden G. Richard III, “Service Advertisement and Discov-
`ery: Enabling Universal Device Cooperation,” http://com-
`puter.org/internet/, Sep.—Oct. 2000.
`ETSI TS 101 369 v7.1.0 (Nov. 1999), Digital Cellular
`Telecommunications System (Phase 2+); Terminal Equip-
`ment
`[0 Mobile Station (TE—MS) Multiplexer Protocol,
`Global System for Mobile Communications (GSM 0710
`v7.1.0 Release 1998 .
`)
`
`* cited by examiner
`
`(63)
`
`(51)
`
`Continuation—in—part of application No. 09/556,568, filed on
`Apr. 24, 2000.
`7
`
`Int. Cl.
`
`.
`.
`............................. G06F 3/00, G06F 9/44,
`G06F 9/46’ G06F 13/00
`........................................ 719/321; 719/327
`(52) US Cl.
`(58) Field of Search .................................. 709/321, 327
`(56)
`References Cited
`U.S. PATENT DOCUMENTS
`
`6,219,707 B1 *
`
`4/2001 Gooderum et al.
`
`......... 709/225
`
`Primary Examiner—Meng-Al T. An
`Assistant Examiner—Diem Cao
`
`6,470,397 B1 * 10/2002 Shah et al.
`
`................. 709/250
`
`(74) Attorney, Agent, or Firm—Leydig, Voit & Mayer, Ltd.
`
`OTHER PUBLICATIONS
`
`(57)
`
`ABSTRACT
`
`Tomlinson, Plug and Play, Windows Developer’s Journal,
`Dec. 1995, pp. 1—6.*
`Microsoft, Plug and Play for Windows NT 5.0, 1997, pp.
`1—14.*
`
`Cant, Windows Driver Model (WDM) Device Drivers, EXE
`Magazine, Jan. 1999.*
`
`A system and method of Bluetooth compliant architecture
`and communication uses a miniport driver structure to
`efficiently implement the Bluetooth protocol layers, while
`allowing simple communication with underlying hardware.
`
`20 Claims, 8 Drawing Sheets
`
`405
`
`Port Driver
`
`
`401
`
`
`
`
`
`
`
`
`.1 Module
`413
`
`
`
`1
`
`Exhibit 1029
`
`Apple, et al. v. Uniloc
`|PR2019—00251
`
`Exhibit 1029
`Apple, et al. v. Uniloc
`IPR2019-00251
`
`1
`
`

`

`US. Patent
`
`Aug. 17, 2004
`
`Sheet 1 0f 8
`
`US 6,779,185 B1
`
`
`
`2_0
`
`
`
`
`
`
`
`RF
`INTERFACE
`
`
`
`
`E37\
`
`-
`
`_
`
`24
`
`
`
`‘
`PROCESSING
`UNIT
`
`VIDEO
`ADAPTER
`
`drive
`
`Magneticdisk OptIcaldrIve
`
`I T
`30
`
`drive
`|
`28W
`29% 31
`
`PERSONAL COMPUTER
`: SYSTEM MEMORY
`
`2
`48
`?
`21
`;
`
`:(ROM)
`I
`32
`
`BIOS
`23
`
`
`
`
`
`“
`
`
`
`HRAM)
`7_ 2i
`1 35\ OPERATING
`,
`
`
`SYSTEM
`.
`:
`1 W
`‘
`DeVIce
`
`
`36 APPLICATION
`NETWORK ;
`
`
`PROGRAM
`INTERFACE
`
`”A
`I
`46
`I
`OTHER
`1
`53
`
`HARD DISK
`PROGRAM
`CHIEF
`
`
`
`
`
`
`MODULES
`DRIVE
`DRIVE
`DISK DRIVE SIENfi'é‘FEFZCéET
`
`INTERFACE INTERFACE INTERFACE
`‘ 38\ E_#_"'
`
`
`
`hard disk
`E=EB=W
`fi .
`PR831AM
`I
`
`
`
`
`
`I
`27
`
`
`
`i
`i
`‘
`
`'
`I
`I
`OPERATING APPLICATION
`nggfiiM PROGRAM
`SYSTEM
`PROGRAMS
`MODULES
`DATA
`
`
`
`
`
`Mouse
`42
`
`35
`
`33
`
`37
`
`38
`
`FIG. 1
`
`36
`
`497 REMOTE
`COMPUTER
`
`
`
`
`
`50\
`
`
`APPLICATION
`PROGRAMS
`
`
`2
`
`

`

`US. Patent
`
`Aug. 17, 2004
`
`Sheet 2 0f 8
`
`US 6,779,185 B1
`
`
`
`OBEXDLL
`
`
`W32_32.DLL
`
`
`
`
`WSHBTHDLL
`
`MSAFD.DLL
`
`UNIMDM.TSP
`
`
`
`
`
`user
`
`kernel
`
`MODEMSYS
`
`
`
`
`
`
`
`
`Serial
`
`
`BTHMDM.SYS
`
`
`
`AFD.SYS
`
`
`
`RFCOMM TDI
`
`
`
`RFCOMMSYS
`201
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`L2CAP/LMP/SDP DDI
`
`
`
`
`BTHPORT.SYS
`203
`
`
`
`
`
`- HCI
`THXXX.SYS Minipon Driver
`205
`
`—B
`
`
`
`
`FIG. 2
`
`3
`
`

`

`US. Patent
`
`Aug. 17, 2004
`
`Sheet 3 0f 8
`
`US 6,779,185 B1
`
`301
`
`PnP creates a
`
`physical device object
`(PDO)
`
`BTHPORT.SYS 307
`
`303
`
`305
`
`A miniport driver
`(BTHXXXX.SYS) is
`loaded based on the
`device ID
`
`The miniport driver
`registers with
`
`
`
`BTHPORT.SYS
`
`instantiates the /
`protocols and data
`elements and handles
`interaction with the
`
`
`
`operating system.
`BTHPORT.SYS also
`
`makes transport
`requests of the
`miniport for the
`various Bluetooth
`
`protocols.
`
`FIG. 3
`
`4
`
`

`

`US. Patent
`
`Aug. 17, 2004
`
`Sheet 4 0f 8
`
`US 6,779,185 B1
`
`User
`
`405
`
` Port Driver
`401
`407
`
`
`
`Plug—In
`‘j:
`.
`.
`_
`g ------------
`
`er'IIport Driver
`"7-;-------1,"' Processing
`403
`........."1' Module
`
`'
`413
`
`
`<2
`
`
`
`
`
`
`
`
`
`
`
`Device
`41 1
`
`FIG. 4
`
`5
`
`

`

`US. Patent
`
`Aug. 17, 2004
`
`Sheet 5 0f 8
`
`US 6,779,185 B1
`
`501
`
`Send message to port using
`standard method
`
`Port translates to H0!
`
`
`
`Port transmits translated
`message to miniport
`
`503
`
`505
`
`507
`
`
`
`
`
`
`
`
`Miniport passes message to local
`device
`
`
`
`
`
`ls message
`
`for local or remote
`
`device?
`
`
`Miniport passes message to
`remote device
`
`513
`
`/
`
`515
`
` Remote device executes message
`
`Local device executes message
`
`and returns acknowledgment
`and returns acknowledgment
`
`
`
`
`
`
`FIG. 5
`
`6
`
`

`

`US. Patent
`
`Aug. 17, 2004
`
`Sheet 6 0f 8
`
`US 6,779,185 B1
`
`601
`
`/
`
`603
`
`Port translates to HCI
`
`Send message to port using
`standard method
`
`
`
`605
`Port transmits translated /
`message to miniport
`
`607
`Miniport uses the message to /
`directly manipulate the device and
`returns acknowledgment
`
`FIG. 6
`
`7
`
`

`

`US. Patent
`
`Aug. 17, 2004
`
`Sheet 7 0f 8
`
`US 6,779,185 B1
`
`701
`
`
`
`Port driver uses SDP
`
`
`to determine services
`
`supported by physical
`device
`
`
`
`703
`
`Port driver determines
`
`
`
`
`
`whether client is
`
`loaded for each
`
`discovered service
`
`705
`
`client portion not
`already loaded, port
`driver loads
`
`
`
`For each client or
`
`
`
`
`
`
`
`appropriate client or
`portion thereof
`
`FIG. 7
`
`8
`
`

`

`US. Patent
`
`Aug. 17, 2004
`
`Sheet 8 0f 8
`
`US 6,779,185 B1
`
`805
`
`803
`
`UpperFilterDO
`
`801
`
`FIG. 8
`
`9
`
`

`

`1
`BLUETOOTH MINIPORT DRIVER MODEL
`
`2
`embodiment of the invention allows a hardware manufac-
`
`US 6,779,185 B1
`
`CROSS-REFERENCE TO RELATED
`APPLICATIONS
`
`This application is a continuation in part of, and claims
`benefit of, US. application Ser. No. 09/556,568, “Bluetooth
`Miniport Driver Model”, filed on Apr. 24, 2000 which is
`hereby incorporated by reference in its entirety.
`
`TECHNICAL FIELD
`
`This invention relates generally to wireless interface
`technology and, more particularly, relates to the interface
`between computer software applications and wireless
`devices operating in accordance with the Bluetooth speci-
`fication.
`
`BACKGROUND OF THE INVENTION
`
`Generally, computers and other electronic devices are
`interconnected via physical cables or wires. These commu-
`nication paths allow for the exchange of data or control
`information between such devices. However, it is increas-
`ingly recognized that certain advantages arise from the
`elimination of cables and wires to interconnect devices.
`
`Such advantages include ease of configuration and
`reconfiguration, due to the elimination of the need to physi-
`cally add,
`remove, or displace a physical medium.
`Furthermore, space which would traditionally be used for
`device interconnection media may be given to other uses.
`Furthermore, device mobility is increased through the use of
`wireless connections.
`
`One method for providing wireless connections between
`devices employs a light wave in the Infrared region of the
`electromagnetic spectrum to link devices. The IrDA
`(Infrared Data Association) protocol defines one such con-
`nection mechanism. Unfortunately, such a mechanism must
`usually operate in a line of sight manner. That is to say that
`any opaque obstruction between transmitter and receiver
`will prevent proper operation. Additionally, IR transmitters
`are typically not omnidirectional when incorporated into a
`communicating device, so that for proper operation,
`the
`transmitter must be pointed generally in the direction of the
`receiver, within some nominal deviation such as 30 degrees.
`Finally,
`IR transmitters are typically fairly low power
`devices, and accordingly the range of IR links is usually
`limited to approximately one meter.
`Radio frequency links solve many of the problems inher-
`ent in Infrared links, however, many shortcomings remain.
`One protocol which defines communication between wire-
`less devices through radio frequency links is the Bluetooth
`specification. Still, within Bluetooth many protocol layers
`must be implemented. An architecture is needed whereby
`the layers of Bluetooth are implemented in an efficient
`manner while retaining a logical degree of componentiza-
`tion. Furthermore, this architecture should not have a nega-
`tive effect on the operating system as a whole, and should
`permit vendor permutations of standard hardware without
`causing faults in the system.
`
`SUMMARY OF THE INVENTION
`
`Accordingly, the present invention provides an architec-
`ture system for implementing the protocol layers of the
`Bluetooth specification in a modular manner using a
`miniport construction. This allows for efficient communica-
`tion while preserving the necessary degree of componenti-
`zation. Furthermore, the architecture system according to an
`
`turer to add vendor-specific commands without rewriting the
`port or miniport driver.
`Additional features and advantages of the invention will
`be made apparent from the following detailed description of
`illustrative embodiments which proceeds with reference to
`the accompanying figures.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`While the appended claims set forth the features of the
`present invention with particularity, the invention, together
`with its objects and advantages, may be best understood
`from the following detailed description taken in conjunction
`with the accompanying drawings of which:
`FIG. 1 is a block diagram generally illustrating an exem-
`plary computer system on which the present invention may
`reside;
`FIG. 2 is an architectural diagram of various system
`components according to an embodiment of the invention;
`FIG. 3 is a flow chart of steps taken during miniport driver
`registration in an embodiment of the invention;
`FIG. 4 is a simplified architectural diagram illustrating
`message passing between a port driver and miniport driver
`in an embodiment of the invention;
`FIG. 5 is a flowchart illustrating the steps taken during
`passage of a message from user mode in an embodiment of
`the invention;
`FIG. 6 is a flowchart illustrating the steps taken during
`passage of a message from user mode in an alternative
`embodiment of the invention;
`FIG. 7 is a flowchart
`illustrating the steps taken to
`facilitate dynamic loading of clients for a device; and
`FIG. 8 is a block diagram showing the loading of a
`protocol driver and a hardware driver according to an
`embodiment of the invention.
`
`DETAILED DESCRIPTION OF THE
`INVENTION
`
`Turning to the drawings, wherein like reference numerals
`refer to like elements, the invention is illustrated as being
`implemented in a suitable computing environment.
`Although not required, the invention will be described in the
`general context of computer-executable instructions, such as
`program modules, being executed by a personal computer.
`Generally, program modules include routines, programs,
`objects, components, data structures, etc. that perform par-
`ticular tasks or implement particular abstract data types.
`Moreover, those skilled in the art will appreciate that the
`invention may be practiced with other computer system
`configurations,
`including hand-held devices, multi-
`processor systems, microprocessor based or programmable
`consumer electronics, network PCs, minicomputers, main-
`frame computers, and the like. The invention may also be
`practiced in distributed computing environments where
`tasks are performed by remote processing devices that are
`linked through a communications network. In a distributed
`computing environment, program modules may be located
`in both local and remote memory storage devices.
`With reference to FIG. 1, an exemplary system for imple-
`menting the invention includes a general purpose computing
`device in the form of a conventional personal computer 20,
`including a processing unit 21, a system memory 22, and a
`system bus 23 that couples various system components
`including the system memory to the processing unit 21. The
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`10
`
`10
`
`

`

`US 6,779,185 B1
`
`3
`system bus 23 may be any of several types of bus structures
`including a memory bus or memory controller, a peripheral
`bus, and a local bus using any of a variety of bus architec-
`tures. The system memory includes read only memory
`(ROM) 24 and random access memory (RAM) 25. Abasic
`input/output system (BIOS) 26, containing the basic roudnes
`that help to transfer information between elements within
`the personal computer 20, such as during start-up, is stored
`in ROM 24. The personal computer 20 further includes a
`hard disk drive 27 for reading from and writing to a hard disk
`60, a magnetic disk drive 28 for reading from or writing to
`a removable magnetic disk 29, and an optical disk drive 30
`for reading from or writing to a removable optical disk 31
`such as a CD ROM or other optical media.
`The hard disk drive 27, magnetic disk drive 28, and
`optical disk drive 30 are connected to the system bus 23 by
`a hard disk drive interface 32, a magnetic disk drive inter-
`face 33, and an optical disk drive interface 34, respectively.
`The drives and their associated computer-readable media
`provide nonvolatile storage of computer
`readable
`instructions, data structures, program modules and other
`data for the personal computer 20. Although the exemplary
`environment described herein employs a hard disk 60, a
`removable magnetic disk 29, and a removable optical disk
`31, it will be appreciated by those skilled in the art that other
`types of computer readable media which can store data that
`is accessible by a computer, such as magnetic cassettes, flash
`memory cards, digital video disks, Bernoulli cartridges,
`random access memories, read only memories, and the like
`may also be used in the exemplary operating environment.
`Anumber of program modules may be stored on the hard
`disk 60, magnetic disk 29, optical disk 31, ROM 24 or RAM
`25, including an operating system 35, one or more applica-
`tions programs 36, other program modules 37, and program
`data 38. A user may enter commands and information into
`the personal computer 20 through input devices such as a
`keyboard 40 and a pointing device 42. Other input devices
`(not shown) may include a microphone, joystick, game pad,
`satellite dish, scanner, or the like. These and other input
`devices are often connected to the processing unit 21
`through a serial port interface 46 that is coupled to the
`system bus, but may be connected by other interfaces, such
`as a parallel port, game port or a universal serial bus (USB).
`A monitor 47 or other type of display device is also
`connected to the system bus 23 via an interface, such as a
`video adapter 48.
`In addition to the monitor, personal
`computers typically include other peripheral output devices,
`not shown, such as speakers and printers.
`The personal computer 20 may operate in a networked
`environment using logical connections to one or more
`remote computers or devices, such as a remote computer 49
`or RF device 64. The remote computer 49 may be another
`personal computer, a server, a router, a network PC, a peer
`device or other common network node, and typically
`includes many or all of the elements described above
`relative to the personal computer 20, although only a
`memory storage device 50 has been illustrated in FIG. 1. The
`Radio Frequency (RF) device 64 can be a cellular phone,
`digital camera, another personal computer, or other device
`which includes the capability to communicate through the
`RF spectrum. The logical connections depicted in FIG. 1
`include a local area network (LAN) 51 and a wide area
`network (WAN) 52, and an RF connection 63. Such net-
`working environments are commonplace in offices,
`enterprise-wide computer networks, intranets and the Inter-
`net.
`
`When used in a LAN networking environment, the per-
`sonal computer 20 is connected to the local network 51
`
`4
`through a network interface or adapter 53. When used in a
`WAN networking environment, the personal computer 20
`typically includes a modem 54 or other means for establish-
`ing communications over the WAN 52. The modem 54,
`which may be internal or external, is connected to the system
`bus 23 via the serial port
`interface 46. When used in
`conjunction with an RF connection 63, the personal com-
`puter 20 includes an RF interface 62.
`In a networked
`environment, program modules depicted relative to the
`personal computer 20, or portions thereof, may be stored in
`the remote memory storage device. It will be appreciated
`that the network connections shown are exemplary and other
`means of establishing a communications link between the
`computers may be used.
`the invention will be
`In the description that follows,
`described with reference to acts and symbolic representa-
`tions of operations that are performed by one or more
`computers, unless indicated otherwise. As such, it will be
`understood that such acts and operations, which are at times
`referred to as being computer-executed, include the manipu-
`lation by the processing unit of the computer of electrical
`signals representing data in a structured form. This manipu-
`lation transforms the data or maintains it at locations in the
`memory system of the computer, which reconfigures or
`otherwise alters the operation of the computer in a manner
`well understood by those skilled in the art. The data struc-
`tures where data is maintained are physical locations of the
`memory that have particular properties defined by the format
`of the data. However, while the invention is being described
`in the foregoing context, it is not meant to be limiting as
`those of skill in the art will appreciate that various of the acts
`and operations described hereinafter may also be imple-
`mented in hardware.
`
`The “Specification of the Bluetooth System” Version 1.0B
`(Dec. 1, 1999) is incorporated herein by reference in its
`entirety. The presentation “Windows Wireless Architecture”
`is attached at Appendix A,
`the presentation “Bluetooth
`Architecture Overview” is attached at Appendix B,
`the
`presentation “Bluetooth Experience in Windows” is attached
`at Appendix C, and the presentation “Bluetooth Stack in
`Windows” is attached at Appendix D. Attached as Appendix
`E is the white paper “Remote NDIS Over Bluetooth
`Specification,” Mar. 20, 2000, copyright Microsoft Corpo-
`ration. These presentations and this white paper provide
`further information regarding the Bluetooth specification.
`With reference to the architectural diagram of FIG. 2, in
`order to implement the L2CAP, HCI, LMP, SDP, and various
`Transport protocols in a port/miniport model, the following
`components are used: RFCOMM.SYS (the Bluetooth
`RFCOMM driver) 201; BTHPORT.SYS (the Bluetooth port
`driver, which is related to a class of devices) 203; BTH-
`SER.SYS (the Bluetooth RS-232 Transport and UART
`Transport miniport driver); BTHUSB.SYS (the Bluetooth
`USB transport driver); BTHXXXXSYS (the miniport
`drivers, which may be statically linked against
`the port
`driver; alternatively, as one of skill in the art will appreciate,
`a miniport driver which is not statically linked against the
`port driver is dynamically linked. The miniport drivers are
`related to a specific device or devices.) 205; PnP (the
`“Plug‘N’Play” system); and Power (Microsoft brand WIN-
`DOWS operating system power management system). As
`one of skill in the art will know, the Plug‘N’Play system is
`a combination of hardware and software support that enables
`a computer system to recognize and adapt
`to hardware
`configuration changes with little or no user intervention. The
`power management system is a system for managing the
`power consumption in a PC running the Microsoft brand
`WINDOWS operating system.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`11
`
`11
`
`

`

`US 6,779,185 B1
`
`5
`Within the invention, it is desirable to implement most of
`the protocol functionality within a single software entity.
`Exemplary of this, as seen from FIG. 2, the L2CAP, HCI,
`LMP, and SDP layers are advantageously implemented
`within a single module, BTHPORT.SYS. This allows the
`greatest efficiency in communicating between the protocol
`layers. One of skill in the art will appreciate that additional
`protocols may also be implemented within the same entity or
`that certain of the listed protocols may be implemented
`elsewhere such as in hardware when preferred in view of the
`Bluetooth Specification. See for example, page 205 of
`“Specification of the Bluetooth System” Version 1.0B (Dec.
`1,1999). Thus, again by way of example, the LMP layer may
`alternatively be implemented in the hardware itself or else-
`where on the host PC. The transport layer is implemented in
`the miniport driver 205 on a transport and/or device-specific
`basis. The BTHPORT.SYS driver 203 and the BTHXXXX.
`
`SYS miniport driver 205 communicate via the BTHPORT
`device driver interface (DDI). This interface is a well-known
`set of methods and data structures which allows communi-
`
`cation with the transport method and Bluetooth hardware to
`be abstracted from the protocols above.
`With reference to the steps of the flow chart of FIG. 3, in
`step 301 when a new Bluetooth device arrives, PnP creates
`a physical device object (PDO) with an ID for the device.
`The PnP system looks up this ID and in step 303 loads an
`appropriate miniport driver for it. The miniport driver then
`registers with the BTHPORT port driver in step 305. If
`BTHPORT is already loaded at this time, for example by
`virtue of being already associated with another device, then
`it need not be reloaded. Rather, BTHPORT may simply
`augment an appropriate counter or such to reflect the addi-
`tional device to be supported. Finally, in step 307 BTH-
`PORT.SYS instantiates the protocols and data path through
`the protocols. BTHPORT.SYS further handles interaction
`with the operating system (i.e. PnP requests, power requests,
`etc.) as much as possible with minimal reliance on the
`miniport driver (although it may ask it to perform specific
`tasks). Furthermore, the miniport driver knows how to send
`and receive packets for the transport/hardware it was written
`for.
`
`Local clients may be associated through BTHPORT as the
`need arises, depending upon the services required. For
`example, it may be necessary to support file transfer, head-
`phone set functionality, a DUN connection, and so on.
`RFCOMM 201 is an example of a client that is loaded in this
`manner. Multiple clients may be associated with a single
`device. This is a result of classifying a device as a conglom-
`eration of services rather than as a singular entity. As
`discussed above, service discovery may be by way of the
`SDP (Service Discovery Protocol) as outlined in the “Speci-
`fication of the Bluetooth System” Version 1.0B (Dec. 1,
`1999). In certain cases, such as with RFCOMM, it may be
`desirable to have a certain portion or portions of a service or
`client loaded, and to load other portions only when the need
`arises. In some instances, a required client may already exist
`due to a recent connection by a device requiring the same
`service.
`
`The steps taken to associate appropriate clients with a
`device may be encompassed within step 307 of FIG. 3, and
`are illustrated in greater detail in FIG. 7. In step 701, the port
`driver 203 uses the SDP to determine what services are
`
`supported by the physical device. In step 703, the port driver
`203 determines whether a client exists for each discovered
`
`service. In step 705, for each client or client portion that is
`not already loaded,
`the port driver loads the appropriate
`client or portion thereof. Handling client loading in this
`
`6
`manner is appropriate and advantageous in a system such as
`the present where mobility is enhanced and connections are
`accordingly somewhat less predictable.
`To enhance the viability of the port/miniport model, it is
`desirable to have a standard method for delivering informa-
`tion between user space and the miniport driver for appli-
`cation by a device. Accordingly, in an embodiment of the
`invention the Bluetooth protocol stack may communicate
`with the underlying hardware without requiring the writing
`of additional code and without requiring the rewriting of
`drivers, enabling the communication of vendor-specific
`commands which may be outside of the Bluetooth specifi-
`cation. FIG. 4 illustrates in a simplified fashion the port
`driver 401 and miniport driver 403, as they relate to this
`embodiment. With reference to the elements of FIG. 4 and
`
`the steps of FIG. 5, when information is to be transmitted
`from user mode to the miniport driver 403 for eventual
`transmission or application to a device 411,
`it
`is first
`transmitted to the port driver 401 using a standard method in
`step 501 via message 405. For example, the requester may
`send a Bluetooth request Block (BRB) to the port driver 401.
`ABRB is simply a block of information conveyed to the port
`driver via 10 Request Packets (IRPs) or any other appropri-
`ate I/O request conveyance mechanism. The BRB has the
`vendor specific function type set and contains the data to be
`sent to the miniport driver 403 or hardware 411. This method
`requires a kernel mode driver. Alternatively, the requester
`may send the vendor specific device i/o control request
`(IOCTL) to the port driver 401. The IOCTL’s input buffers
`contain the data to be sent to the miniport driver 403 or
`hardware 411. This may be implemented in either kernel or
`user mode. Finally, the requester may alternatively send the
`vendor specific command via a WMI request.
`The request’s input buffer could contain the data to be sent
`to the miniport driver 403 or hardware 411. There is pref-
`erably a specific GUID defined for the command. This may
`be implemented in user mode.
`Subsequently, the message 405 is translated by the port
`driver 401 in step 503 from the standard format to a format
`appropriate for the miniport driver 403. The translated
`message 407 is preferably compliant with the HCI (Host
`Controller Interface) standard set forth in “Specification of
`the Bluetooth System” Version 1.0B (Dec. 1, 1999). The
`translated message preferably takes the form of HCIi
`unknowniCMD, with an acknowledgment of HCIi
`unknowniEVENT. An example of such a message is an
`HCIiUNKNOWNiCMD with a hardware-specific value
`of “LEDiON” to light an LED on a device, and an
`acknowledgement of HCIiUNKNOWNiEVENT with a
`hardware-specific value of “LEDiON” to acknowledge this
`command. The protocol and interface between the miniport
`driver 403 and device 411 is preferably standardized to
`minimize the number of miniport drivers needed, such that
`hardware vendors with knowledge of the protocol and
`interface may use the methods disclosed herein to pipe
`messages from user mode to the miniport driver 403 and
`device 411. The translated message 407 is sent
`to the
`miniport driver 403 in step 505. In turn in this embodiment,
`the miniport driver 403 passes the translated message 407 to
`the local device 411 in step 507.
`In step 509, the miniport driver 403 determines whether
`the message is for the local or remote device. In the former
`case, the local device 411 receives the message and executes
`the requested function and transmits an acknowledgement
`upstream in step 511. Otherwise, in step 513 the local device
`411 is given the message by the miniport driver 403 and
`transmits the message to the remote device, not shown,
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`12
`
`12
`
`

`

`US 6,779,185 B1
`
`7
`which executes the requested function and transmits an
`acknowledgement in step 515 to the local device 411 for
`transmission upstream.
`the message 405 may be
`In a further embodiment,
`intended for use by the miniport driver rather than the device
`or devices.
`In this embodiment,
`the miniport driver is
`adapted to interpret the message 407 rather than simply
`passing it downstream. The steps according to this embodi-
`ment are illustrated in FIG. 6. Steps 601, 603, and 605
`correspond to steps 501, 503, and 505 of FIG. 5. However,
`in step 607, the miniport driver 403 uses the message to
`directly manipulate the device 411 rather than passing the
`message along and relying on the device 411 to perform the
`necessary function. Such direct manipulation may be by
`writing to a register, sending a USB command, etc. The
`miniport driver 403 also generates and returns an acknowl-
`edgment in step 507. Accordingly, in this embodiment, the
`device 411 need not to be able to understand the message
`407.
`
`The port driver may use various methods to route the
`possible response. In a first embodiment a kernel mode
`component sends a query interface to the port driver. The
`query interface request contains a direct call function that
`will be called when an unknown HCI event occurs in the
`port driver. Alternatively,
`the query interface request can
`contain an event ID which can limit the events for which the
`direct call function will be called. This may be implemented
`as a response to any of the three ways to send a request
`discussed above.
`
`the port
`Alternatively, for each unknown HCI event,
`driver can fire a WMI event. A user mode component can
`then listen for the event and respond to it appropriately. This
`may be implemented as a response to any of the three ways
`to send a request discussed above, although it is best suited
`for the WMI method of sending as request.
`In an alternative embodiment, additional processing of
`information passing to or from the device 411 may be
`executed externally to the miniport driver 403. In particular,
`a plug-in module 413 is provided in this embodiment for
`executing additional processing of the message 407 before
`passage to the device, or of a message from the device 411
`to the miniport 403 before passage to higher layers.
`Examples of processing performable by such a plug-in
`processing module are LMP layer emulation and processing
`of proprietary packet headers and trailers, etc. This archi-
`tecture allows for additional value to be added in a manner
`that is substantially transparent to the Bluetooth protocols.
`In one aspect of this embodiment, the plug-in processing
`module 413 may also be used by the miniport driver 403 to
`process information that does not get passed on to the device
`411. This may occur for instance where a particular opera-
`tion or transformation is performable by the plug-in pro-
`cessing module 413 without the aid of the device 411.
`In the Bluetooth Specification, each hardware interface is
`described with a transport protocol, however it is possible
`that different hardware vendors will choose, for various
`reasons, to utilize different transport protocols. Thus, in a
`further alternative embodiment, the miniport driver 403 is
`comprised of two components, a Bluetooth Transport Pro-
`tocol Driver (Protocol Driver) and a Bluetooth Hardware
`Interface Driver (Hardware Driver). Separating the miniport
`403 into two components in this manner allows the imple-
`mentation of any hardware interface with any transport
`protocol allowing flexibility, driver reuse, and all associated
`economies and benefits. This architecture provides further
`benefits to hardware vendors by allowing them to create
`“controller-less” Bluetooth devices. For example, in a sys-
`tem wherein the port driver does not implement the LMP
`layer, a vendor may nevertheless choose to run LMP on the
`PC by implementing the protocol in the Protocol Driver
`component of the minidriver.
`
`8
`to the above-described
`In greater detail with respect
`componentization of the minidriver 403, the Protocol Driver
`and Hardware Driver are communicably associated, with the
`Protocol Driver presenting a Bluetooth miniport driver inter-
`face to higher layers. The Protocol Driver implements the
`appropriate protocols to send and receive data to and from
`the Bluetooth hardware. The lower edge of this driver may
`be IRP-based, and communicates with the Hardware Driver.
`Alternatively, a statically or dynamically linked library may
`be implemented which shields the protocol code from the
`fact that communication with the Hardware Driver is IRP-
`based.
`
`The Hardware Driver is implemented to com