(12) United States Patent
`(10) Patent N0.:
`US 6,799,318 B1
`
`Davison et al.
`(45) Date of Patent:
`Sep. 28, 2004
`
`U5006799318B1
`
`(54) METHOD HAVING MULTIPLE INTERFACES
`WITH DISTINGUISHED FUNCTIONS AND
`COMMANDS FOR PROVIDING SERVICES
`TO A DEVICE THROUGH A TRANSPORT
`_
`_
`Inventors: Erlc DaVISon, Seattle, WA (US); .
`Stanley W- Adermann, SammamISh,
`WA (US)
`.
`.
`,
`,
`(73) ASSIgnee. Mjlscrosoft Corporatlon, Redmond, WA
`(
`)
`.
`.
`.
`.
`.
`S b
`N t
`t t
`d
`1
`th t
`f th
`0 Ice
`p2,if 1506?an011:; Singing;filla?“ 31;
`U S C 154(b) by 669 days
`.
`i
`i
`.
`
`(75)
`
`*
`
`(
`
`)
`
`:
`
`(21) APPL No“ 09/587,753
`(22)
`Filed:
`Jun. 5, 2000
`
`Related US. Application Data
`
`(63)
`
`Continuation—in—part of application No. 09/552,320, filed on
`Apr. 24, 2000, now abandoned.
`
`Int. Cl.7 .................................................. G06F 3/00
`(51)
`(52) US. Cl.
`....................................................... 719/328
`(58) Field of Search ................................. 709/228, 230,
`709/250, 302, 719/328; 717/108
`_
`References CIted
`U.S. PATENT DOCUMENTS
`
`(56)
`
`8/1992 Harvey et al.
`.............. 709/228
`5,136,716 A *
`1/1995 Wold etal. .......... 717/162
`5,386,568 A *
`
`..... 370/389
`6/1995 Britton et al.
`..
`5,425,028 A *
`................. 709/228
`8/1996 Pettus
`5,548,723 A *
`........... 707/200
`5,572,724 A * 11/1996 Watanabe et al.
`5,612,898 A
`3/1997 Huckins
`............ 709/203
`5,706,437 A *
`1/1998 Kirchner et al.
`5,710,908 A *
`1/1998 Man ........................... 709/230
`5,758,186 A
`5/1998 Hamilton et al.
`5,987,517 A * 11/1999 Firth et al. ........... 709/230
`....... 707/10
`6,023,698 A *
`2/2000 Lavey et al.
`
`..... 719/328
`6,032,198 A *
`2/2000 Fujii et al.
`
`6/2001 Minard ...........
`.. 707/104.1
`6,247,020 B1 *
`.
`..... 709/245
`6,351,776 B1 *
`2/2002 O’Brien et al.
`
`6,408,342 B1 *
`6/2002 Moore et al.
`..... 709/330
`.............. 709/227
`6,434,617 B1 *
`8/2002 Clough et al.
`
`6,591,295 B1 *
`
`7/2003 Diamond et a1.
`
`........... 709/217
`
`OTHER PUBLICATIONS
`Artisoft, “Using NodeRunner/SI with NDIS,” 1993, 8 pages.
`Moore, “Windows, Wireless Architecture”, 71 pages.
`Ray et al., “Bluetooth Stack in Windows”, 30 pages.
`Specification of the Blaetooth System, v1.0B, Dec. 1, 1999.
`Riku Mettala et al., Blaetooth Protocol Architecture (White
`Paper), V1.0, Nokia Mobile Phones, Sep. 29, 1999.
`Brent Miller et al., Mapping SalatationArchitectareAPIs to
`Blaetooth Service Discovery Layer (White Paper), v1.0,
`IBM Corporation Jul. 1 1999.
`’
`’
`IEEE Standard, 802.11, Part 11: Wireless LAN Medium
`Access Control (ll/(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.
`.
`.
`* Clted by examlner
`
`Primary Examiner—K risa le
`(74) Attorney, Agent, or Firm—Leydig, Voit & Mayer, Ltd.
`
`ABSTRACT
`(57)
`Aprotocol independent implementation of the OBEX Speci-
`fication that allows OBEX applications to communicate
`without having to know transport Specific details is pre-
`sented. OBEX services reside on top of an OBEX layer and
`the layer communicates with the transports with a interface
`that
`is independent of the transport protocol and other
`interfaces are provided when connections are created.
`OBEX applications use the protocol independent interface to
`communicate with OBEX services and other applications
`and to transfer data via the transports. Aprimary interface is
`provided that has commands to enumerate transports and to
`enumerate devices. Other interfaces include a transport
`interface for communicating with a transport, a service
`interface for determining when an incoming connection
`arrives, and a device interface for communicating with the
`at least one device.
`
`15 Claims, 7 Drawing Sheets
`
`PMs/y imam Funcliuni
`
`ia/uponswam inrmc:
`Fummm
`Class .86cm
`Lilla/Iiorlnmmlnu mnnmrnns
`Errrrrm grammar ibwla
`5439ka
`Corinnain aman
`
`Funnfinns
`
`
`
`
`
`vaida Primary Interface
`
`Provide Transporl Imeflaoe
`
`Prwde Service lntaflaoe
`
`Prnvide Device Inlertace
`
`
`
`
`
`
`
`
`
`
`
`
`runner min Inii»an.nun. .
`
`Sim-n mime Funny»
`andan:rm1strum
`Wribedatatoulmm
`wear-d nu
`insinmsteamtowrite maintoa
`spedfimMe
`Banal/1M“ Funcmns
`
`minedloanew
`Disco/med5Mine
`
`Send dalitnadevice
`
`
`
`
`
`Service inmnanr Fir/mm:
`Lisle"inran Inwming
`snmnoun 1r. immin-wl:
`Service
`s-izyawn: mumto
`new: .Swine
`
`Curr/nacho»
`
`can em: 5mm. canmiimr lnieflane
`Liar-nin In incoming Mir-and
`
`
`
`
`
`Twin“InmaaeFunnier:
`Imbaliflarmsm
`CVSEIEascam
`EmmmaMutants-Iota
`sperm an:
`Enwwlttmm" rewindto
`manalists/1m mm
`
`Truman onnnsniinn
`InleflmFuncllnnx
`
`Receive nairo unarmed!
`’
`a
`Enumerabepmpemes hours
`.
`.
`
`Exhibit 1028
`
`Apple, et al. v. Uniloc
`|PR2019—00251
`
`m T
`
`Exhibit 1028
`Apple, et al. v. Uniloc
`IPR2019-00251
`
`1
`
`

`

`US. Patent
`
`Sep.28,2004
`
`Sheet170f7
`
`US 6,799,318 B1
`
`um
`
`mu
`
`mm
`
`um
`
`mm
`
`mm
`
`M;
`
`MN
`
`DB.)
`
`.umOomQ/Z
`
`EODCrmm
`
`UNOOIES
`
`O4Imx
`
`.umOOZZS
`
`>_u_u_._o>._._Oz
`
`m<m,_,m_s
`
`Ohm—”>420
`
`
`
`
`
`Pm<m._.m_s§m§Om<
`
`
`
`vmmmOZx/rOOZUCAWI
`
`$25
`
`A2073
`
`mam
`
`C22.
`
`vaOmeZO
`
`>U>U4mm
`
`<=UmO
`
`_z._.mm_n>0m
`
`zm4<<OWX
`
`NA
`
`A
`m
`
`mw
`
`AN
`
`Nw
`
`mmmm
`
`ONE—m
`
`022m
`
`I>NU05x
`25005X
`
`“X
`
`K5
`
`05X032m
`03402.
`
`mmm_>rvow...
`.zammmpom
`
` Ofimgdzm>mu_u_._0>jOZ
`
`
`
`
`
`_z4mm_u>0m_zfim_~_u>0m_ZAmmm>Om
`
`um
`
`mm
`
`mu
`
`wm
`
`m<mflm§
`
`U>._1>
`
`.umoomksm
`UEOOZZS
`EOUCrmm
`.umOOIZS
`
`
`
`mm
`
`UWOOFESm
`
`>EuEO>jOZ
`
`OOEUCfimm
`
`mmEOAm
`
`2
`
`
`
`
`
`
`
`
`
`
`

`

`US. Patent
`
`Sep. 28, 2004
`
`Sheet 2 0f 7
`
`US 6,799,318 B1
`
`Application reads transport
`specific data
`
`100
`
`102
`
`108
`
`106
`
`return
`error
`
`Application passes data to
`OBEX layer API
`
`s transpo
`installed?
`
`load transport and pass
`
`application data
`
`
`
`110
`
`return transport independent
`interface to appliction
`
`FIG. 2
`
`3
`
`

`

`US. Patent
`
`Sep.28,2004
`
`Sheet3 0f7
`
`US 6,799,318 B1
`
`wmoEmw
`
`523xmmo
`
`wtoqwcmh...
`
`ON?
`
`NNF
`
`omr
`
`
`
`$2meXmmO
`
`xme
`
`ztoawcmfi
`
`Nmr
`
`xmmO XmmO
`mNrtoamcmfitoawcmfitoamcmfi
`
`
`xmexme
`
`m.07...
`
`4
`
`
`
`

`

`US. Patent
`
`Sep.28,2004
`
`Sheet4 0f7
`
`US 6,799,318 B1
`
`nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn
`
`v.©_n_
`
`Xmmo
`
`ztoawcmc.
`
`
`
`
`
`Nm—Ixfl£8635-
`
`xoomE>>
`
`m8
`
`.5
`
`
`
`
`
`$53.XmmOimmo
`
`5
`
`
`
`
`

`

`US. Patent
`
`Sep. 28, 2004
`
`Sheet 5 0f 7
`
`US 6,799,318 B1
`
`170
`
`
`
`FIG. 5
`
`172
`
`174
`
`
`
`Create primary
`interface
`
`
`
`
`Read and Pass
`transport data blob
`
`
`
`
`Listen for
`
`
`incoming
`connections
`
`
`
`
`
`
` Incoming
`connection
`
`
`received?
`
`
`176
`
` Wait for incoming
`command
`
`
`
`received?
`
`
`178
`
`
`
`180
`
`Incoming
`command
`
`Perform read or write
`
`operation
`
`182
`
` Has
`
`connecfion
`
`
`
`
` 184
`
`dropped?
`
`6
`
`

`

`US. Patent
`
`Sep. 28, 2004
`
`Sheet 6 0f 7
`
`US 6,799,318 B1
`
`FIG. Ga
`
`
`
`
`
`
`Provide Primary Interface
`
`
`
`
`Provide Transport Interface
`
`Provide Service Interface
`
`Provide Device Interface
`
`7
`
`

`

`US. Patent
`
`Sep. 28, 2004
`
`Sheet 7 0f 7
`
`US 6,799,318 B1
`
`FIG. 6b
`
`Primary Interface Functions
`
`
`
`
`
`Enumerate transports
`
`Enumerate devices
`
`Register a service
`
`
`
`
`
`Transport Socket Interface
`Functions
`
`
`
`
`
`
`
`Transport Interface Functions
`
`Initialize a transport
`
`Create a socket
`
`Enumerate a list of devices of a
`
`specified type
`
`Enumerate properties required to
`create a listening socket
`
`Close a transport
`
`
`
`
`
`
`
`
`
`Close a Socket
`
`Lrsten for incoming connections
`
`Enumerate properties about a
`socket
`
`Connect to a device
`
`
`
`Stream Interface Functions
`
`Read data from a stream
`
`Write data to a stream
`
`Instruct steam to use data from a
`
`specified file
`Instruct steam to write data to a
`
`specified file
`
`Device Interface Functions
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Service Interface Functions
`
`
`
`
`
`
`
`Listen for an Incoming
`Connection
`
`Shut down an Instance of a
`Service
`
`Set a password required to
`access a Service
`
`Transport Connection
`Interface Functions
`
`Close a connection
`
`Send data on a connection
`
`Receive data on a connection
`
`Enumerate properties about a
`connection
`
`
`
`
`
`
`
`Service Connections Interface
`Functions
`
`
`
`
`
`
`
`
`
`
`Accept a connection
`
`Close a connection
`
`Listen for an incoming command
`
`8
`
`

`

`US 6,799,318 B1
`
`1
`METHOD HAVING MULTIPLE INTERFACES
`WITH DISTINGUISHED FUNCTIONS AND
`COMMANDS FOR PROVIDING SERVICES
`TO A DEVICE THROUGH A TRANSPORT
`
`RELATED APPLICATIONS
`
`This application is a continuation in part of US. patent
`application No. 09/552,320 filed Apr. 24, 2000, now aban-
`doned.
`
`TECHNICAL FIELD
`
`This invention relates generally to communication
`between electronic devices and, more particularly, relates to
`methods to transfer data and objects between electronic
`devices.
`
`BACKGROUND OF THE INVENTION
`
`OBEX (Object Exchange) is a protocol that is similar to
`the Hypertext Transfer Protocol (HTTP). It provides the
`same basic functionality in a lighter fashion using a client-
`server model. OBEX consists of a protocol and an applica-
`tion framework. The application framework is built on top of
`the protocol and is used to ensure interoperability between
`devices and applications using OBEX. The protocol consists
`of a format for communication between devices and appli-
`cations and a set of functions. The functions include initi-
`
`ating a connection, disconnecting a connection, sending an
`object from a client
`to a server (push operation), and
`requesting that a server return an object to a client (pull
`operation).
`IrDA, and
`there are 3 transports—IP,
`Presently,
`Bluetooth—that OBEX can operate over. Applications and
`devices need to know transport specific information before
`using a particular transport. OBEX applications typically
`have to be re-written each time a transport using a different
`protocol becomes available. More transports are becoming
`available that use OBEX. Re-writing OBEX applications for
`each new transport is time consuming and destabilizing and
`adds to both the development and testing effort. Amethod is
`needed whereby applications can be run on new transports
`that become available without having to be re-written.
`
`SUMMARY OF THE INVENTION
`
`In view of the aforementioned problems, OBEX is imple-
`mented in such a way as to expose a protocol independent
`interface. This allows OBEX applications to communicate
`without having to know transport specific information. The
`main advantage to this approach is that OBEX applications
`will not need to be re-written when a new protocol for
`OBEX becomes available. Only a small piece of transport
`specific data needs to be updated in order for the application
`to work over the new transport.
`The OBEX services reside on top of an OBEX layer. The
`OBEX layer communicates with the transports with a inter-
`face that is independent of the transport protocol and other
`interfaces are provided when connections are created. The
`OBEX layer allocates packets and post them down to the
`transports for incoming data from an application or module.
`When an incoming data packet is received from a transport,
`the layer determines which of the OBEX services should
`receive notification, abstracts the OBEX data and provides
`it
`to the appropriate OBEX services. The OBEX layer
`generates outbound packets for data passed into the OBEX
`layer by an OBEX service. The layer generates the correct
`headers for the protocol being used and sends the outbound
`
`2
`packets down to the appropriate transport for sending to an
`application or module.
`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
`resides;
`illustrating the steps taken to
`FIG. 2 is a flowchart
`determine which transport to use in accordance with the
`teachings of the invention;
`FIG. 3 is a block diagram illustrating an embodiment of
`an operating system for directing data through a plurality of
`transport providers;
`FIG. 4 is a block diagram illustrating OBEX services and
`OBEX transports in the operating system of FIG. 3;
`FIG. 5 is a block diagram illustrating the steps of sending
`an object between devices;
`FIG. 6a is a block diagram illustrating the steps of
`providing a service to a device through a transport provider;
`and
`
`FIG. 6b is a block diagram illustrating the functions of the
`interfaces of FIG. 6a.
`
`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
`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
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`9
`
`9
`
`

`

`US 6,799,318 B1
`
`3
`
`input/output system (BIOS) 26, containing the basic routines
`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, not shown, 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, a remov-
`able 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, magnetic disk 29, optical disk 31, ROM 24 or RAM 25,
`including an operating system 35, one or more applications
`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, such as a remote computer 49. 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 com-
`puter 20, although only a memory storage device 50 has
`been illustrated in FIG. 1. The logical connections depicted
`in FIG. 1 include a local area network (LAN) 51 and a wide
`area network (WAN) 52. Such networking environments are
`commonplace in offices, enterprise-wide computer
`networks, intranets and the Internet.
`When used in a LAN networking environment, the per-
`sonal computer 20 is connected to the local network 51
`through a network interface or adapter 53. When used in a
`WAN networking environment,
`the person 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. 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
`
`4
`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
`computer, 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 operation described hereinafter may also be imple-
`mented in hardware.
`The invention will be described in the context of the
`
`Windows operating system. It should be understood that the
`instant invention is applicable to other operating systems
`such as the Macintosh operating system from Apple
`Computer, Inc. and the 08/2 operating system from IBM.
`Turning now to FIGS. 2 and 3, in order to expose multiple
`transports through OBEX without applications needing to be
`re-written, a dynamic link library, OBEX.dll, is used to
`implement
`the OBEX specification, and the Windows
`registry, or some other data store, stores transport specific
`data that can be read at start-up.
`FIG. 2 illustrates the steps taken to allow an application
`to communicate on a network. AnApplication Programming
`Interface (API) allows OBEX applications to pass transport
`specific data to the OBEX layer to initialize the networking
`subsystem (steps 100, 102). The data has a pre-defined
`format such that
`the OBEX layer can determine which
`transport the data is for and check to see if the transport is
`installed (step 104). If the transport which the data is for is
`not installed, an error message is returned (step 106). If the
`transport
`is installed,
`the OBEX layer then creates the
`appropriate transport module and passes the transport spe-
`cific data down to that module (step 108). The OBEX layer
`then returns a transport independent interface to the appli-
`cation to use whenever it communicates on the network
`
`(step 110).
`In one embodiment, this data can be generated at setup
`time by reading a device information file (e.g., an INF).
`OBEX services 120 reside on top of the OBEX layer 122.
`The OBEX layer 122 allocates packets and post them down
`to the transports 124, 126, 128, 130 for incoming data. When
`an incoming data packet
`is received, OBEX layer 122
`determines which OBEX service should receive notification
`
`and abstracts OBEX data and provides the OBEX data to the
`OBEX services 120. Outgoing data passed into the OBEX
`layer 122 from OBEX services 120 may not be in the correct
`protocol format for the transport being used. OBEX layer
`122 generates outbound packets with correct wheaders for
`the protocol being used and sends the outbound packets
`down to the appropriate transport.
`Each transport defines the INF file layout and provides a
`small application to convert the information into something
`the application can pass through the OBEX layer 122. In this
`embodiment, application transport specific data is stored in
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`10
`
`10
`
`

`

`US 6,799,318 B1
`
`5
`the registry and can be read in at startup time. When a new
`transport is brought on-line it is registered so that the OBEX
`layer knows about it as well. For an application to support
`a new transport, all that needs to be done is to have the
`application written in such a way that it reads data from the
`registry and passes it
`through the OBEX APIs.
`In this
`manner the code has no knowledge of what transport it is
`using.
`Enumeration of OBEX devices is done at the OBEX layer
`122 and information about other OBEX clients is passed to
`the application in a generic fashion. The application can then
`display the choices to the user to select. The information
`about the transport 124, 126, 128, 130 the OBEX device is
`using is obtained in a standard fashion as known by those
`skilled in the art such that
`it can be enumerated and
`
`presented to the user without knowing the details of the
`information. For an OBEX client to connect to a remote
`
`device it would just need to pass the information generated
`by the OBEX layer to connect.
`OBEX server applications initialize their transport infor-
`mation by reading data from the registry. At install time the
`registry is configured with all the necessary information to
`initialize the transports 124, 126, 128, 130. The transports
`124, 126, 128, 130 communicate with other applications
`through the Windows Sockets provider (Winsock) 132. The
`transports 124, 126, 128, 130 know how to discover devices
`and send and receive data across a network medium and do
`
`not need to have any knowledge of the OBEX protocol.
`Winsock 132 consists of a kernel driver and a set of
`
`user-mode dynamic link libraries (DLLs) and it allows
`programs to communicate with other programs and
`machines via protocols such as TCP/IP, Bluetooth, etc.
`Turning now to FIG. 4, OBEX services 120 has several
`default services. Two of these services are the default inbox
`140, 142, 144, 146 and folder browser 148. The default
`inbox allows a sending device (i.e., a client) to send a file or
`an object to a receiving device (i.e., a server) without having
`to know the folder hierarchy of the receiving device. The
`client sends the file/object to the server and the server is
`responsible for placing the file/object in the correct location.
`The functionality provided the default inbox 140, 142, 144,
`146 may be the same, but each instance of a default inbox
`will be listening on a different transport/port combination.
`Default inbox 140 listens on IrDA transport 150 on the
`OBEX port. Default inbox 142 listens on IrDA transport 150
`on the OBElerXfer port. Default inbox 144 listens on IP
`transport 152 on port 650. Default inbox 146 listens on
`Bluetooth transport 150 on the Bluetooth OBEX port. The
`folder browser 148 allows a client to browse folders on a
`
`device and put objects into and get objects out of the folders.
`The folder browser 148 listens on the same ports as the
`default inboxes 140, 142, 144, 146.
`The application programming interfaces used to imple-
`ment the instant invention shall now be described. These
`interfaces
`are
`IOBEX,
`IOBEXService,
`IOBEXServiceConnection,
`IOBEXDevice,
`IOBEXTransport,
`IOBEXTransportSocket,
`IOBEXTransportConnection, and IOBEXSink.
`The IOBEX interface is the main interface to the OBEX
`services. The IOBEX interface contains a set of functions
`
`preferably including EnumTransports, Register Service,
`RegisterServiceBlob, and EnumDevices. EnumTransports
`returns an ITransportEnum pointer that is used to enumerate
`the known transports. The ITransportEnum interface will
`enumerate a list of transport property bag interfaces. Each
`transport property bag interface has a globally unique iden-
`
`6
`
`tifier (i.e., GUID) associated with it and a list of properties
`for that transport. An OBEX service that wishes to register
`can use this list of services to determine what needs be
`configured for that particular transport. The transport prop-
`erty bag interface can then be passed to the register service
`call once all of the properties are set. RegisterServiceBlob
`takes a blob (i.e., an information package) that describes the
`service information. The format of this blob is transport
`specific and is typically created at setup time of the service.
`At run time, the service reads in the blob and passes in the
`data to RegisterService. The only part of the information
`package the OBEX layer will interpret is the transport with
`which the information package is destined. The RegisterSer-
`vice function takes transport property bag that contains all of
`the properties that have been set by the user and uses these
`values to configure the service. An IObeXService interface is
`returned if either of the two functions are successful. The
`EnumDevices function returns an IDeviceEnum interface
`
`that can be used to walk the list of devices within range.
`Notifications will be returned using the connection point
`model defined by the Windows COM.
`The IOBEXService interface is used to listen for incom-
`
`ing connections and close the instance of an OBEX service.
`This interface contains a set of functions preferably includ-
`ing GetConnection, Close, and SetPassword. The GetCon-
`nection function listens for incoming connections for a
`service. The function can be used to poll for incoming
`connections or to wait until one arrives. When a connection
`comes in, the function returns an IObeXServiceConnection
`interface. The Close function shuts down the particular
`instance of an OBEX service. The SetPassword function sets
`
`the password required to access the service upon connecting.
`The IOBEXServiceConnection interface is used after a
`connection is made. This interface contains a set of functions
`
`preferably including Accept, Close, GetCommand, and
`EnumProperties. The Accept function accepts an incoming
`connection and it should be called before GetCommand. The
`Close function closes the current connection and sends a
`
`disconnect request to the client. If the connection has not yet
`been accepted, an error response will be sent to the client.
`The GetCommand function listens for incoming command
`requests from the client. This function can be used for either
`polling for an incoming command or to block and wait for
`a command. The function will return a command structure.
`
`The EnumProperties function is used by the interface user to
`get the properties of the connection. This method will return
`a set of properties that specifies the client information. The
`caller should use this information along with the header
`information to determine if the connection should be
`
`accepted.
`The command structure has several fields and properties
`that describe the command. The properties are the opcode
`and any flags. The structure has a pointer to an IHeaderCol-
`lection interface which can be used to enumerate the head-
`
`ers. All headers can be displayed here except any body
`headers, which can be accessed through the stream interface.
`The stream interface is also returned in the structure. The
`
`SendResponse function is used for those commands that do
`not have any data associated with them and only require a
`response from the server. This function can be called to
`generate a response code to the client.
`The IOBEXDevice interface is obtained by the EnumDe-
`vices call of IObeX. The IObeXDevice interface exposes a
`property bag that describes the device. The property bag
`includes standard properties such as Name, Address and
`Transport which define the device. The address is transport
`specific, but is presented to the user as a string. This interface
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`11
`
`11
`
`

`

`US 6,799,318 B1
`
`7
`contains a set of functions preferably including Connect,
`Put, Get, Abort, SetPath, and Disconnect. The Connect
`function connects to the device specified and it operates in
`blocking mode. A password for the device can be specified
`at this point. If a password is not specified and the server
`requires a password, a callback will be made to the interface
`registered on the main OBEX object. If no interface has been
`registered for callbacks then the function will fail
`if a
`password is required. The Put function issues a put com-
`mand to the server for the object that is passed in. The user
`builds a collection of headers that describes the object using
`the IHeaderCollection interface. The Put function returns an
`
`IStream interface, which the user can use to write any data
`that needs to be sent. The Get function does a get request of
`an object on an OBEX server. An IHeaderCollection inter-
`face will be passed in to describe the object. The Get
`function also returns an IStream interface with which the
`
`10
`
`15
`
`user can read the incoming data. The Abort function sends
`an abort request to the server. The SetPath function issues a
`SetPath command to the server. The Disconnect function
`
`20
`
`disconnects the specified connection.
`The IOBEXTransport interface is used by the OBEX layer
`122 to communicate with the transports 124, 126, 128, 130.
`All notifications that arise from objects created from this
`interface will use the callback interface specified on the
`object. This interface contains a set of functions preferably
`including Init, CreateSocket, EnumDevices,
`EnumProperties, and Shutdown. The Init function initializes
`the transport. The CreateSocket function creates a socket
`that can then be used for listening on or connecting to other
`devices. When a socket is created, this function returns an
`IOBEXTransportSocket interface. There are two versions of
`CreateSocket function. The first version takes a information
`package that
`is passed in by the user. The data in the
`information package is defined by the transport and can be
`unknown to the OBEX layer 122. The OBEX layer 122 just
`passes the information to the correct transport provider. The
`second version of this function takes a property collection
`that contains the properties necessary to create a listening
`socket. The EnumDevices function returns a list of known
`devices of the specified type. The information returned is an
`enumeration of property collection. Each collection of prop-
`erties defines a device. When a connection to a device is
`made, the collection of properties that defines the device is
`passed in. The EnumProperties function retuns an enumera-
`tion of all
`the necessary properties required to create a
`listening socket on the transport. The property collection is
`to the user through the IObeX::EnumTransport function to be
`filled in. The collection can then be passed through the
`IObexzzRegisterService function and down through the Cre-
`ateSocket method of the IOBEXTransport interface to create
`a listening socket. The Shutdown function closes the trans-
`port.
`The IOBEXTransportSocket interface is used to l