246
`
`Chapter 14- & THE SERIAL AND OBJECT EXCHANGE PROFILES
`
`this is son1ewhat n1isleadin g. The prima1·y motivation
`fer, although
`behind
`the OPP is tl1at of exchangin g elect1·011ic bu siness cards. OPP
`uses OBEX, as do all of the object exchan ge p1·ofiles. The vCar d object
`for1nat men.tioned in Chapt er 9 can be used to 1·epresent a bu iness card
`that can be exchanged using the OBE X protocol. Certainly other ty pes
`of objects besides vCa1·ds (including· notes, messages, calenda1· entries
`and in fact any object that could be exchang·ed using OBEX ) can be
`used with the OPP , but the ration ale behind the OPP is the busines s
`card exchange usage model.
`The OPP assumes compliance vvith the GOEP and then fur ther
`details the scena1·ios, function s and app lication considerations associ-
`ated with object push. While it mak es allowan ces for pu sl1ing (and in
`certain ci1·cumstances pulling ) generi c objects be tween a client and a
`server, the OPP focuses on pushing business card objects.
`OPP Development
`The OPP was the last of the object exchange profiles to be defined. Syn-
`chronization and file transfer are fundam ental usage mode ls that ha ve
`existed since the SIG was fo11r1ed; thus they wer e ob \rious profile candi-
`dates. Originally only these two profile s were defined within the object
`exchange family. It was not untiljanuar y 1999 that the SIG mad e a dis-
`tinction between two types of object exchange: a simpl e obje ct push
`model and a folder-based browse , push and pull mod el. The former
`supports a ''business card exchange '' usage scenario, and this concept of
`unidirectional 3 object transfer eventually grew to become
`the OPP,
`although it was not originally called object push. The folder -based file
`transfer model is embodied in the file transfer profile , discussed below.
`One key difference between the OPP and the file transfer profile is
`that the OPP instantiates a usage case in which data objects might be
`offered in an unsolicited fashion. File transfer (and synchronization
`too)
`nor1nally are motivated by a desire of at least one party to acqliire new
`or updated information, and they often involve user intervention. Push-
`ing objects is a different model: at least one party might offer data with-
`out being asked, and that data is simply pushed to a static location (think
`of an in-box) without any afplication knowledge of file or directory
`structure. In some situations, a user might conJigure her device to offer
`her electronic business card to any other device that comes within prox-
`3. The previous footnote applies here also. The OPP can generally be thought of as a unidirec -
`tional object push, although limited object pulling is also possible, as explained in following
`sections.
`
`IPR2020-00202
`Apple Inc. EX1057 Page 268
`
`

`

`The Object Push Profile
`
`2 4 7
`
`imity and has the ability to take the business card.5 This aspect is unique
`to the OPP and was one of the main reasons that busine ss card
`exchange, or object push in general, was developed as a separate profile.
`OPP Examined
`Inh eriting from the GOE P, the OPP defines a client and a server role,
`but further refines these roles to those of a push client and a pzLSh server.
`Ju st as i11 the GOEP,
`tl1e push server is the device that provide s the
`object exchange service, while the client is the devic e that does the
`pushing (and perhap s pullin g) of objects. Of course these operations can
`be viewed as symmetric, in that if one device is pulling an object the
`other device might be consider ed to be pushing that same object. As
`explain ed for the GOEP, howeve r, the OBEX model does distinguish
`betw een a clie11t and a server, and the OPP maintains this distinction.
`As in the GO EP, the client and server roles do not imply anything
`about the und erlying baseband master and slave roles.
`One of the first concepts introdu ced in the OPP is that of pulling
`business cards, which for a profile dealing with pushing objects might
`seem unusual. Inde ed, tl1e OPP talks about push clients that can both
`push and pull objects to and f1·om push servers; this apparent dichot-
`omy merits furthe1· exploration. Th e key is found in the unique aspect
`of the OPP , noted above, that involves offering (pushing ) unsolicited
`data objects . From the viewpoint of tl1e push client, objects are always
`being pusl1ed to a push server. In fact, during the errata process of the
`version 1.0 specification , a clarification was added to the OPP (present
`in the version l.OB specification) explicitly stating that the push opera-
`tion involve s the client pushing an object to the server. Yet the same
`push client can also pull ce1·tain objects , as described below, from the
`push serve1·. Thi s concept is rooted in the OBEX transaction model,
`which has fundamental elements of pushing and pulling objects as well
`as the notion of a client and a se1·ver. One way that objects might be
`exchanged only through pushing is for a client to push an object to a
`serve1·, then have the devices exchange roles, then have the new client
`(old server) push an object to the new se1·ver (old client ). This would
`maintain a ''push-only'' purity but seems unnecessarily complex, given
`
`4. Consider, for example, meetings and trade sho,vs ,vhere business cards are exchanged; or any
`event at ,vhich a person might register herself by providing inforn1ation typically contained in a
`business card (nan1e, address, telephone number and so on).
`5. The OPP does ,varn against automating the object push operation, though , and suggests that
`user intervention should be required to initiate the object push and pull functions .
`
`IPR2020-00202
`Apple Inc. EX1057 Page 269
`
`

`

`248
`
`Cl1apter 14
`
`THE SERIAL AND OBJECT EXCHANGE PROFILES
`
`that the underlying protocol support s botl1 push and pull operations.
`Thus OBEX and the OPP allow a ''push centri c'' usage model that also
`includes an optimization for pulling ce1·tain objects from a push server,
`although push serve1·s are not 1·equi1·ed to supp ort this feature. Thi s opti-
`mization removes the need fo1· a client-server role switcl1 ,.vhile still per-
`mitting the idea of a push -based usag·e mod el.
`The OPP defines three functions: object pztsli., business card pull and
`business card excliange. Object push is, of cow·se, the fund amental opera-
`tion and the only mandatory function within the O PP. Th e other two
`functions are optimizations of the ty pe noted above, whereby the
`underlying OBEX pull operation is used to ext1·act a spe cific object,
`namely the owner's business cai·d, from the push serve r. The pull oper-
`ation is optional for push server s to support; note that the pull operation
`in the OPP is restricted to pulling only owner business cards and not
`other objects, while the push operation can pusl1 any object (the file
`transfer profile , iliscussed below , provid es a mor·e genera l bidirectional
`object exchange ). The business ca1·d exch ange function is rea lly ju st a
`composition of a business card object pu sh and a business card pull
`function; thus it too is optional . Figure 14.2 illustrates the typical oper a-
`tion of the OPP.
`
`)
`
`)
`
`Push
`client
`
`Push
`server
`
`Push (any) object
`..., __________________ _________________________________________ _
`Pull owner's business card object (optional)
`Figure 14.2
`Object push profile typical operation. Note that business card exchange is just a
`business card push along with a business card pull.
`Within the OPP are the procedures necessary to accomplish each
`of the object push, business card pull and business card exchange func-
`tions. The object push operation allows several types of objects to be
`pushed from the push client to the push server: vCard ( version 2.1 of
`vCard is required), vCal, vMessage and vNote. The SDP service record
`of the OPP also allows a value for ''any type of object," which would
`
`IPR2020-00202
`Apple Inc. EX1057 Page 270
`
`

`

`The Object Push Profile
`
`249
`
`permit two devices to exchan ge objects other than those noted above ,
`assumin g that both devices und erstand
`the object
`format
`to be
`exchang ed. The business card pull and business card exchange func-
`tions take advantage of the OBEX default get object, which is an objec t
`that can be pulled by type rather than by name. By specifying that the
`default get object contains the device owner 's busine ss card, the special
`case of pt1lling the default get object allows the busine ss card pull and
`exchange operation s to be accomplished within tl1e context of the OPP .
`The final point discussed here about the OPP is that of secu1·ity.
`While exchanging objects between devices can be very useful, it also
`could be dang erous when one considers security exposures like viruses,
`violation of privacy and denial of service. All of these could be concerns
`if devices excl1anged objects without any precautions. The OPP dis-
`cusses at least two types of security precaution s: the use of underlying
`Bluetooth transport security and user interaction. The OPP indicates
`that authentication and encryption at the baseband level must be sup-
`ported, although they need not be used for every transaction. In addi-
`tion, bondin g (described
`i11 the GAP), which
`requires a
`trust
`relationship between the two involved devices , must be supported, but
`again need not be used for eve1-y transaction. If used, these security fea-
`tures can sig·nificantl y reduce the exposures noted above, since objects.
`can be exchanged securely , and only with devices that are kno·wn and
`trusted. Beyond this, the OPP n1entions nume1·ous times that user inter·
`vention is recommended
`for many of the steps required to accomplis.H
`object push and pull ope1·ations. The p1·ocedures in the OPP that out-
`line each of the push , pull and exchange functions all include steps
`where it is recommended
`that tl1e user decide whether or not to accept
`an object being pushed or to allow an object to be pulled.
`
`OPP Usage
`As discussed in the GO EP section above, middleware that implements
`the GOEP can provide a foundation for applications that implement
`the other object exchange profiles. Since all of these profiles share the
`common elements of the GOEP, it would not be uncommon
`to imple-
`ment synchronization,
`file transfer and object push all in the same
`device. Much of the code-that which instantiates
`the GO EP-could
`likely be reused in each of the remaining p1·ofiles.
`In fact, the OPP, fi·om an application perspective, can be consid-
`ered to be a special case of file transf e1·. Like file transf e1· ( discussed
`below), the OPP pushes (and perhaps pulls) objects between a client and
`
`IPR2020-00202
`Apple Inc. EX1057 Page 271
`
`

`

`250
`
`Cl1apter 14 t THE SERIAL AND OBJECT EXCHANGE PROFILES
`
`a se1-ve1·. The OPP restricts the type s of objects tl1at can be pushed and
`the circumstances under which specific objects can be pull ed, so in some
`respects 6it is a subset or resbicted case of file transfer. Syn ch1·011ization
`(also discussed below ) could require significant addi tional logic beyond
`the object ti·ansfer function s, bu t file t1·ansfe1· and object pu sh, in many
`cases, might be implemented
`in the same appli cation (although
`the func-
`tions might be p1·ese11ted to the use1· as two separ ate applicat ions).
`Application considerations
`for OPP includ e the pro vision of a user
`interface
`to allow the required user intervention
`to occu1·. Th e user is
`the final arbiter of which objects are permi tted lo be pu shed on to and
`pulled from his device , so the appli cation needs to pern1it this sort of
`user interaction. Some of the se fun ctio11s might be can didates for inte-
`gration with a general device control appli cation such as the Bluetoot h
`piconet minder application described in Chapter 8.
`
`THE FILE TRANSFER PROFILE
`The file transfer profile , or FP ,7 is the second of the thr ee pr ofiles in the
`object exchange famil y. Like synchr onization and object pu sh , the FP
`uses OBEX
`to exchange object s, in this case files and dir ectories (or
`folders ). Du1ing the early phase s of the specificatio11 de velopm ent, the
`definition of TCP / IP over Bluetooth
`link s was inves tiga ted (see the dis-
`cussion of OBEX over TCP / IP in Chapter 9) and thu s the IETF file
`transfer protocol (ITP ) was a candidate for a file transfer profil e. In the
`end, the version 1.0 specification did not address g·eneric IP networking
`links, so ITP is not a part of the version 1.0 file tran sfer
`over Bluetooth
`profile, although in the future this almost certainly will be an alternative
`method for file transfer. Within the version 1.0 realm,
`though , file and
`object transfer is via OBEX.
`The FP can be considered
`to be a less restrictive, mo ·re robust form
`of the OPP in that it supports full bidirectional pushing and pulling of
`objects, yet it supports only two object types: file and folder. The FP does
`not directly address exchanging other object types like vCard , vCal and
`so on, although
`those object types could certainly be packaged as files
`and could be transferred using the FP.
`
`6. At least from an implementer's vie,v, although perhaps not from an end user's vie\-v.
`Z We use FP rather than FTP to remove any confusion with the Internet file transfer protocol.
`
`IPR2020-00202
`Apple Inc. EX1057 Page 272
`
`

`

`The File Transfer Profile
`
`251
`
`FP Development
`Th e OBEX protocol was originall y adopted from the lrDA to support
`the synch1·on ization usage model. But OBEX also supports general file
`transfer, which has been used in IrDA for some time. File transfer has
`been a fun darnental Bluetoot h usage scena rio since the SIG was
`farm ed, altho ugh it originally fell unde1· the conferenc e room scenario.
`As not ed in the OPP discussion above, the FP originally was an ali-
`en com pas sing profile for object exchang e but eventually was split into
`lhe two distinct app lication s of object pu sh, cove red in the OPP, and
`fold er-ba sed b1·owsing, pu shing and pulling that remains in the FP.
`FP Examined
`Client and serv er roles are defined by the FP in a manner similar to the
`oth er obj ect exc hange profile s. In this case, the client is the device that
`initiate s transact ions and pr esum ably will be pulling files from the
`serv er, although the client might also pu sh objects to the server as
`de scribe d below. The server is the devi ce that exports a folder to the cli-
`ent, which the client can browse to initiate requests to pull files (or other
`fold ers) from the server. Th e server also accepts other data from the cli-
`ent, includin g files that the client might pu sh and requests to create or
`delete objects on the serve1·. While the client and server role definitions
`are imp ortant for execution of the profil e, many of the operations a:e
`symm etric, and it the1·efore seems likely that many devices can and ,.,vill
`impl ement both client and server function s of the FP. Indeed, the FP
`note s that a devi ce can support either role or both.
`.
`.
`Th e operations defined by the FP a1·e typical file marupulation
`operations, and they include:
`• Pulling files and folders
`• Pushing files and folders
`• Browsing and navigating folders
`• Deleting files and folders
`• Creating new files and folders
`.
`.
`,
`th clients v1ewpomt.
`ti· ons and
`Each of these operations
`is desc1ibed from
`e
`.
`.
`th
`client opera
`,
`Server operations occur 1n response
`to
`d' g to requests
`e
`·
`1
`.
`d c Id
`d respon in
`include supplying 1·equested fi es a11 10 ers ~n and file transfer (push -
`to delete and create objects. The folder bi·owstngboth client and server,
`ing and pulling ) operations are mandatory
`for consisting of pulling a
`and these allow the simplest fo1m ?f file transfer, all files in the folder ),
`folder (the description, not the entire contents of
`
`IPR2020-00202
`Apple Inc. EX1057 Page 273
`
`

`

`2 52
`
`Chapter 14 > THE SERIAL AND OBJECT EXCHANGE PROFILES
`
`selecting one or more files in tha t fold er, and pullin g· those files. Oth er
`operation s that p1·ovide mo1·e advanced
`ft.111ctions are optio nal; these
`include the ability to pull enti1·e fold er contents (which cot 1Id be acco m-
`plished with an iteration
`that pull s all files in a folder, using just the
`basic folder brow sing and file pulling · ope r·ation s) and the ability to cre-
`ate and delete object s. The FP includ es pro cedu 1·es to follow for both
`client and ser,rer to accompli sh these operatio ns, along· witl1 the cor1·e-
`sponding OBEX operation s of the GOEP
`t1sed in tl10 e procedur es.
`Figure 14.3 depicts typi cal FP operation ; two cliffe1·ent types of devices
`are shown to illustrate that this ·usag·e scenario is not 1·estricted only to
`traditional computers. Any two devices with compatible file repre senta -
`tions could use the FP for file trans[ e1·.
`
`)
`
`)
`
`Pull folder (description)
`
`Client
`
`Browse folder
`
`Pull file(s)
`Push files, create/delete files, folders (optional)
`----------------- --------------------------- ------- ---•
`Figure 14.3
`Typical file transfer profile operation.
`The FP assumes user interaction for all file transfer operation s. In
`and
`addition to mandatory support (but optional use) of authentication
`encryption, the FP mandates user intervention
`to initiate file transfers.
`As in the OPP, security exposures could surface when files are mo ve d
`to a new device. Therefore
`the FP also requires user intervention
`to
`accept files f1·om another device and to pull files from other de vices.
`The FP assumes that a user interface will be presented on a device as a
`result of pulling a folder description. That user interface allows the user
`to browse and select files to pull; similarly, local files can be browsed
`and selected for pushing to another device. So while the protocol stack
`
`. . 1
`h
`8. Consider also de ·
`err;d :S files using the diskette . Since the camera must have a file system, the disket te drive
`.
`.
`.
`vices sue as d1gita cameras with diskette dnves. Today pictures are trans -
`d
`fi
`e removed and the files could be transferred using the Bluetooth FP.
`cou
`
`IPR2020-00202
`Apple Inc. EX1057 Page 274
`
`

`

`The Synchronization Profile
`
`253
`
`the
`includes security features that can be used in file transf e1· operations,
`FP leaves to the end user tl1e ultimate choice of which files to accept.
`FP Usage
`As described in the OPP section, it seems likely that both OPP and FP
`migl1t be implemented
`together in many devices. Once the GOEP sup-
`port is in place, the addition s needed to support OPP and FPP are simi-
`la1·, and ind eed might use the same code.
`As noted in Chapter 3, file lJ:ansfer is one of the mo st fundamental
`and useful functions of data networking. Many device manufacturers
`believe that t1·ansfe1·1ing files and other objects is one of the most impor -
`tant scenarios to suppor t in wi1·eless communi cation, since most users
`are likely to expect and make use of this function. Thus the FP plays an
`imp o1·ta11 t role in helping to ensure that file transfer can be accom-
`plished i11 an intero per able fashion using Bluetooth technology.
`Most devices that are likely to suppo1·t the FP already have a file
`system and som e sort of user interface for that file system; in addition
`they probably already include some n.otion of transferring files. While
`the mechanism used may or may not include OBEX file transfer , irnple-
`mentations of OBEX
`that meet the requir·ements of the GOEP can
`p1·obabl y be proct1red or developed in a straightforward manner. With
`GOEP-compliant OBEX support in place, and with a Bluetooth adap-
`tation layer in the devic e's software stack that permits the use of Blue-
`tooth links, it should be possible in most cases to link ( or perhaps adapt )
`existing file system user interfaces for use with the Bluetooth FP.
`An integTated use1· interface fo1· FP (and also fo1· OPP) might
`include a Bluetooth piconet minder application like that described
`in
`Chapter 8 that allows users to select devices and services in p1·oximity.
`One option for a device that is selected in this way could be to obtain
`file folde1·s from that device and initiate file transfer ( or business ca1·d
`exchange in the case of OPP as discussed above). This seems to p1·ovide
`an easy, straigl1tforward and intuitive method for extending the existing
`functions of a given device or platform to take advantage of Bluetooth
`wireless communication between two coope1·ating devices.
`
`·
`
`--
`
`THE SYNCHRONIZATION PROFILE
`Synchronization
`is a popula1· data communi~ations application and it
`has been one of the Bluetooth usage models since the SIG was formed.
`
`IPR2020-00202
`Apple Inc. EX1057 Page 275
`
`

`

`254
`
`Chapter 14
`
`THE SERIAL AND OBJECT EXCHANGE PROFILES
`
`The final member of the object excha11g·e fa1nily of pr ofiles is the syn-
`chronization profile, or SP. The SP also build s up on t}1e GOEP and
`uses the IrMC protocol to synch1·011ize obje cts.
`Synchronization can be consider·ed to be a special case of object
`transfer in which prog1·ammatic decision s about which objec ts to t1·ans-
`fer in which direction a1·e n1ade by syncl11·011ization softwar·e logic. Th e
`actual synchronization proces s can 1·ang·e f1·om very sim ple (t1nidirec-
`tional pushing or pulling of a gToup of objects \,vitl1out any special treat-
`ment of those objects ) to very involved (selective excha11ge of objects or
`even partial objects usi11g principle s like differencing a11d conflict reso-
`lution). Bluetooth sy11ch1·onization as defin ed in the SP tend s to 1nore
`closely 1·esemble the former, although appli catio11 logic can be add ed to
`the basic operations of the SP to achieve more sophisticate d synchroni-
`zation models. Data can be synchronized bet\vee 11 any two9entities,
`including devices and netvvorks.
`SP Development
`is probabl y the mo st complex of the
`Even though synchronization
`object exchange scenarios, the development of the SP prec eded that of
`the FP and OPP. The group that developed
`the IrDA inte1·operabili ty
`protocols and their corresponding object exchang e profil es was known
`within the SIG as the synchronization group.
`Since the SIG's beginnings , synchronization among man y classes
`of devices (phones, PDAs, notebook compute1·s and othe1·s) has been a
`key usage case. In mid-1998, shortly after the SIG 's formation,
`the pos-
`sibilities for automated synchronization
`(described more fully in Chap-
`ter 3) had already been identified and the use of OBEX
`to accomplish
`these scenarios had already been proposed. The
`incorporation
`of
`OBEX into the Bluetooth protocol stack was primarily
`intended
`to sup -
`port synchronization but, as we have seen, it also permits business card
`exchange, file transfer and other object transfer usage cases. A funda -
`mental requirement was to be able to synchronize at least calendar and
`address book entries, although we will see that other data types can be
`synchronized as well.
`The synchronization
`task force within
`the SIG was unusual
`(although not unique) in that, in addition to the five promoter compa-
`(namely PUMATECH™
`nies, other contributing adopter companies
`9. In fact it is possible to synchronjze data among more than two devices, but we foct1s here on
`synchronizing between a pair of devices, ,vhjch most closely matches the Bluetooth communi·
`cation model.
`
`IPR2020-00202
`Apple Inc. EX1057 Page 276
`
`

`

`The Synchronization Profile
`
`255
`
`and Extended Systems rt-1, both of whose primary business is in the area
`of data synchronization ) participated
`in the specification's development.
`Because synchronization from the outset was one of the main usage
`models, the SP was one of the first profiles to be developed. It was not
`completed any sooner than most other profiles, though, owing mostly to
`the fact that new enhancements
`to the profile (like provision for auto-
`mated synchronization
`and the addition of new and updated object for-
`an initial level of stability. One
`mats ) were added after it reached
`interesting aspect of the SP's development
`is that it, along with the other
`object exchange profiles, was the first to add a section on service discov-
`ery , with service record and SD P t1·ansaction information. In this respect
`it served as a model for the other profiles, all of which (except for the
`in the version 1.0 specification.
`''generic '' ones ) contain such information
`SP Examined
`The SP first defines device roles, which once again derive from the
`GO EP and consist of a client and a server role. The client is the device
`that pulls data from the server, synchronizes
`that data against its own
`local objects, and pushes the resulting synchronized data back to the
`server. The server must support an object exchange service based upon
`the GOEP. As with the other object exchange profiles, these roles have
`no bearing on the unde1·lying baseband master and slave roles. The SP
`that the server is usually a phone or a PDA, with the client
`indicates
`usually being a PC. This is curious, since servers traditionally are c_o~-
`sidered
`to be the more robust and capable machines. For the SP, ~t 1s
`the client that must contain the synchronization
`logic tha~ deter1nmes
`how to process the objects to achieve a synchronized ver~1on of t~em.
`Thus the SP describes a PC as a typical client, since a PC 1s more hkely
`to have available storage and processing power to operate a s):Ilchronlid-
`e-any device cou
`.
`.
`h'
`d
`b
`th
`zation engine. However,
`t 1s nee
`not
`e
`e cas
`d
`,
`. 1
`take on the role of client or server, as appropriate. But to ay s typh ica
`.
`" mall'' server, sue as a
`h
`synchronization models usually sync ron1ze a 5
`k syn-
`'' 1·
`PC or even a networ
`t lik
`''l
`. al SP opera-
`PDA or phone, against a arge c 1en
`e a
`.
`service. Tl1is model is preserved U1 the typic
`chronization
`tion, which is illustrated in Figure 14.4.
`
`IPR2020-00202
`Apple Inc. EX1057 Page 277
`
`

`

`256
`
`CI1apter 14 !> THE SERIAL AND OBJECT EXCHANGE PROFILES
`
`)
`
`)
`
`Initiate synchronization operal1on
`Pull objects to be synchronized
`
`Client
`
`._ _ __,
`
`Perform synchronization against local objects
`Push resulting synchronized objects
`
`Server
`
`Figure 14.4
`Typical synchronization profile operation.
`The SP does not directly address the 1-ules and proce sses necessary
`for a synchronization engine to actually synchronize the objects with
`each other. Instead it defers to the IrMC specification [IrDA99b] for
`that level of detail, since there is no par ticular reason to modify tl1ese
`aspects of synchronization for use in Bluetooth enviro nments . Instead
`the SP focuses on the proc edures needed to initiate and contro l the syn-
`chronization proces s. The SP discusses both client- and server- initiated
`synchronization and provides procedur es to follow for tl1ese. In the
`former case there are two distinct scenario s: one for when the two
`devices are not yet known to each other and anoth er for when the
`devices have already bonded (that is, are known to and trusted by each
`other). The second case is an optimization that takes advantage of the
`fact that the devices have already bonded. Another proc edure is sup-
`plied for automated synchronization , which is a special case of client -
`initiated synchronization that is started without user intervention. Onl y
`bonded devices can synchronize automaticall y.
`Several different object types can be synchronized using the SP;
`the profile does not mandate which object types must be supported.
`Instead it mandates that at least one of the defined object types-phone-
`book {or address book), calendar, notes and messages-be able to be
`synchronized. SDP is used to discover the supported object type(s) for
`the synchronization service.
`The SP relies heavily on the GOEP and GAP, making use of sev-
`eral of the definitions and functions in each. In particular, some of the
`features defined in the GAP and GOEP are used for security. The SP
`mandates one of the highest security levels among all of the version 1.0
`profiles. It restricts synchronization
`to bonded, or paired, devices and
`
`IPR2020-00202
`Apple Inc. EX1057 Page 278
`
`

`

`I
`
`The Synchronization Profile
`
`2 5 7
`
`requires the use of authentication and encryption. Further, the OBEX-
`level authentication discussed in the GO EP optionally may also be
`used. Unlike the FP and OPP , the SP does not call for user intervention
`as a security measu1·e. A user may initiate the synchronization transac-
`tion (although in tl1e case of automated synchronization, even this user
`interactio n is unn ecessary) and may be informed of the status and
`resu lts of the synch1·onization operation, and might even be consulted
`abo ut desi1·ed actions (say, for conflict resolution) during synchroniza-
`tion. But the user typically does not authorize individual pushes and
`pulls of objects as in the FP and OPP (although the user might identify a
`set or class of objects that a1·e to be synchronized). Since the SP does not
`rely on the user as a security arbit er, it specifies a relatively high level of
`other security functions from the protocol stack.
`SP Usage
`Synchronization is a somewhat specialized application, although a popu-
`lar one. It is a bit different from file transfer and object push, although the
`SP uses many of the same und erlying constructs and functions that the
`FP and OPP use. Since the SP build s upon the GOEP, an SP implemen-
`tation could reuse OBEX rnidclleware that is also used for FP and OPP.
`But unlike FP and OPP , which could be very similar (if not the same)
`applications, SP would not necessarily be expected to be implemented
`on all of the devices where FP and OPP are implemented. A digital cam-
`era, fo1· example, might implem ent a file transfer function, as described in
`footnote 94 above, but the synchronization function on a camera. see.ms
`less likely. As the SP notes, the devices most likely to use synchroruzatio~
`are notebook comput ers, phone s and PDAs; these are devices. that( tyftpi-
`.
`d ther information o en
`cally contain addre ss books, appomtmen ts an o
`.
`called "PIM " or personal infonnation management functions) .
`· tion of the synchro-
`. 1 d d
`esc~ I MC specification
`The SP does not provide any detai e
`nization pro cess itself; application s must. look to I
`though there is
`for guidan ce. Even beyond what is specified b~ r0. n 'applications can
`d'fc
`· ti'
`Synchron1za 0
`.
`1.
`i·oom for app 1cat1on 1 1erent1a on.
`timized methods fo1·
`add value through enhan ced user interfaces,1.0kP
`·
`nd the I e.
`. .
`b.
`exchanQ"ing and synchron1z1ng o ~ects a
`h t ·s enabled by Blue-
`.
`. aaon t a i
`o
`. still required, even
`In the case of automated syncbroniz
`.
`I. canon is
`.
`.
`.
`.
`tooth proximity networking, an app 1
`h ti·me synchronization is
`· at t e
`· d
`for
`·
`h
`though it may not be visible to t e user . h to configure his eVIce
`bly will wis
`· possible does
`F.
`.
`Perf orined . 1rst, a user pre sum a
`th' s fun ca on 1s
`. . U t b cause
`t
`automated synchron1zat1on us
`e
`
`IPR2020-00202
`Apple Inc. EX1057 Page 279
`
`

`

`258
`
`Cl1apter 14 THE SERIAL AND OBJECT EXCHANGE PROFILES
`
`not mean that every use1· will wish to take advantage of it; some users
`might want to use this feature selectively). In addition, some application
`software is needed on both the client and the server to discover the
`automated synchronization capability and to sta1-t and carry out the syn-
`chronization operation. In man y situation s it is also advisable to provide
`some sort of indication to the user that the automated synch1·onization is
`underway ( this probably should at least be a user-con figu1·able option,
`because many users are uncomfortabl e having their per sonal devices
`engage in nontrivial communications with other devices without their
`knowledge ).
`A final application consideration in the case of automate d synchro-
`nization 10is how to deal with a device that leaves the proximity range
`before the synchronization operation com pletes. Consider a case where
`a user walks into an office with a PDA in a pocket or purse. If appropri-
`ately configured, the PDA might begin synchronizatio n with a PC in
`the office without the user being aware of it. The user might leave the
`office in the middle of the synchronization pro cess. Thu s the synchroni -
`zation application needs to somehow accoun t for this possibility, per -
`haps through a checkpoint and restart proces s of partial synchronization
`or some other means.
`
`10. This consideration also applies for user-initiated synchronization, but l