BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 359 of 440
`
`File Transfer Profile
`
`F0 R EWO R D
`
`This document, together with the Generic Object Exchange profile and the
`Generic Access profile form the File Transfer usage model.
`
`interoperability between devices from different manufacturers is provided for a
`specific service and usage model if the devices conform to a Bfuetooth SIG-
`defined profile specification. A profile defines a selection of messages and
`procedures (generally termed capabilities} from the Bluetooth SIG specifica-
`tions, and gives an unambiguous description of the air interface for specified
`service(s) and usage mode|( ).
`
`All defined features are process-mandatory. This means that if a feature is
`used, it is used in a specified manner. Whether the provision of a feature is
`mandatory or options! is stated separately for both sides of the Bluetooth air
`interface.
`
`1 December 1999
`
`AFFLT0294669
`
`Samsung Ex. 1119 p. 1441
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`File Transfer Profile
`
`1
`
`INTRODUCTION
`
`1.1 SCOPE
`
`page 360 of440
`
`Bluetooth-
`
`The File Transfer profile defines the requirements for the protocols and proce-
`dures that shall be used by the applications providing the File Transfer usage
`model. This profile uses the Generic Object Exchange profile (GOEP) as a
`base profile to define the interoperability requirements for the protocols needed
`by the applications. The most common devices using these usage models can
`be (but are not limited to) PCs, notebooks, and PDAs.
`
`The scenarios covered by this profile are the following:
`
`- Usage of a Bluetooth device (e.g. a notebook PC) to browse an object store
`(file system) of another Bluetooth device. Browsing involves viewing objects
`(files and folders) and navigating the folder hierarchy of another Bluetooth
`device. For example. one PC browsing the file system of another PC.
`
`- A second usage is to transfer objects (files and folders) between two
`Bluetooth devices. For example, copying files from one PC to another PC.
`
`- A third usage is for a Bluetooth device to manipulate objects (files and fold-
`ers) on another Bluetooth device. This includes deleting objects, and
`creating new folders.
`
`1.2 BLUETOOTH PROFILE STRUCTURE
`
`In ?~'ig;u.r'e 13:, the Bluetooth profile structure and the dependencies of the pro-
`files are depicted. A profile is dependent upon another profile if it re-uses parts
`of that profile, by implicitly or explicitly referencing it. Dependency is illustrated
`in the figure: a profile has dependencies on the profi|e(s) in which it is con-
`tained — directly and indirectly.
`
`1 December 1999
`
`introduction
`
`AFFLT0294870
`
`Samsung Ex. 1119 p. 1442
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 361 of 440
`
`File Transfer Profile
`
`Service Discovery
`Profle
`
`Fax Profile
`
`,.
`
`File Transfer Profile
`
`"
`
`.,.,._.,.,,._..,..,...,..,..._..._..,...,.._..._.,.
`Headset Profile
`
`Object Push Profile
`
`LAN Access Profile
`
`S’"°"'°"i“’“°"
`
`Figure 1.1: Bluetooth Profiles
`
`1.3 BLUETOOTH OBEX-RELATED SPECIFICATIONS
`
`Bluetooth Specification includes five separate specifications for OBEX and
`applications using OBEX.
`
`1. Bluetooth IrDA Interoperability Specification {'3}.
`
`- Defines how the applications can function over both Bluetooth and IrDA.
`
`Specifies how OBEX is mapped over RFCOMM and TCP.
`
`Defines the application profiles using OBEX over Bluetooth.
`
`. Bluetooth Generic f;3b_ie-st Eixclzarage Profile Specification {2}
`
`Generic interoperability specification for the application profiles using OBEX.
`
`Defines the interoperability requirements of the lower protocol layers (e.g.
`Baseband and LMP) for the application profiles.
`
`. Bluetooth Syr:t:tir'onizei_ior: Profile Specification {.33
`
`Application Profile for Synchronization applications.
`
`Defines the interoperability requirements for the applications within the
`Synchronization application profile.
`
`Does n_ot define the requirements for the Baseband, LMP, LZCAP. or
`RFCOM M.
`
`Introduction
`
`1 December 1999
`
`AFFLT0294671
`
`Samsung Ex. 1119 p. 1443
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`page 362 of440
`
`File Transfer Profile
`
`Bluetooth-
`
`4. Bluetooth File Transfer Profile Specification (This Specification)
`
`- Application Profile for File Transfer applications.
`
`- Defines the interoperability requirements for the appiications within the File
`Transfer application profile.
`
`Does n_ot define the requirements for the Baseband, LMP, L2CAP, or
`RFCOM M.
`
`. Bluetooth Qi.‘l_§i’-3i‘..‘l_ Push F’s'ot”sle Specification {4}
`
`Application Profile for Object Push applications.
`
`Defines the interoperability requirements for the applications within the
`Object Push application profile.
`
`Does n_ot define the requirements for the Baseband, LMP, L2CAP, or
`RFCOMM.
`
`1.4 SYMBOLS AND CONVENTIONS
`
`1.4.1 Requirement status symbols
`
`In this document (especially in the profile requirements tables in Annex A), the
`following symbols are used:
`
`‘M’ for mandatory to support (used for capabilities that shall be used in the
`profile);
`
`‘O’ for optional to support (used for capabilities that can be used in the profile);
`
`‘C‘ for conditional support (used for capabilities that shall be used in case a
`certain other capability is supported);
`
`‘X‘ for excluded (used for capabilities that may be supported by the unit but
`shall never be used in the profile);
`
`‘N!A‘ for not applicable (in the given context it is impossible to use this
`capability).
`
`Some excluded capabilities are capabilities that, according to the relevant
`Bluetooth specification, are mandatory. These are features that may degrade
`operation of devices following this profile. Therefore. these features shall never
`be activated while a unit is operating as a unit within this profile.
`
`1 December 1999
`
`introduction
`
`AFFLT0294872
`
`Samsung Ex. 1119 p. 1444
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 363 of 440
`
`File Transfer Profile
`
`1.4.2 Signaling diagram conventions
`
`The following arrows are used in diagrams describing procedures:
`
`PROC1
`-
`
`PROC2
`—————~—~———«————~—«———-—~———a-
`
`PROC3
`
`-1
`
`D-
`
`(PROC4)
`
`p (
`
`PROC5)
`
`
`
`MSG1
`
`
`MSG2
`
`
`
`{MSG3)
`
`T (
`
`MSG4)
`
`T
`
`Table 1.1: Arrows used in signaiing diagrams
`
`in the table above, the following cases are shown: PROC1 is a sub-procedure
`initiated by B. PROC2 is a sub-procedure initiated by A. PROC3 is a sub-
`procedure where the initiating side is undefined (may be both A and B).
`PROC4 indicates an optional sub-procedure initiated by A, and PROC5 indi-
`cates an optional sub-procedure initiated by B.
`
`MSG1 is a message sent from B to A. MSG2 is a message sent from A to B.
`MSG3 indicates an optional message from A to B, and MSG4 indicates an
`optional message from B to A.
`
`Introduction
`
`1 December 1999
`
`AFFLT0294873
`
`Samsung Ex. 1119 p. 1445
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 364 of440
`
`Flle Transfer Profile
`
`2 PROFILE OVERVIEW
`
`2.1 PROFILE STACK
`
`Bluetooth.
`
`The figure below shows the protocols and entities used in this profile.
`
`Application
`
`Application
`
`File Transfer Client I Fi|eTransfer Server
`
`OBEX
`
`-
`
`-
`
`-
`
`i
`
`File Transfer Client side
`
`File Transfer Server side
`
`Figure 2.1: Protocol model
`
`LMP [6] and LZCAP {IF} are the OS! layer 1 and 2 Bluetooth
`The Baseband
`protocols. RFCOMM {8} is the Bluetooth adaptation of GSM TS 07.10 [. }. SDP
`is the Bluetooth Service Discovery Protocol HG}. OBEX {1} is the Bluetooth
`adaptation of lrOBEX {T2}.
`
`The RFCOMM_ LZCAP, LMP, and Baseband interoperability requirements are
`defined in GOEP.
`
`2.2 CONFIGURATIONS AND ROLES
`
`Objects Being Pushed
`
`T; 4
`
`ca
`Objects Being
`Pulled
`
`Figure 2.2: Bl-directional File Transfer Example between two Personal Computers
`
`1 December 1999
`
`Profile overview
`
`AFFLT0294674
`
`Samsung Ex. 1119 p. 1446
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 365 of 440
`
`File Transfer Profile
`
`The following roles are defined for this profile:
`
`Client — The Client device initiates the operation, which pushes and pulls
`objects to and from the Server. In addition to the interoperability requirements
`defined in this profile. the Client must also comply with the interoperability
`requirements for the Client of the GOEP if not defined in the contrary. The
`Client must be able to interpret the OBEX Folder Listing format and may
`display this information for the user.
`
`Server — The Server device is the target remote Bluetooth device that provides
`an object exchange server and folder browsing capability using the OBEX
`Folder Listing format. In addition to the interoperability requirements defined in
`this profile, the Server must comply with the interoperability requirements for
`the Server of the GOEP if not defined in the contrary.
`
`2.3 USER REQUIREMENTS AND SCENARIOS
`
`The scenarios covered by this profile are the following:
`
`- Usage of the Client to browse the object store of the Server. Clients are
`required to pull and understand Folder Listing Objects. Servers are required
`to respond to requests for Folder Listing Objects. Sewers are required to
`have a root folder. Servers are not required to have a folder hierarchy below
`the root folder.
`
`Usage of the Client to transfer objects to and from the Server. The transfer
`of objects includes folders and files. Clients must support the ability to push
`or pull files from the Server. Clients are not required to push or pull folders.
`Servers are required to support file push, pull. or both. Servers are allowed
`to have read-only folders and files, which means they can restrict object
`pushes. Thus, Servers are not required to support folder push or pull.
`
`Usage of the Client to create folders and delete objects (folders and files) on
`the Server. Clients are not required to support folderffile deletion or folder
`creation. Servers are allowed to support read-only folders and files, which
`means they can restrict folderiflle deletion and creation.
`
`A device adhering to this profile must support Client capability, Server
`capability or both. The restrictions applying to this profile are the same as in the
`GOEP.
`
`2.4 PROFILE FUNDAMENTALS
`
`The profile fundamentals are the same as defined in Section 213 in GOEP {:3}.
`Support for link level authentication and encryption is required but their use is
`optional.
`
`Support for OBEX authentication is required but its use is optional.
`
`This profile does not mandate the server or client to enter any discoverable or
`
`Profile overview
`
`1 December 1999
`
`AFFLT0294675
`
`Samsung Ex. 1119 p. 1447
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`page 366 of440
`
`File Transfer Profile
`
`connectable modes automatically, even if they are able to do so.
`
`On the Client side, end-user intervention is always needed to initiate file
`transfer (see Cizaptes‘ 3).
`
`Support of bonding is required but its use is optional.
`
`1 December 1999
`
`Profile overview
`
`AFFLT0294876
`
`Samsung Ex. 1119 p. 1448
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 367 of 440
`
`File Transfer Profiie
`
`3 USER INTERFACE ASPECTS
`
`3.1 FILE TRANSFER MODE SELECTION, SERVERS
`
`Sewers must be placed in File Transfer mode. This mode enables a Client to
`perform file transfer operations with the Server. When entering this mode, File
`Transfer Servers should set the device in Limited Discoverabie mode (see
`Generic; Access Pa-et'ile), ensure that the Object Transfer Bit is set in the CoD
`(see {$53}, and register a service record in the SDDB (see section
`on page
`383).
`
`It is recommended that this mode be set and unset by user interaction. when
`possible. Public devices. devices that want to be visible at all times. or devices
`that can not supply a user interface to enable File Transfer mode shall use
`Genera.-‘ Discoverabie mode (see Generic fitccess F-irr-file) instead of Limited
`Discoverabie mode.
`
`3.2 FUNCTION SELECTION, CLIENTS
`
`Clients provide file transfer functions to the user via a user interface. An exam-
`ple of a file transfer user interface is a file-tree viewer to browse folders and
`files. Using such a system fi|e—tree viewer, the user can browse and manipulate
`files on another PC. which appears in the network view.
`
`File Transfer Applications provide the following functions.
`
`Select Server
`
`Navigate Folders
`
`Pull Object
`
`Push Object
`
`Delete Object
`
`Create Folder
`
`Selecting the Server from a list of possible Servers, and
`setting up a connection to it.
`
`Displaying the Server's folder hierarchy. including the files
`in the folders. and moving through the Server's folder hier-
`archy to select the current folder. The current folder is
`where items are pulled andior pushed.
`
`Copying a file or a folder from the Server to the Client.
`
`Copying a file or folderfrom the Client to the Server.
`
`Deleting a file or folder on the Server.
`
`Creating a new folder on the Server.
`
`When the user selects the Select Server function, an inquiry procedure will be
`performed to produce a list of available devices in the vicinity. Requirements on
`inquiry procedures are discussed in Section» 5.5.? of the GOEP E133}.
`
`User interface aspects
`
`1 December 1999
`
`AFFLT0294677
`
`Samsung Ex. 1119 p. 1449
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`page 368 of440
`
`Fiie Transfer Profiie
`
`3.3 APPLICATION USAGE
`
`In this section, the presented scenarios work as examples. Variations in the
`actual implementations are possible and allowed.
`
`When the Client wants to select a Server the following user interaction can be
`followed:
`
`Sewer
`
`The user sets the device into File Transfer
`mode. A Server typically does not need to
`provide any other user interaction.
`
`The user of the Client selects the File
`
`Transfer Application on the device.
`
`A list of Sewers that may support the File
`Transfer service is displayed to the user.
`
`The user selects a Server in which to con-
`neat. The connection may require the user
`to enter a password for authentication. If
`both link levei authentication and OBEX
`authentication is required, then the user will
`need to be prompted for two passwords.
`
`If the Client requires authentication of the
`Server, then the Server wiii need to prompt
`the user for a password. If both link level
`authentication and OBEX authentication are
`required, then the user will need to he
`prompted for two passwords.
`
`After the connection is complete. including
`any authentication, the contents of the
`Server‘s root folder are dispiayed.
`
`1 December 1999
`
`User interface aspects
`
`AFFLT029467B
`
`Samsung Ex. 1119 p. 1450
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 369 of 440
`
`Fife Transfer Profile
`
`The following user interaction shows how the user of the Client performs file
`transfer functions. The operations assume a Server has already been selected
`as described above.
`
`Client
`
`The user is presented with the folder
`hierarchy of the Server. The first presenta-
`tion has the root folder selected as the
`current folder.
`
`The user chooses a folder to be the current
`folder. The contents of this folder are dis-
`played.
`
`To push a file from the Client to the Server.
`the user selects a tile on the Client and acti-
`vates the Push Object function. The object
`is transferred to the current folder on the
`Server.
`
`To pull a file from the Server. the user
`selects a file in the current folder of the
`Server and activates the Pull Object func-
`tion. The user is notified of the result of the
`
`operation.
`
`To delete a file on the Server, the user
`selects the file in the Server’s current folder
`and activates the Delete Object function.
`The user is notified of the result of the oper-
`ation.
`
`To create a new folder on the Server. the
`user activates the Create Folder function.
`This function requests a name from the user
`for the folder. When complete. a new fotder
`is created in the Server’s current folder.
`
`User interface aspects
`
`1 December 1999
`
`AFFLT0294679
`
`Samsung Ex. 1119 p. 1451
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`Fife Transfer Profile
`
`4 APPLICATION LAYER
`
`page 370 of440
`
`Bluetooth-
`
`This section describes the feature requirements on units active in the File
`Transfer use case.
`
`4.1 FEATURE OVERVIEW
`
`The File Transfer application is divided into three main features, as shown in
`the ‘fabie 4.1 below.
`
`Features
`
`Folder Browsing
`
`Oblect Transfer:
`File Transfer
`Folder Transfer
`
`Support in
`File Transfer
`Client
`
`Support in
`File Transfer
`Server
`
`M
`
`Object Manipulation
`
`Table 4.1: Appttcation layer procedures
`
`*. Optional. but the server must be able to respond with an appropriate error code. even if
`it doesn't support these capabilities.
`
`4.2 FOLDER BROWSING
`
`A file transfer session begins with the Client connecting to the Server and pull-
`ing the contents of the Server's root folder. When an OBEX connection is
`made, the Server starts out with its current folder set to the root folder. The
`
`contents of folders must be transferred in the Folder Listing format specified in
`{'11}.
`
`Tabia 4.3 shows the application procedure required by the Client to connect to
`the Server and pull the contents of the root folder.
`
`1 December 1999
`
`Application layer
`
`AFFLT02946B0
`
`Samsung Ex. 1119 p. 1452
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`File Transfer Profile
`
`page 371 of 440
`
`Bluetooth.
`
`Client
`
`Details
`
`OBEX CONNECT.
`
`Pull the contents of the Server's
`root folder using GET.
`
`Target Header must be set to the Folder Browsing
`UUID:
`
`FQECTBC4-953C-11D2-984-E-5254-OODCQEUQ.
`
`This UUID is sent in binary (15 bytes) with most
`significant byte sent first (OXFQ is sent first).
`
`The Type Header must be set to the MlME-type of
`the Folder Listing Object {x-obexlfolder-listing).
`The Connect lD header must be set to the value
`
`returned in the Connect operation. A Name
`header is not used.
`Table 4.2: Application layer procedure for File Transfer Connect
`
`F
`
`Browsing an object store involves displaying folder contents and setting the
`‘current folder‘. The OBEX SETPATH command is used to set the current
`
`folder. To display a folder hierarchy starting with the root folder, the Client must
`read the root folder contents using GET. It must then retrieve the contents of all
`sub-folders using GET. If the sub-folders contain folders. then the Client must
`retrieve the contents of these folders and so on. To retrieve the contents of a
`
`folder. the Client must set the current folder to the sub-folder using SETPATH,
`then pull the sub-folder contents using GET. Table 4.3 shows the application
`procedure required for retrieving the contents of a sub-folder.
`
`Client
`
`Details
`
`Set the current folder to the sub-
`folder using OBEX SETPATH.
`
`Name header is set to the name of the sub-folder.
`Connect ID header is required.
`
`Pull the contents of the sub-folder
`using GET.
`
`Set the current folder back to the
`
`root folder using OBEX SETPATH.
`
`If the parent of the sub-folder is not
`the root folder, then set the current
`toider to the parent folder using
`SETPATH.
`
`No Name is sent, since the sub-folder is the current
`folder. The Type Header must be set to the MIME-
`type of the Folder Listing Object {X-obexlfolder-Iisb
`Eng). Connect ID header is required.
`
`Name header is empty. Connect ID header is
`required.
`
`The Backup flag is set and no Name header is sent.
`Connect ID header is required.
`
`Table 4.3: Application layer procedure for Folder Browsing
`
`Application layer
`
`1 December 1999
`
`AFFLT02946B1
`
`Samsung Ex. 1119 p. 1453
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`Flle Transfer Profile
`
`4.3 OBJECT TRANSFER
`
`page 372 of440
`
`Bluetooth-
`
`Objects are transferred from the Client to the Server using OBEX PUT, and
`objects are transferred from the Server to the Client using OBEX GET.
`Transferring files requires a single PUT or GET operation per file. Transferring
`folders requires transferring all the items stored in a folder, including other
`folders. The process of transferring a folder may require that new folders be
`created. The SETPATH command is used to create folders.
`
`Table 15;.-"3 shows the application procedure for transferring a folderfrom the Cli-
`ent to the Server. If the folder contains other folders. then these other folders
`are transferred using the same method. The folder is transferred to the current
`folder on the Server.
`
`Client
`
`Details
`
`Create a new folder (if it does not
`already exist) in the Server's current
`folder using SETPATH. The current
`folder is changed to this new folder.
`
`Name header is set to the name of the new folder.
`Connect ID header is required.
`
`Push all files to the new folder using
`a PUT command for each file.
`
`The Name header is set to the name of the file. Con-
`nect ID header is required.
`
`Folders are created using SET-
`PATH.
`
`Name header is set to folder name. This application
`procedure is applied recursively to each folder. Con-
`nect ID header is required.
`
`Set the current folder back to the
`
`parent folder using SETPATH.
`
`The Backup flag is set and no Name header is sent.
`Connect lD header is required.
`
`Table 4.4: Application layer procedure for Pushing a Folder
`
`Table -4.5 shows the application procedure for transferring a folder from the
`Server to the Client.
`
`Client
`
`Details
`
`Set the current folder to the folder
`which is to be transferred using
`SETPATH.
`
`The Name header is set to the name of the folder.
`Connect ID header is required.
`
`Pull the contents of the folder using
`GET.
`
`A Name header is not sent. and the Type Header
`must be set to the MIME-type of the Folder Listing
`Object (x-obexlfolder-listing).
`
`Pull all files to the new folder using a
`GET command for each file.
`
`The Name header is set to the name of the file. Con-
`nect ID header is required.
`
`Pull all Folders to the new folder
`
`using this application procedure.
`
`Set the current folder back to the
`
`parent folder. using SETPATH.
`
`This application procedure is applied recursively to
`each folder.
`
`The Backup flag is set and no Name header is sent.
`Connect ID header is required.
`
`Table 4.5: Application layer procedure for Pulling a Folder
`
`1 December 1999
`
`Application layer
`
`AFFLT02946B2
`
`Samsung Ex. 1119 p. 1454
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`File Transfer Profile
`
`4.4 OBJECT MANIPU LATION
`
`page 373 of 440
`
`Bluetooth
`
`A Client can delete folders and files on a Server. It can also create new folders
`
`on a Server. A brief summary of these functions is shown below.
`
`- A file is deleted by using a PUT command with the name of the file in a
`Name header and no Body header.
`
`- An empty folder is deleted by using a PUT command with the name of the
`folder in a Name header and no Body header.
`
`A non-empty folder can be deleted in the same way as an empty folder but
`Servers may not allow this operation. If a Server refuses to delete a non-
`empty folder it must return the "Precondition Fai|ed" (UXCC) response code.
`This response code tells the Client that it must first delete all the elements of
`the folder individually before deleting the folder.
`
`A new folder is created in the Server's current folder by using the SETPATH
`Command with the name of the folder in a Name header. if a folder with that
`
`name already exists. then a new folder is not created. In both cases the cur-
`rent folder is set to the new folder.
`
`Application layer
`
`1 December 1999
`
`AFFLT02946B3
`
`Samsung Ex. 1119 p. 1455
`
`

`
`BLUETOOTH SPECEFICATION Version 1.0 8
`
`page 374 of440
`
`Ffle Transfer Profile
`
`5 OB EX
`
`5.1 OBEX OPERATIONS USED
`
`'E'ahie
`profile.
`
`shows the OBEX operations. which are required in the File Transfer
`
`Table 5.1: OBEX Operations
`
`1 December 1999
`
`AFFLT02946B4
`
`Samsung Ex. 1119 p. 1456
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 375 of 440
`
`Fiie Transfer Profile
`
`5.2 OBEX HEADERS
`
`shows the specified OBEX headers, which are required in the File
`Te-tsie
`Transfer profile.
`
`Header no.
`
`OBEX Headers
`
`_L
`
`<.DO3'-~.|O')€.J1-I‘-‘-iIAJ|'\J
`
`_l (3
`
`Count
`
`Name
`
`Type
`
`Length
`
`Time
`
`Description
`
`Ta rget
`
`HTTP
`
`Body
`
`End of Body
`
`Who
`
`Connection ID
`
`Authenticate Challenge
`
`Authenticate Response
`
`Application Parameters
`
`Object Class
`
`Tabie 5. 2: OBEX Headers
`
`5.3 INITIALIZATION OF OBEX
`
`XXEEZEZZOZOOEEEO
`
`XXEEEEZZOZOOEZEO
`
`Devices implementing the File Transfer profile can optionally use OBEX authen-
`tication. The initialization procedure is defined in Senator: 5.35 of GOEP {:3}.
`
`5.4 ESTABLISHMENT OF OBEX SESSION
`
`The OBEX connection must use a Target header set to the File Browsing
`UUID, F9EC7BC4—953C-11D2-984E—525400DC9E09. This UUID is sent in
`
`binary (16 bytes) with 0xF9 sent first. OBEX authentication can optionally be
`used. This profile follows the procedures described in :'§e+r:ti:_>n 5.4 of GOEP {2}
`with the Target, Connection ID, and Who headers being mandatory.
`
`1 December 1999
`
`AFFLT02946B5
`
`Samsung Ex. 1119 p. 1457
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`page 376 of440
`
`File Transfer Profile
`
`5.5 BROWSING FOLDERS
`
`Bluetooth-
`
`Browsing folders involves pulling Folder Listing objects and setting the current
`folder. Navigating a folder hierarchy requires moving fowvard and backward by
`changing the current folder. Upon cornptetion of the OBEX Connect operation
`the Server's current folder is the root folder.
`
`5.5.1 Pulling a Folder Listing Object
`
`Pulling a Folder Listing object uses a GET operation and follows the procedure
`described in Section 5.5 of GOEP {'2}. The Connection ID and Type headers
`are mandatory. A Name header containing the name of the folder is used to
`pull the listing of a folder. Sending the GET command without a name header is
`used to pull the contents of the current folder. Typically. a folder browsing appli-
`cation will pull the contents of the current folder, so a Name header is not used.
`The Type header must be set to ‘x-obexifolder-tisting'.
`
`5.5.2 Setting the Current Folder (Forward)
`
`Setting the current folder requires the SETPATH operation. The SETPATH
`request must include the following fields and headers:
`
`Field!
`
` . Value Status Explanation
`
`
`
`
`
`.
`
`Opcode for
`SETPATH
`
`Packet Length
`
`Flags
`
`Constants
`
`Connection ID
`
`M
`
`_
`
`-
`
`‘Backup level‘ flag is set to 0 and ‘Don't
`Create’ flag is set to 1.
`
`Constants are not used, and the field
`must be set to 0.
`
`Connection ID is set to the value
`returned by the Server during the
`OBEX Connect operation. This must
`be the first header.
`
`Name of the folder.
`
`Tabie 5.3: Fields and Headers in SETPATH Request for Setting Current Foider (Forward)
`
`1 December 1999
`
`AFFLT02946B6
`
`Samsung Ex. 1119 p. 1458
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 377 of 440
`
`Fiie Transfer Profile
`
`The response packet for the SETPATH request has the following fields and
`headers:
`
`Name
`
`Response code
`for SETPATH
`
`Packet Length
`
`Explanation
`
`0xA0 for success or 0x04 if the folder
`does not exist.
`
`-
`
`Table 5.4: Fields and Headers in SE TPATH Response for Setting Current Foider (Forward)
`
`Other headers such as Description can optionally be used.
`
`5.5.3 Setting the Current Folder (Backward)
`
`Setting the current folder back to the parent folder requires the SETPATH oper-
`ation. The SETPATH request must include the following fields and headers
`(note that a Name header is not used):
`
`Name
`
`Explanation
`
`Opcode for SET-
`PATH
`
`Packet Length
`
`Flags
`
`Constants
`
`Connection ID
`
`-
`
`‘Backup level‘ flag is set to 1 and ‘Don't
`Create’ flag is set to 1.
`
`Constants are not used. and the field
`must be set to 0.
`
`Connection ID is set to the value
`returned by the Server during the
`OBEX Connect operation. This must
`be the first header.
`
`Table 5.5: Fieids and Headers in SE TPATH Request for Setting Current Folder {Backward}
`
`1 December 1999
`
`AFFLT02946B7
`
`Samsung Ex. 1119 p. 1459
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`page 378 of440
`
`Flle Transfer Profile
`
`Bluetooth-
`
`The response packet for the SETPATH request has the fotlowing fields and
`headers:
`
`Name
`
`Response code
`for SETPATH
`
`Packet Length
`
`Explanation
`
`0xA0 for success. or 0x04 if the current
`folder is the root.
`
`-
`
`Table 5.6: Fields and Headers in SETPATH Response for Setting Current Folder (Backward)
`
`Other headers, such as Description, can optionally be used.
`
`5.5.4 Setting the Current Folder (Root)
`
`Setting the current folder to the root requires the SETPATH operation. The
`SETPATH request must include the following fields and headers:
`
`Field.-'
`
`.
`
`Opcode for SET-
`PATH
`
`Packet Length
`
`Flags
`
`Constants
`
`Connection ID
`
`M
`
`_
`
`-
`
`‘Backup level‘ flag is set to 0 and ‘Don’!
`Create‘ flag is set to 1.
`
`Constants are not used. and the field
`must be set to 0.
`
`Connection ID is set to the value
`returned by the Server during the
`OEIEX Connect operation. This must
`be the first header.
`
`Name header is empty.
`
`Table 5. 7: Fields and Headers in SETPATH Request for Setting Current Folder (Root)
`
`1 December 1999
`
`AFFLT02946B8
`
`Samsung Ex. 1119 p. 1460
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 379 of 440
`
`File Transfer Profile
`
`The response packet for the SETPATH request has the following fields and
`headers:
`
`Name
`
`Response code
`for SETPATH
`
`Packet Length
`
`Explanation
`
`0xA0 for success.
`
`Table 5.8: Fields and Headers in SE TPATH Response for Setting Current Foider (Root)
`
`Other headers, such as Description, can optionally be used.
`
`5.6 PUSHING OBJECTS
`
`Pushing object involves pushing files and folders.
`
`5.6.1 Pushing Files
`
`Pushing files follows the procedure described in Eiéersfisn 5.5 of GOEP £2}. The
`Connection ID header is mandatory.
`
`5.6.2 Pushing Folders
`
`Pushing folders involves creating new folders and pushing files. It may also
`involve navigating through the folder hierarchy. Navigation is described in Sec-
`tion 5.5 on
`Pushing files is described in Secticn 5.6.1 on page
`
`1 December 1999
`
`AFFLT02946B9
`
`Samsung Ex. 1119 p. 1461
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`Fiie Transfer Proiiie
`
`5. 6. 2.1 Creating New Foiders
`
`page 380 of440
`
`Bluetooth-
`
`Creating a new folder requires the SETPATH operation. The SETPATH request
`must include the following fields and headers:
`
`Name
`
`Explanation
`
`Opccde for SET-
`PATH
`
`Packet Length
`
`Flags
`
`Constants
`
`Connection ID
`
`‘Backup level‘ flag is set to U and ‘Don’t
`Create‘ flag is set to 0.
`
`Constants are not used, and the field
`must be set to 0.
`
`Connection ID is set to the value
`returned by the Server during the
`OBEX Connect operation. This must
`be the first header.
`
`Name of the folder.
`
`Table 5.9: Fieids and Headers in SETPATH Request for Creating a Foider.
`
`The response packet for the SETPATH request has the following fields and
`headers:
`
`new
`Header
`
`Ex lanation
`9
`
`Response code
`for SETPATH
`
`UXAO for success or UXC1 if the current
`folder is read only and creation of a new
`folder is unauthorized.
`
`Packet Length
`
`-
`
`Tabie 5.10: Fields and Headers in SETPATH Response for Creating a Foider
`
`Other headers such as Description can optionally be used.
`
`1 December 1999
`
`AFFLT0294690
`
`Samsung Ex. 1119 p. 1462
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`File Transfer Profile
`
`5.7 PULLING OBJECTS
`
`Pulling objects involves pulling files and folders.
`
`5.7.1 Pulling Files
`
`page 381 of 440
`
`Bluetooth.
`
`Pulling files follows the procedure described in Sectéor:
`Connect ID header is mandatory.
`
`of GOEP
`
`The
`
`5.7.2 Pulling Folders
`
`Pulling folders involves navigating the folder hierarchy, pulling folder listing
`objects and pulling files. Navigating the folder hierarchy and pulling folder list-
`ing-objects is described in Secties
`en page
`Pulling files is described in
`Sestiert :'}.?.l on {tags 381.
`
`5.8 MANIPULATING OBJECTS
`
`Manipulating objects includes deleting objects and creating new folders. Creat-
`ing new folders is described in Séectiruh
`on page 35:}, Creating New
`Folders. Deleting objects involves deleting files and folders.
`
`5.8.1 Deleting Files
`
`Deleting a file requires the PUT operation. The PUT request must include the
`following fields and headers (note that no Body or End Body headers are sent):
`
`Opcode for PUT
`
`Packet Length
`
`ConnectionID
`
`Connection ID is set to the value
`returned by the Server during the
`OBEX Connect operation. This must
`be the first header.
`
`The header value is the name of the
`
`obieot to delete.
`
`Table 5.11: Fields and Headers in PUT Request for Delete
`
`1 December 1999
`
`AFFLT0294891
`
`Samsung Ex. 1119 p. 1463
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`File Transfer Profile
`
`page 382 of440
`
`Bluetooth-
`
`The response packet for the PUT request has the following fields and headers:
`
`Field;
`Header
`
`Field
`
`Response code
`for PUT
`
`0:-(A0,
`OXC1 or
`OXC4
`
`Packet Length
`
`Varies
`
`Ex lanation
`9
`
`0xA0 for success. UXC1 for unautho-
`rized (e.g. read only} or 0}-(C4 if the file
`does not exist.
`
`Table 5.12: Fields and Headers in PUT Response for Delete
`
`Other headers such as Description can optionally be used.
`
`5.8.2 Deleting Folders
`
`A folder can be deleted using the same procedure used to delete a file (see
`Sectien
`on
`331). Deleting a non-empty folder will delete all its con-
`tents, including other folders. Some Servers may not allow this operation and
`will return the “Preeondition Failed" (OXCC) response code. indicating that the
`folder is not empty. In this case the Client will need to delete the contents
`before deleting the folder.
`
`5.9 DISCONNECTION
`
`See Sectisn 5-3."? in GOEP E2}.
`
`1 December 1999
`
`AFFLT0294892
`
`Samsung Ex. 1119 p. 1464
`
`

`
`BLUETOOTH SPE