BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 331 of 1082
`
`Service Discovery Protocol‘
`
`SDP involves communication between an SDP server and an SDP client. The
`server maintains a list of service records that describe the characteristics of
`services associated with the server. Each service record contains information
`
`about a single service. A client may retrieve information from a service record
`maintained by the SDP server by issuing an SDP request.
`
`if the client, or an application associated with the client, decides to use a ser-
`vice, it must open a separate connection to the service provider in order to uti-
`lize the service. SDP provides a mechanism for discovering services and their
`attributes (including associated service access protocols). but it does not pro-
`vide a mechanism for utilizing those services (such as delivering the service
`access protocols).
`
`There is a maximum of one SDP server per Bluetooth device. (If a Bluetooth
`device acts only as a client, it needs no SDP server.) A single Bluetooth device
`may function both as an SDP server and as an SDP client. If multiple applica-
`tions on a device provide services, an SDP server may act on behalf of those
`service providers to handle requests for information about the services that
`they provide.
`
`Similarly, multiple client applications may utilize an SDP client to query servers
`on behalf of the client applications.
`
`The set of SDP servers that are available to an SDP client can change dynam-
`ically based on the RF proximity of the servers to the client. When a server
`becomes available, a potential client must be notified by a means other than
`SDP so that the client can use SDP to query the server about its services. Sim-
`ilarly. when a server leaves proximity or becomes unavailable for any reason.
`there is no explicit notification via the service discovery protocol. However, the
`client may use SDP to poll the server and may infer that the server is not avail-
`able if it no longer responds to requests.
`
`Additional information regarding application interaction with SDP is contained
`in the Bluetooth Service Discovery Profile document.
`
`29 November 1999
`
`AFFLT0293559
`
`Samsung Ex. 1019 p. 331
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`Service Discovery Protocoi
`
`2.2 SERVICE RECORD
`
`page 332 of H382
`
`Bluetooth.
`
`A service is any entity that can provide information, perform an action, or con-
`trol a resource on behaif of another entity. A service may be implemented as
`software. hardware, or a combination of hardware and software.
`
`All of the information about a service that is maintained by an SDP server is
`contained within a single service record. The service record consists entirely of
`a list of service attributes.
`
`Service Record
`
`Service Attribute 1
`
`Service Attribute 2
`
`Service Attribute 3
`
`Service Attribute N
`
`Figure 2.3: Service Record
`
`A service record handle is a 32-bit number that uniquely identifies each service
`record within an SDP server. It is important to note that, in general, each han-
`dle is unique only within each SDP server. If SDP server 81 and SDP server
`S2 both contain identical senrice records (representing the same senrice), the
`service record handles used to reference these identical service records are
`
`completely independent. The handle used to reference the service on S1 will
`be meaningless if presented to S2.
`
`The service discovery protocol does not provide a mechanism for notifying cli-
`ents when service records are added to or removed from an SDP server.
`
`While an L2CAP (Logical Link Control and Adaptation Protocol) connection is
`established to a server, a service record handle acquired from the server will
`remain valid unless the service record it represents is removed.
`If a service is
`removed from the server, further requests to the server (during the L2CAP con»
`nection in which the service record handle was acquired) using the services
`(now stale) record handle will result in an error response indicating an invalid
`service record handle. An SDP server must ensure that no service record han-
`dle values are re-used while an L2CAP connection remains estabiished. Note
`that service record handles are known to remain valid across successive
`L2CAP connections while the ServiceDatabaseState attribute value remains
`
`unchanged. See the ServiceRecordState and ServiceDatabaseState attributes
`in Section ti Service Attribute iieiinitéons on page
`
`There is one service record handle whose meaning is consistent across all
`SDP servers. This service record handle has the value 0x00000000 and is a
`
`29 November 1999
`
`Overview
`
`AFFLT0293560
`
`Samsung Ex. 1019 p. 332
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 333 of 1082
`
`Service Discovery Protocol
`
`Bluetooth.
`
`handle to the service record that represents the SDP server itself. This service
`record contains attributes for the SDP server and the protocol it supports. For
`exampie, one of its attributes is the list of SDP protocol versions supported by
`the server. Service record handle values 0x00000001-OXOOOOFFFF are
`reserved.
`
`29 November 1999
`
`AFFLT0293561
`
`Samsung Ex. 1019 p. 333
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`Service Discovery Protocol
`
`2.3 SERVICE ATTRIBUTE
`
`page 334 of €032
`
`Bluetooth-
`
`Each service attribute describes a single characteristic of a service. Some
`examples of service attributes are:
`
`ServiceC|assiD List
`
`Identities the type of service represented by a service record.
`In other words, the list of classes of which the service is an
`instance
`
`Se rvicel D
`
`Uniquely identifies a specific instance of a service
`
`Protoco|DescrlptorList
`
`Specifies the protocol stacl<(s) that may be used to utilize a
`service
`
`ProviderName
`
`|conURL
`
`Servicetslame
`
`The textual name of the individual or organization that pro-
`vides a service
`
`Specifies a URL that refers to an icon image that may be
`used to represent a service
`
`A text string containing a human-readable name for the ser-
`vice
`
`Serviceflescrlptiori
`
`A text string describing the service
`
`See Eéerstiran 5.’? Lirmrersai Attribute t3etin'a=‘.':cns ore. page 358, for attribute defini-
`tions that are common to all service records. Service providers can also define
`their own service attributes.
`
`A service attribute consists of two components: an attribute ID and an attribute
`value.
`
`Service Attribute
`
`Attribute ID
`
`Attribute Value
`
`Figure 2.4: Service Attribute
`
`29 November 1999
`
`AFFLT0293562
`
`Samsung Ex. 1019 p. 334
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 335 of 1082
`
`Service Discovery Protocol‘
`
`2.4 ATTRIBUTE ID
`
`An attribute ID is a 16-bit unsigned integer that distinguishes each service
`attribute from other service attributes within a service record. The attribute ID
`also identifies the semantims of the associated attribute value.
`
`A service class definition specifies each of the attribute IDs for a service class
`and assigns a meaning to the attribute value associated with each attribute ID.
`
`For example. assume that service class C specifies that the attribute value
`associated with attribute ID 12345 is a text string containing the date the ser-
`vice was created. Assume further that service A is an instance of service class
`C. If service A's service record contains a service attribute with an attribute ID
`
`of 12345, the attribute value must be a text string containing the date that ser-
`vice A was created. However, services that are not instances of service class C
`
`may assign a different meaning to attribute ID 12345.
`
`All services belonging to a given service class assign the same meaning to
`each particular attribute ID. See ESe-cticn
`Seririce
`page
`
`In the Service Discovery Protocol, an attribute ID is often represented as a data
`element. See Section 3
`Representation on page 341.
`
`Type
`
`Size Index
`
`I-II
`<—5—H—3—i>1j1Ber
`
`Figure 2.5:
`
`2.5 ATTRIBUTE VALUE
`
`The attribute value is a variable length field whose meaning is determined by
`the attribute ID associated with it and by the service class of the service record
`in which the attribute is contained. In the Service Discovery Protocol, an
`attribute value is represented as a data element. (See Section 3 Data Repre-
`seawtation on page 34?.) Generally. any type of data element is permitted as an
`attribute value, subject to the constraints specified in the service class defini-
`tion that assigns an attribute ID to the attribute and assigns a meaning to the
`attribute value. See Section
`Servi:.:e Attribute iltetinitiorzs on page 358, for
`attribute value examples.
`
`29 November 1999
`
`AFFLT0293563
`
`Samsung Ex. 1019 p. 335
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`Service Discovery Protocol‘
`
`2.6 SERVICE CLASS
`
`page 336 of
`
`Bluetooth-
`
`Each service is an instance of a service class. The service class definition pro-
`vides the definitions of all attributes contained in service records that represent
`instances of that class. Each attribute definition specifies the numeric value of
`the attribute ID, the intended use of the attribute value, and the format of the
`attribute value. A service record contains attributes that are specific to a ser-
`vice class as well as universal attributes that are common to all services.
`
`Each service class is also assigned a unique identifier. This service class iden-
`tifier is contained in the attribute value for the ServiceC|asslDList attribute, and
`is represented as a UUID (see Section 2.7.‘? iititfi on
`33?). Since the for-
`mat and meanings of many attributes in a service record are dependent on the
`service class of the service record, the ServiceC|ass|DList attribute is very
`important. Its value should be examined or verified before any class-specific
`attributes are used. Since all of the attributes in a service record must conform
`
`to all of the service’s classes, the service class identifiers contained in the Ser-
`
`viceC|asslDList attribute are related. Typically, each service class is a subclass
`of another class whose identifier is contained in the list. A service subclass def-
`
`inition differs from its superclass in that the subclass contains additional
`attribute definitions that are specific to the subclass. The service class identifi-
`ers in the ServiceC|ass|DList attribute are listed in order from the most specific
`class to the most general class.
`
`When a new service ciass is defined that is a subclass of an existing service
`class, the new service class retains all of the attributes defined in its super-
`class. Additional attributes will be defined that are specific to the new service
`class. In other words, the mechanism for adding new attributes to some of the
`instances of an existing service class is to create a new service class that is a
`subclass of the existing service class.
`
`2.6.1 A Printer Service Class Example
`
`A color postscript printer with duplex capability might conform to 4 Service-
`Class definitions and have a ServiceC|ass|DList with UU|Ds (See SE‘rGI.EDi'i 23".’:
`Ut.iit') en page 33?.) representing the following Serviceclasses:
`
`DuplexCo|orPostscriptPrinterServiceC|ass|D,
`Co|orPostscriptPrinterServiceC|assID,
`PostscriptPrinterServiceC|ass|D,
`PrinterServiceC|ass|D
`
`Note that this example is only illustrative. This may not be a practical printer
`class hierarchy.
`
`29 November 1999
`
`Overview
`
`AFFLT0293564
`
`Samsung Ex. 1019 p. 336
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 337 of 1082
`
`Service Discovery Protocol‘
`
`2.7 SEARCHING FOR SERVICES
`
`Once an SDP client has a service record handle. it may easily request the val-
`ues of specific attributes, but how does a client initially acquire a service record
`handle for the desired service records? The Service Search transaction allows
`
`a client to retrieve the service record handles for particular service records
`based on the values of attributes contained within those service records.
`
`The capability search for service records based on the values of arbitrary
`attributes is not provided. Rather, the capability is provided to search only for
`attributes whose values are Universally Unique Identifiers‘ (UU|Ds). Important
`attributes of services that can be used to search for a service are represented
`as UU|Ds.
`
`2.7.1 UUID
`
`A UUID is a universally unique identifier that is guaranteed to be unique across
`all space and all time. UUIDs can be independently created in a distributed
`fashion. No central registry of assigned UUIDs is required. A UUID is a 128-bit
`value.
`
`To reduce the burden of storing and transferring 128-bit UUID values, a range
`of UUID values has been pre-allocated for assignment to often-used, regis-
`tered purposes. The first UUID in this pre-allocated range is known as the
`Bluetooth Base UUID and has the value 00000000-0000-1000-700$
`
`0O805F9B34FB, from the Bluetooth Assigned Numbers document. UUID val-
`ues in the pre-allocated range have aliases that are represented as 16-bit or
`32-bit values. These aliases are often called 16-bit and 32-bit UU|Ds, but it is
`important to note that each actually represents a 128-bit UUID value.
`
`The full 128-bit value of a 16-bit or 32-bit UUID may be computed by a simple
`arithmetic operation.
`
`128_bit_va|ue = 16_bit_va|ue * 295 + B|uetooth_Base_UUID
`
`128_bit_va|ue = 32_bit_va|ue * 295 + B|uetooth_Base_UUID
`
`A 16-bit UUID may be converted to 32-bit UUID format by zero-extending the
`16-bit value to 32-bits. An equivalent method is to add the 16-bit UUID value to
`a zero-valued 32-bit UUID.
`
`Note that two 16-bit UUlDs may be compared directiy, as may two 32-bit
`UU|Ds or two 128-bit UUlDs. If two UUlDs of differing sizes are to be com-
`pared. the shorter UUID must be converted to the longer UUID format before
`comparison.
`
`1. The format of UUIDs is defined by the International Organization for Standardization in ISO!
`IEC 1157821996. ''Information technology— Open Systems Interconnection - Remote Proce-
`dure Call {RPC)"
`
`Overview
`
`29 November 1999
`
`AFFLT0293565
`
`Samsung Ex. 1019 p. 337
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`Service Discovery Protocol‘
`
`2.7.2 Service Search Patterns
`
`page 338 of
`
`Bluetooth-
`
`A service search pattern is a list of UU|Ds used to locate matching service
`records. A service search pattern is said to match a service record if each and
`every UUID in the service search pattern is contained within any of the service
`record's attribute values. The UU|Ds need not be contained within any specific
`attributes or in any particular order within the service record. The service
`search pattern matches if the UUIDs it contains constitute a subset of the
`UU|Ds in the service record's attribute values. The only time a service search
`pattern does not match a service record is if the service search pattern con-
`tains at least one UUID that is not contained within the service record's
`
`attribute values. Note also that a valid service search pattern must contain at
`least one UUID.
`
`2.8 BROWSING FOR SERVICES
`
`Normally, a client searches for services based on some desired characteris-
`tic(s) (represented by a UUID) of the services. However, there are times when
`it is desirable to discover which types of services are described by an SDP
`server's service records without any a priori information about the services.
`This process of looking for any offered services is termed browsing. In SDP, the
`mechanism for browsing for services is based on an attribute shared by all ser-
`vice classes. This attribute is called the BrowseGroupList attribute. The value
`of this attribute contains a list of UUIDS. Each UUID represents a browse group
`with which a service may be associated for the purpose of browsing.
`
`When a client desires to browse an SDP server’s services, it creates a service
`search pattern containing the UUID that represents the root browse group. All
`services that may be browsed at the top level are made members of the root
`browse group by having the root browse group's UUID as a value within the
`BrowseGroupList attribute.
`
`Normally, if an SDP server has relatively few services, all of its services will be
`placed in the root browse group. However, the services offered by an SDP
`server may be organized in a browse group hierarchy, by defining additional
`browse groups below the root browse group. Each of these additional browse
`groups is described by a service record with a service class of
`BrowseGroupDescriptor.
`
`A browse group descriptor service record defines a new browse group by
`means of its Group ID attribute. In order for a service contained in one of these
`newly defined browse groups to be browseable, the browse group descriptor
`service record that defines the new browse group must in turn be browseable.
`The hierarchy of browseable services that is provided by the use of browse
`group descriptor service records allows the services contained in an SDP
`server to be incrementally browsed and is particularly useful when the SDP
`server contains many service records.
`
`29 November 1999
`
`Overview
`
`AFFLT0293566
`
`Samsung Ex. 1019 p. 338
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`Service Discovery Protocol
`
`2.8.1 Example Service Browsing Hierarchy
`
`page 339 of 1082
`
`Bluetooth.
`
`Here is a fictitious service browsing hierarchy that may illuminate the manner in
`which browse group descriptors are used. Browse group descriptor service
`records are identified with (G); other service records with (S).
`
`Pubiic Browse R oot
`
`| Eniertainmeni(G)
`
`|
`
`Games (G)
`L
`Btarcraft (S) l
`
`Movies ((3)
`I
`| ABug's Life (3) l
`
`i News(G)
`‘
`| Dictionaryl (S)
`
`R efere nce (G)
`
`‘
`
`i Encyc|ope1:|iaX(S)
`
`|
`
`New York Times (8)
`
`Local N ewsp aper (S)
`
`London Times (3)
`
`Figure 2.6:
`
`This table shows the services records and service attributes necessary to
`implement the browse hierarchy.
`
`Service Name
`
`Service Class
`
`Attribute Name
`
`Attribute Value
`
`Entertainment
`
`BrowseGroupDescri'ptor
`
`BrowseGroupL'
`
`Browseg roupDescriptor
`
`BrowseGroupL'
`
`GrouplD
`
`Pub|icBrowseRoot
`
`Entertainmentlfl
`
`Pub|icBrowseRoot
`
`Reference
`
`BrowseG rou pDescr1ptor
`
`BrowseGroupL’
`
`Pub|icBrowseRoot
`
`GroupID
`
`News|D
`
`GrouplD
`
`BrowseGroupDescriptor
`
`BrowseGroupL'
`
`Group|D
`
`BrowseGroupDescriptor
`
`BrowseGroupL’
`
`Video Game Class ID
`
`BrowseGroupL'
`
`GroLiplD
`
`Reference|D
`
`Entertainment|D
`
`GamesID
`
`Entertainment|D
`
`MoviesiD
`
`GameslD
`
`29 November 1999
`
`AFFLT0293567
`
`Samsung Ex. 1019 p. 339
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`Service Discovery Protocol
`
`page 340 of €832
`
`Bluetooth-
`
`A Bug's Life
`
`Dictionary Z
`
`Movie Class ID
`
`BrowseGroupList
`
`Dictionary Class ID
`
`BrowseGroupi_:'st
`
`Encyclopedia X
`
`Encyclopedia Class ID
`
`BrowseGroupList
`
`MovielD
`
`ReferenceID
`
`ReferenceID
`
`New York Times
`
`London Times
`
`Newspaper ID
`
`Newspaper ID
`
`BrowseGrcupList
`
`NewspaperID
`
`BrowseGroupl.ist
`
`NewspaperiD
`
`Local Newspaper
`
`Newspaper ID
`
`BrowseGroupList
`
`NewspaperID
`
`Tabie 2.1:
`
`29 November ‘I999
`
`AFFLT029356B
`
`Samsung Ex. 1019 p. 340
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 341 of 1082
`
`Service Discovery Protocol
`
`3 DATA REPRESENTATION
`
`Attribute values can contain information of various types with arbitrary com-
`plexity; thus enabling an attribute list to be generally useful across a wide vari-
`ety of service classes and environments.
`
`SDP defines a simple mechanism to describe the data contained within an
`attribute value. The primitive construct used is the data element.
`
`3.1 DATA ELEMENT
`
`A data element is a typed data representation. It consists of two fields: a
`header field and a data field. The header field, in turn, is composed of two
`parts: a type descriptor and a size descriptor. The data is a sequence of bytes
`whose length is specified in the size descriptor (described in Section 3.3 Data
`Eiiement Sfiizs iiéescriptcir on page fist?) and whose meaning is (partially) speci-
`fied by the type descriptor.
`
`3.2 DATA ELEMENT TYPE DESCRIPTOR
`
`A data element type is represented as a 5-bit type descriptor. The type descrip-
`tor is contained in the most significant (high-order) 5 bits of the first byte of the
`data element header. The following types have been defined.
`
`Type
`Descriptor
`Value
`
`Valid Size
`Descriptor
`Values
`
`Type Description
`
`Nil. the null type
`
`Unsigned Integer
`
`Signed twos-complement integer
`
`UUID. a universally unique identifier
`
`Text string
`
`Boolean
`
`Data element sequence. a data element whose data field
`is a sequence of data elements
`
`Data element alternative, data element whose data field is
`a sequence of data elements from which one data ele-
`ment is to be selected.
`
`URL. a uniform resource locator
`
`Reserved
`
`Data Representation
`
`29 November 1999
`
`AFFLT0293569
`
`Samsung Ex. 1019 p. 341
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`page 342 of €832
`
`Service Discovery Protocol
`
`3.3 DATA ELEMENT SIZE DESCRIPTOR
`
`The data element size descriptor is represented as a 3-bit size index followed
`by O, 8. 16, or 32 bits. The size index is contained in the least significant (low-
`order) 3 bits of the first byte of the data element header. The size index is
`encoded as follows.
`
`Additional
`bits
`
`1 byte. Exception: if the data eiement type is nil, the data size is 0
`bytes.
`
`2 bytes
`
`4 bytes
`
`8 bytes
`
`16 bytes
`
`The data size is contained in the additional 8 bits. which are inter-
`preted as an unsigned integer.
`
`The data size is contained in the additional 16 bits. which are
`interpreted as an unsigned integer.
`
`The data size is contained in the additional 32 bits, which are
`interpreted as an unsigned integer.
`
`29 November 1999
`
`Data Representation
`
`AFFLT0293570
`
`Samsung Ex. 1019 p. 342
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 343 of 1082
`
`Service Discovery Protocol
`
`3.4 DATA ELEMENT EXAMPLES
`
`Nil is represented as:
`
`Type
`
`Size Index
`
`6%
`
`1—5—N-3-D
`
`A 16-bit signed integer is represented as:
`
`Type
`
`Size Index
`
`16«bit data value
`1
`2
`4—5—M—3—>4j16en
`
`he 3 character ASCII string "Hat" is represented as:
`
`Type Size Index
`
`Size
`
`E21
`
`Figure 3.1:
`
`Data Representation
`
`29 November 1999
`
`AFFLT0293571
`
`Samsung Ex. 1019 p. 343
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`Service Discovery Protocol‘
`
`4 PROTOCOL DESCRIPTION
`
`page 344 of
`
`Bluetooth-
`
`SDP is a simple protocol with minimal requirements on the underlying trans-
`port. It can function over a reliable packet transport (or even unreliable, if the
`client implements timeouts and repeats requests as necessary).
`
`SDP uses a requestiresponse model where each transaction consists of one
`request protocol data unit (PDU) and one response PDU. However, the
`requests may potentially be pipelined and responses may potentially be
`returned out of order.
`
`In the specific case where SDP utilises the Bluetooth L2CAP transport proto-
`col, multiple SDP PDUS may be sent in a single LZCAP packet, but only one
`LZCAP packet per connection to a given SDP server may be outstanding at a
`given instant. Limiting SDP to sending one unacknowledged packet provides a
`simple form of fiow control.
`
`Eixarrapie ESELEP 'i'rarssactions,
`The protocol examples found in ;‘-‘qzrpertriix E3
`may be helpful in understanding the protocol transactions.
`
`4.1 TRANSFER BYTE ORDER
`
`The service discovery protocol transfers multiple-byte fields in standard net-
`work byte order (Big Endian), with more significant (high-order) bytes being
`transferred before less-significant (low-order) bytes.
`
`4.2 PROTOCOL DATA UNIT FORMAT
`
`Every SDP PDU consists of a PDU header foliowed by PDU-specific parame-
`ters. The header contains three fields: a PDU ID. a Transaction iD, and a
`ParameterLength. Each of these header fields is described here. Parameters
`may include a continuation state parameter, described below; PDU-specific
`parameters for each PDU type are described later in separate PDU descrip-
`tions.
`
`PDU Format:
`
`Header:
`
`PDU ID
`
`Transaction ID
`
`ParameterLength
`
`4-1 byte—Hj2 bytes—>4j2 bytes—>
`
`4eParameterLength byteseb
`
`Figure 4.1:
`
`29 November 1999
`
`Protocol Description
`
`AFFLT0293572
`
`Samsung Ex. 1019 p. 344
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`Service Discovery Protocoi
`
`page 345 of 1082
`
`Bluetooth.
`
`Size: 1' Byte
`
`N
`
`0x00
`
`0x01
`
`0x02
`
`0x03
`
`0x04
`
`0x05
`
`0x06
`
`OX0?
`
`Parameter Description
`
`The PDU ID field identifies the type of PDU. i.e. its meaning and the
`specific parameters.
`
`Reserved
`
`SDP_ErrorResponse
`
`SDP_ServiceSearchRequest
`
`SDF'_ServiceSearchResponse
`
`SDP_ServiceAttributeRequest
`
`SDPmserviceAttributeResponse
`
`SDP_ServiceSearchAttributeRequest
`
`SDP_ServiceSearchAttributeResponse
`
`OX0?-OXFF
`
`Reserved
`
`TransactioniD.'
`
`Size: 2 Bytes
`
`Parameter Description
`
`The Transactioniili field uniquely identifies request PDUs and is used to
`match response PDUs to request PDUs. The SDP client can choose
`any vaiue for a request's Transaction1D provided that it is different from
`all outstanding requests. The TransactioniD vaiue in response PDUs is
`required to be the same as the request that is being responded to.
`Range: OXUUUU — OXFFFF
`
`ParameterLength.'
`
`Size: 2 Bytes
`
`Parameter Description
`
`The PararneterLength field specifies the iength (in bytes) of all parame-
`ters contained in the PDU.
`
`Range: oxcooo — OXFFFF
`
`Protocol Description
`
`29 November 1999
`
`AFFLT0293573
`
`Samsung Ex. 1019 p. 345
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`page 346 of €882
`
`Service Discovery Protocol‘
`
`Bluetooth-
`
`4.3 PARTIAL RESPONSES AND CONTINUATION STATE
`
`Some SDP requests may require responses that are larger than can fit in a sin-
`gle response PDU. In this case, the SDP server will generate a partial
`response along with a continuation state parameter. The continuation state
`parameter can be supplied by the client in a subsequent request to retrieve the
`next portion of the complete response. The continuation state parameter is a
`variable length field whose first byte contains the number of additional bytes of
`continuation information in the field. The format of the continuation information
`
`is not standardized among SDP servers. Each continuation state parameter is
`meaningful only to the SDP Server that generated it.
`
`lnfoLength
`
`Continuation Information
`
`¢—1 byte—M—lnfoLength bytes—v
`
`Figure 4. 2: Continuation State Fonnat
`
`After a client receives a partial response and the accompanying continuation
`state parameter, it can re-issue the original request (with a new transaction ID)
`and include the continuation state in the new request indicating to the server
`that the remainder of the original response is desired. The maximum allowable
`value of the |nfoLength field is 16 (0x10).
`
`Note that an SDP server can split a response at any arbitrary boundary when it
`generates a partial response. The SDP server may select the boundary based
`on the contents of the reply, but is not required to do so.
`
`4.4 ERROR HANDLING
`
`Each transaction consists of a request and a response PDU. Generally, each
`type of request PDU has a corresponding type of response PDU. However, if
`the server determines that a request is improperly formatted or for any reason
`the server cannot respond with the appropriate PDU type, it will respond with
`an SDP_ErrorResponse PDU.
`
`Any Request
`
`SDP_ErrorResponse
`
`Figure 4.3:
`
`29 November 1999
`
`Protocol Description
`
`AFFLT0293574
`
`Samsung Ex. 1019 p. 346
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 347 of 1082
`
`Service Discovery Protocol
`
`4.4.1 SDP_ErrorResponse PDU
`
`PDU Type
`
`SDP_ErrorResponse
`
`Description:
`
`Parameters
`
`ErrorCode.
`Errorlnfo
`
`The SDP server generates this PDU type in response to an improperly format-
`ted request PDU or when the SDP server, for whatever reason. cannot gener-
`ate an appropriate response PDU.
`
`PDU Parameters:
`
`ErrorCoo‘e:
`
`Size: 2 Bytes
`
`Parameter Description
`
`The Errorcode identifies the reason that an SDP_ErrorResponse PDU
`was generated.
`
`0340000
`
`OXOOO1
`
`0x0002
`
`0x0003
`
`GXOOO4
`
`Ox0005
`
`0x0006
`
`Reserved
`
`lnvalidiunsupported SDP version
`
`Invalid Service Record Handle
`
`Invalid request syntax
`
`Invalid PDU Size
`
`Invalid Continuation State
`
`Insufficient Resources to satisfy Request
`
`0x000?-0xFF FF
`
`Reserved
`
`Errori'm°o.'
`
`Error-specific
`
`Size.‘ N Bytes
`
`Parameter Description
`
`Errorlnfo is an Errorcode-specific parameter. Its interpretation depends
`on the ErrorCode parameter. The currently defined Errorcode values do
`not specify the format of an Errorlnfo field.
`
`Protocol Description
`
`29 November 1999
`
`AFFLT0293575
`
`Samsung Ex. 1019 p. 347
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`Service Discovery Protocoi
`
`4.5 SERVICESEARCH TRANSACTION
`
`page 348 of €832
`
`Bluetooth-
`
`SDP_ServiceSearch Reque
`
`SDP_ServiceSearchRespon
`
`Figure 4.4:
`
`4.5.1 SDP_ServiceSearchRequest PDU
`
`PDU Type
`
`Parameters
`
`SDP_ServiceSearchRequest
`
`ServiceSearchPattern.
`MaximumServiceRecordCount.
`Continuaticnstate
`
`Description:
`
`The SDP client generates an SDP_ServiceSearchRequest to locate service
`records that match the service search pattern given as the first parameter of
`the PDU. Upon receipt of this request, the SDP server will examine its service
`record data base and return an SDP_ServiceSearchResponse containing the
`service record handles of service records that match the given service search
`pattern.
`
`Note that no mechanism is provided to request information for all service
`records. However, see ffsecrtirst
`E:3rcv.=s%n-gt; for £3;~'arvie-es on page
`for a
`description of a mechanism that permits browsing for non-specific services
`without a priori knowledge of the services.
`
`PDU Parameters:
`
`ServiceSearchPattern:
`
`Size: Varies
`
`_ Parameter Description
`Data Element
`The ServiceSearchPattern is a data element sequence where each ele-
`Sequence
`ment in the sequence is a UUID. The sequence must contain at least
`one UUiD. The maximum number of UU|Ds in the sequence is 12'. The
`list of UU|Ds constitutes a service search pattern.
`
`*. The value of 12 has been selected as a compromise between the scope of a service
`search and the size of a search request PDU. It is not expected that more than 12
`UUIDS will be useful in a service search pattern.
`
`29 November 1999
`
`Protocol Description
`
`AFFLT0293576
`
`Samsung Ex. 1019 p. 348
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 349 of 1082
`
`Service Discovery Protocol‘
`
`MaximumServiceRe coro‘Count.'
`
`Parameter Description
`
`Bluetooth.
`
`Size: 2 Bytes
`
`MaximumServiceRecordCount is a 16-bit count specifying the maximum
`number of service record handles to be returned in the response(s} to
`this request. The SDP server should not return more handles than this
`value specifies. If more than N service reoords match the request. the
`SDP server determines which matching service reoord handles to return
`in the responsets).
`Range: UXUUU1-UXFFFF
`
`Continuationstate:
`
`Size: 1 to 17 Bytes
`
`Continuation
`State
`
`Parameter Description
`
`Continuationstate consists of an 8-bit count, N. of the number of bytes
`of continuation state information, followed by the N bytes of continua-
`tion state information that were returned in a previous response from
`the server. N is required to be less than or equal to 16. If no continua-
`tion state is to be provided in the request, N is set to 0.
`
`4.5.2 SDP_ServiceSearchResponse PDU
`
`PDU Type
`
`Parameters
`
`SD P__Se rviceSea rch Response
`
`Tota|ServiceRecordCount,
`CurrentServiceRecordCount.
`ServiceRecordHandleList,
`Continuationstate
`
`Description:
`
`The SDP server generates an SDP_ServiceSearchResponse upon receipt of a
`valid SDP_ServiceSearchRequest. The response contains a list of service
`record handles for service records that match the service search pattern given
`in the request. Note that if a partial response is generated, it must contain an
`integral number of complete service record handles; a service record handle
`value may not be split across multiple PDUs.
`
`Protocol Description
`
`29 November 1999
`
`AFFLT0293577
`
`Samsung Ex. 1019 p. 349
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`Service Discovery Protocol
`
`PDU Parameters:
`
`TotaiServr'ceRecordCount.'
`
`page 350 of €032
`
`Bluetooth-
`
`Size: 2 Bytes
`
`Parameter Description
`
`The ‘l'otalServiceRecordCount is an integer containing the number of
`service records that match the requested service search pattern. if no
`service records match the requested service search pattern. this param-
`eter is set to 0. N should never be larger than the MaximumServiceRe-
`cordCount value specified in the SDP_ServiceSearchRequest. When
`multiple partial responses are used. each partial response contains the
`same value for TotalServiceReoordCount.
`
`Range: UXUUUU-DXFFFF
`
`C urrentSe rvice Re cordCo un 1‘:
`
`Size: 2 Bytes
`
`Parameter Description
`
`The CurrenlServiceRecordCount is an Integer indicating the number of
`service record handles that are contained in the next parameter. If no
`service records match the requested service search pattern. this param-
`eter is set to 0. N should never be larger than the ToialServiceRecord-
`Count value specified in the current response.
`
`Range: 0x0000~0xFFFF
`
`Sen/iceRecon:iHandiei_ist.'
`
`Size: (currentsenziceRecordCount*4) Bytes
`
`List of
`32-bit handles
`
`Parameter Description
`
`The ServiceRecordHand|eList contains a list of service record handles.
`The number of handles in the list is given in the CurrentServiceRecorcl-
`Count parameter. Each of the handles in the Eist refers to a service
`r