throbber
BLUETOOTH SPECIFICATION Version 1.0 8
`
`page 496 of1082
`
`Jnteroperabflfty Requirements for Biue-tooth as a WAP Bearer
`
`uetooth-
`
`29 November 1999
`
`AFFLT0293724
`
`Samsung Ex. 1019 p. 496
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 497 of 1082
`
`Inreroperabiffljx Requirements for Biuetooth as a WAP Bearer
`
`uetouth.
`
`CONTENTS
`
`immsziuction ..................................................................................... "$99
`
`1.’! Documantficope
`
`The Use sf WA?’ in the Eiuatouth Environment .......................... "599
`
`2.1
`
`2.2
`
`‘JaIue—.a:*£dedServices..............................................................5OG
`
`Usage: Cases
`
`2.2.2 Fhrbidden
`2.2.3 WAP Smart Kiosk ...................................................... .59!
`
`Wk? Services Gvrewiew ................................................................ ".552
`
`3.‘?
`
`‘1s’*JAP §':".r':iiiia-‘BS ..........................................................................
`3.3.1
`“.:"J'.«5.F* Ciieni ................................................................ ..5{}2
`
`3.3.2 WAF3 §’rc»xyfGateway ................................................. .1393
`13-.’§.3
`\.;‘.*‘.£‘sP Server ...............................................................
`
`WA?“ é”->ram>r;9Es ....................................................................... . .503
`
`3.2.‘: Wireless: Datagrarn F‘a'o?ocr;i (W'CJP} .......................... ..504
`
`3.2.2 Wéreaiess Transaction Protocoi {WT§=‘)
`
`.
`
`......5£}-«3
`
`3.2.3 Wireiess ?ra:“=:=..;302"3; §..aye.=r Se.-*.".=.;rit3,«' {‘v‘~.r‘TL8}
`
`3.2.4 Wireiess Session £'~=mé.acoi‘
`
`Coratrasténg WAP amt; interwar: F>ro:;:3cr.>!s ...............................
`3.3.1
`Ui":>P.=’WE3F’ ................................................................. ..
`
`9*’ .9-3 M
`
`$1-7f:}.r-_....\§-'§'_,.\§
`
`F»'~5$*’1’~*’1'~*3‘
`
`<$3<.)‘=.-ii-"
`
`WTP.F‘f*C1P .................................................................. ..
`
`WT2..$.=‘SSL ................................................................. ..
`
`WSF’:‘1~iTTP ................................................................ ..
`
`i;‘.’fz;‘i{.I'£—~E'E'¥v‘;E_ ............................................................... ..
`
`WMLSc:'i;:t.*‘Ja\-'35“-:<;rig3i. ............................................... ..
`
`.
`
`.
`
`.
`
`'
`
`-
`
`-
`
`‘
`
`'
`
`29 November 1999
`
`AFFLT0293725
`
`Samsung Ex. 1019 p. 497
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`Interoperabiffty Requirements for Biue-tooth as a WAP Bearer
`
`page 498 of 1082
`
`Bluetonth.
`

`
`WA? in the Biuetaeth Féconet ...................................................... "585
`
`an
`
`‘WA? Server Commzmicatioma ......................... ..
`
`4.1.1
`
`inétéation by the Céiant
`
`4-.1.‘i.1 Discovea"yo:'ServEces ........... ..
`"i'ern1inaiion bythe Ciient
`
`4.1.2
`
`.................... "598
`.506
`
`..................... . 50?’
`E30"?
`
`4.1.3
`
`initéaticm by the Server Device
`
`E30"?
`
`4.1.3.1 Discoveryof
`.................... .. 558
`inxgmameratatiozu of WA? fez‘ Biuemoth .............. ..
`................... ..5{3E3
`4.2. ‘E
`‘uifffi?’ ?-fianagemesut Entity ..................... ..
`
`4.2.1.1 Asynchronous Neiifications
`4.2.1.2 Aitemate
`
`. 5G8
`538
`
`4.2.2 Addressing .......................................... ..
`
`....................
`
`451.3
`
`Network Su;Jp0rt'1:rWAP ................................ ..
`4.3.1
`
`.................... ..5{3Q
`509
`
`iniemperabiiity Fiequirememzs. ...................................................... .. 511
`5.1
`Siege 1 — Basia: !n?erc:;3erai*.-iiitg.-' ....................... .. .................... “$311
`Stage 2
`1’-\ci~.ranc:eci interogaerabéiiiy ...................................... .. 511
`
`5.2
`
`$awice fliscuvery .......................................................................... ..5?2
`512
`£13.?
`SUP Service Recmds
`$3.2
`
`SEEP Frotuczai Data Units
`
`SM
`
`6.3
`
`Servicze discovery ;3rc.=r:=:-adure
`
`534
`
`Refarentxes ...................................................................................... .. 5'3 5
`
`29 November 1999
`
`AFFLTD293726
`
`Samsung Ex. 1019 p. 498
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 499 of 1082
`
`interoperabifiry Requirements for Biuetooth as a WAP Bearer
`
`uetooth.
`
`1
`
`INTRODUCTION
`
`1.1 DOCUMENT SCOPE
`
`This document is intended for Bluetooth implementers who wish to take advan-
`tage of the dynamic, ad-hoc characteristics of the Bluetooth environment in
`providing access to value-added sewices using the WAP environment and pro-
`toools.
`
`Bluetooth provides the physical medium and link control for communications
`between WAP client and server. This document describes how PPP may be
`used to achieve this communication.
`
`The information contained in this document is not sufficient to allow the imple-
`mentation of a generat-purpose WAP ciient or server device. Instead, this doc-
`ument provides the following information:
`
`- An overview of the use of WAP in the Bluetooth environment will explain
`how the concept of value-added services fits within the Bluetooth vision.
`Examples are given of how the WAP value-added services model can be
`used to fulfil specific Bluetooth usage models.
`
`The WAP Services Overview attempts to place the WAP environment in a
`familiar context. Each component of WAP is introduced, and is contrasted
`with equivalent Internet protocols (where applicable).
`
`A discussion of WAP in the Bluetooth Piconet describes how the particular
`structure of Bluetooth communications relates to WAP behaviors.
`
`Finally. the Interoperability Requirements describe the specific Bluetooth
`features that must be implemented in order to ensure interoperability
`between any two WAP enabled Bluetooth devices.
`
`29 November 1999
`
`AFFLT0293727
`
`Samsung Ex. 1019 p. 499
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`interoperabiiity Requirements for Biueioofh as a WAP Bearer
`
`page 500 of 1082
`
`Bluetooth-
`
`2 THE USE OF WAP IN THE BLUETOOTH ENVIRONMENT
`
`2.1 VALUE-ADDED SERVICES
`
`The presence of communications capabilities in a device is unlikely to be an
`end in itself. The end users are generally not as interested in the technology as
`in what the technology allows them to do.
`
`Traditional telecommunications relies on voice communications as the single
`application of the technology, and this approach has been successful in the
`marketplace. As data communications services have become more widely
`available, there is increasing pressure to provide services that take advantage
`of those data capabilities.
`
`The Wireless Application Protocol Forum was formed to create a standards-
`based framework, in which value-added data services can be deployed, ensur-
`ing some degree of interoperability.
`
`2.2 USAGE CASES
`
`The unique quality of Bluetooth, for the purposes of delivering value-added ser-
`vices, is the limited range of the communications link. Devices that incorporate
`Bluetooth are ideally suited for the receipt of location-dependent services. The
`following are examples of how the WAP ciient 1’ server mode! can be applied to
`Bluetooth usage cases.
`
`2.2.1 Briefcase Trick
`
`Figure 2.1: The ‘Briefcase Trick‘ Hidden Computing Scenario
`
`The Briefcase Trick usage case allows the user’s laptop and mobile phone to
`communicate, without user intervention, in order to update the user's e-maii.
`The user can review the received messages from the handset, all without
`removing the laptop from its storage in a briefcase.
`
`29 November 1999 The Use of WAP In the Bluetoolh Environment
`
`AFFLT0293'/28
`
`Samsung Ex. 1019 p. 500
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`interoperabiiity Requirements for Biuetooth as a WAP Bearer
`
`page 501 of 1082
`
`Bluetooth.
`
`2.2.2 Forbidden Message
`
`Figure 2.2: The ‘Forbidden Message’ Hidden Computing Scenario
`
`The Forbidden Message usage case is similar to the briefcase trick. The user
`can compose messages in an environment where no dial-up connection is pos-
`sible. At a later time the laptop wakes up, and checks the mobile phone to see
`if it is possible to send the pending messages. If the communications link is
`present, then the mail is transmitted.
`
`2.2.3 WAP Smart Kiosk
`
`The WAP Smart Kiosk usage case allows a user to connect a mobile PC or
`handheld device to communicate with a kiosk in a public location. The kiosk
`can provide information to the device that is specific to the user's location. For
`exampie, information on flights and gates in an airport, store locations in a
`shopping centre. or train schedules or destination information on a railway plat-
`form.
`
`The Use of WAP In the Bluetoolh Environment
`
`29 November 1999
`
`AFFLT0293729
`
`Samsung Ex. 1019 p. 501
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`interoperability Requirements for Blue-tooth as a WAP Bearer
`
`page 502 of 1082
`
`Bluetooth-
`
`3 WAP SERVICES OVERVIEW
`
`The Wireless Application Protocol is designed to provide Internet and Internet-
`like access to devices that are constrained in one or more ways. Limited com-
`munications bandwidth. memory, processing power, display capabilities and
`input devices are all factors driving the development of WAP. Although some
`devices may only exhibit some of the above constraints, WAP can still provide
`substantial benefit for those devices as well.
`
`The WAP environment typically consists of three types of device: the WAP Cli-
`ent device. the WAP Proxylgateway and WAP Server. In some cases the WAP
`Proxyfgateway may also include the server functionality.
`
`WAP Client
`
`Base Station WAP Server.-‘Proxy
`
`Figure 3. 1: Typical WAP Environment
`
`3.1 WAP ENTITIES
`
`3.1.1 WAP Client
`
`The WAP Client device is usually found in the hands of the end user. This
`device can be as powerful as a portable computer, or as compact as a mobile
`phone. The essential feature of the client is the presence of some type of dis-
`play and some type of input device.
`
`The WAP Client is typically connected to a WAP Proxyigateway through a wire-
`less network. (Figure
`on page 503) This network may be based on any
`available technology. The WAP protocols allow the network to exhibit low reli-
`ability and high latency without interruption in service.
`
`29 November 1999
`
`WAP Services Overview
`
`AFFLT0293730
`
`Samsung Ex. 1019 p. 502
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 503 of 1082
`
`interoperability Requirements for Bluetooth as a WAP Bearer
`
`uetooth.
`
`3.1.2 WAP Proxyi‘Gateway
`
`The WAP Proxyigateway acts as an interface between the wireless network,
`and the larger Internet. The primary functions of the proxy are to provide DNS
`name resolution services to WAP ciient devices and transiation of Internet pro-
`tocols and content formats to their WAP equivalents.
`
`3.1.3 WAP Server
`
`The WAP Server performs a function that is similar to a server in the Internet
`world. In fact. the WAF’ server is often an HTTP server. The server exists as a
`
`storage location for information that the user can access. This ‘content’ may
`include text, graphics, and even scripts that allow the client device to perform
`processing on behalf of the server.
`
`The WAP Server logic may exist on the same physical device as the Proxy.’
`gateway, or it may reside anywhere in the network that is reachable from the
`Proxyigateway.
`
`The server may fill the role of an HTTP server, a WSP server, or both.
`
`3.2 WAP PROTOCOLS
`
`The WAP environment consists of a layered protocol stack that is used to iso-
`late the user agents from the details of the communications network. Figisre «3.1
`on page fitit‘; illustrates the general architecture of the WAP protocol stack.
`Bluetooth will provide an additional data bearer service, appearing at the bot-
`tom of this diagram.
`
`.
`
`.
`
`._..E .....:..__ _E _.:_.
`
`.
`
`.
`
`other Services and
`Mnlications
`
`Beams:
`|os!.I
`
`as-136
`
`IW°Pi
`
`Té-#6:?-:=%¥%“= -';'?‘.1'=
`\ .\. ..\..
`..,\.
`..
`com Pl-IS
`
`cow PDC—P |
`
`Figure 3.2: WAP Protocol Stack
`
`WAP Services Overview
`
`29 November 1999
`
`E:
`iDI'-.‘N | max ||stc... E?
`
`AFFLT0293731
`
`Samsung Ex. 1019 p. 503
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`interoperabiiity Requirements for Biuetoofh as a WAP Bearer
`
`page 504 of 1082
`
`Bluetooth-
`
`3.2.1 Wireless Datagram Protocol (WDP)
`
`The WDP layer provides a service interface that behaves as a socket-based
`UDP implementation. For a bearer service based on IP, then this layer is UDP.
`For bearer which do not provide a UDP service interface, then an implementa-
`tion of WDP must be provided to act as an adaptation layer to allow socket-
`based UDP datagrams over the native bearer.
`
`3.2.2 Wireless Transaction Protocol (WTP)
`
`The WTP layer provides a reliable datagram service on top of the WDP (U DP)
`layer below.
`
`3.2.3 Wireless Transport Layer Security (WTLS)
`
`The WTLS layer is an optional component of the protocol stack that provides a
`secure data pipe between a client WSP session and its peer server WSP ses-
`sion. In the current version of the WAP specification, this session will terminate
`at the WAP server. There is currently a proposal before the WAP Forum for a
`proxy protocol, which will allow the intermediate WAP proxy to pass WTLS traf-
`fic across the proxyigateway without decrypting the data stream.
`
`3.2.4 Wireless Session Protocol (WSP)
`
`The WSP layer establishes a relationship between the client application. and
`the WAP server. This session is relatively long-lived and able to survive service
`interruptions. The WSP uses the services of the WTP for reliable transport to
`the destination proxyigateway.
`
`3.3 CONTRASTING WAP AND INTERNET PROTOCOLS
`
`The intent and implementation of the WAP protocol stack has many parallels
`with those of the Internet Engineering Task Force (IETF). The primary objective
`of the WAP Forum has been to make Internet content available to devices that
`
`are constrained in ways that make Internet protocols unsuitable for deploy-
`ment.
`
`This section compares the roles of the WAP protocol stack‘s layers with those
`of the IETF.
`
`3.3.1 UDPIWDP
`
`At the most basic layer, WAP and lntemet protocols are the same. The WAP
`stack uses the model of a socket-based datagram (UDP) service as its trans-
`port interface.
`
`Some Internet protocols also use the UDP service, but most actually use a
`connection-oriented stream protocol (TCP).
`
`29 November 1999
`
`WAP Services Overview
`
`AFFLT0293732
`
`Samsung Ex. 1019 p. 504
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 505 of 1082
`
`interoperabiifly Requirements for Biuetooth as a WAP Bearer
`
`uetooth.
`
`3.3.2 WTPITCP
`
`The wireless transport protocol (WTP) provides services that, in some
`respects, fill the same requirements as TCP. The Internet Transmission Control
`Protocol (TCP) provides a reliable, connection-oriented, character-stream
`protocol that is based on IP services. In contrast, WTP provides both reliable
`and unreliable, one-way and reliable two-way message transports. The trans-
`port is optimized for WAP’s ‘short request, long response’ dialogue characteris-
`tic. WTP also provides message concatenation to reduce the number of
`messages transferred.
`
`3.3.3 WTLSISSL
`
`The Wireless Transport Layer Security (WTLS) is derived from the Secure
`Sockets Layer (SSL) specification. As such, it performs the same authentica-
`tion and encryption services as SSL.
`
`3.3.4 WSPIHTTP
`
`Session services in WAP are provided by the Wireless Session Protocol
`(WSP). This protocol incorporates the semantics and functionality of HTTP 1.1,
`while adding support for long-lived sessions, data push, suspend and resume.
`Additionally, the protocol uses compact encoding methods to adapt to narrow-
`band communications channels.
`
`3.3.5 WMUHTML
`
`The markup language used by WAP is a compact implementation that is simi-
`lar to HTML, but optimized for use in hand-held devices. WML is an XML-
`defined markup language.
`
`3.3.6 WMLScripti'JavaScript
`
`WAP also incorporates a scripting language that is similar to JavaScript, but
`adapted to the types of constrained devices that WAP is targeted for.
`
`WAP Services Overview
`
`29 November 1999
`
`AFFLT0293733
`
`Samsung Ex. 1019 p. 505
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`interoperabiiity Requirements for Biuefoorh as a WAP Bearer
`
`page 506 of 1082
`
`Bluetooth.
`
`4 WAP IN THE BLUETOOTH PICONET
`
`In many ways, Bluetooth can be used like other wireless networks with regard
`to WAP. Bluetooth can be used to provide a bearer for transporting data
`between the WAP Client and its adjacent WAP Server.
`
`Additionally, B|uetooth’s ad hoc nature provides capabilities that are exploited
`uniquely by the WAP protocols.
`
`4.1 WAP SERVER COMMUNICATIONS
`
`The traditional form of WAP communications involves a client device that com-
`
`municates with a Serverl’Proxy device using the WAP protocols. In this case
`the Bluetooth medium is expected to provide a bearer service as specified by
`the WAP architecture.
`
`4.1.1 Initiation by the Client Device
`
`When a WAP client is actively ‘listening’ for available Bluetooth devices, it can
`discover the presence of a WAP server using B|uetooth's Service Discovery
`Protocol.
`
`WAP Proxy
`I Gateway
`
`Figure 4. 1: WAP Server / Proxy in Piconet
`
`In Pigure dist, stage 1 the WAP Client device is moving into range of the WAP
`Proxyigateway's piconet. When the client detects the presence of the WAP
`proxyigateway, it can automatically, or at the client's request, connect to the
`server.
`
`29 November 1999
`
`WAP in the Bluetooth Pioonet
`
`AFFLT0293734
`
`Samsung Ex. 1019 p. 506
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 507 of 1082
`
`interoperability Requirements for Bluetooth as a WAP Bearer
`
`uetooth.
`
`4. 1.1. 1 Disco very of Services
`
`The client must be able to determine the specific nature of the WAP proxy!
`gateway that it has detected. It is expected that the Bluetooth Service Discov-
`ery Protocol will be used to learn the following information about the server:
`
`- Server Name — this is a user readable descriptive name for the server.
`
`- Server Home Page Document Name — this is the home page URL for the
`server. This is optional.
`
`Server!Proxy Capability — indicates if the device is a WAP content server, a
`Proxy or both. If the device is a Proxy, it must be able to resolve URLs that
`are not local to the Server!Proxy device.
`
`In Figgtira 4:32, stage 2, the device is communicating with the WAP proxyigate—
`way. All WAP data services normally available are possible.
`
`4.1.2 Termination by the Client Device
`
`In i5=ig_;1.ir-:-3 4.1, stage 3. the device is exiting the piconet. When the device
`detects that communication has been lost with the WAP proxylgateway, it may
`optionally decide to resume communications using the information obtained at
`discovery.
`
`For example, a client device that supports alternate bearers may query the
`alternate address information of the server when that capability is indicated.
`The information should be cached for later access because the client device
`
`may leave the piconet at any time, and that information will no longer be avail-
`able.
`
`In the WAP Smart Kiosk example above, if the user wishes to continue
`receiving information while out of Bluetooth range, the Kiosk would provide an
`Internet address to the client device. When Btuetooth communications are not
`
`possible. the device could use cellular packet data to resume the client-server
`SBSSIOFI.
`
`This capability is impiementation-dependent, and is provided here for illustra-
`tive purposes only.
`
`4.1.3 Initiation by the Server Device
`
`An alternative method of initiating communications between a client and server
`is for the server to periodically check for available client devices. When the
`server device discovers a client that indicates that it has WAP Client capability,
`the server may optionally connect and push data to the client.
`
`The client device has the option of ignoring pushed data at the end user’s dis-
`cretion.
`
`WAP in the Bluetooth Piconet
`
`29 November 1999
`
`AFFLT0293735
`
`Samsung Ex. 1019 p. 507
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`interoperabiiity Requirements for Biue-tooth as a WAP Bearer
`
`page 508 of 1082
`
`Bluetooth-
`
`4 . 1'. 3.1 Discovery of Services
`
`Through the Bluetooth Service Discovery Protocol, the server can determine
`the following information about the client:
`
`' Client Name — this is a friendly format name that describes the client device
`
`- Client capabilities — this information allows the server to determine basic
`information regarding the client's Bluetooth-specific capabilities
`
`4.2 IMPLEMENTATION OF WAP FOR BLUETOOTH
`
`In order to effectively implement support for WAP over Bluetooth, certain capa-
`bilities must be considered.
`
`4.2.1 WDP Management Entity
`
`Associated with an instance of the WDP layer in the WAP Protocol Stack is an
`entity that is responsible for managing the services provided by that layer. The
`WDP Management Entity (WDP-ME) acts as an out-of-band mechanism for
`controlling the protocol stack.
`
`4.2.1.1 Asynchronous Notifications
`
`The WDP-ME will need to be able to generate asynchronous notifications to
`the application layer when certain events occur. Example notifications are:
`
`- New Client Node Detected
`
`- New Server Node Detected
`
`' Client Node Signal Lost
`
`- Server Node Signal Lost
`
`- Server Push Detected (detected as unsolicited content)
`
`Platform support for these events is implementation-specific. All of the listed
`events may be derived through the Bluetooth Host Controller Interface
`(page 51?), with the exception of Server Push.
`
`4.2.1.2 Aiternate Bearers
`
`An implementation of WAP on a particular device may choose to support multi~
`ple bearers. Methods of performing bearer selection are beyond the scope of
`this document. The procedure to be followed is implementation-dependent.
`See F‘.-tactics 4.'§..’:‘: above.
`
`29 November 1999
`
`WAP in the Bluetooth Pioonet
`
`AFFLT0293736
`
`Samsung Ex. 1019 p. 508
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 509 of 1082
`
`lnteroperabifity Requirements for Bluetooth as a WAP Bearer
`
`uetooth.
`
`4.2.2 Addressing
`
`Two basic types of addressing are being used in the WAP environment: User
`Addressing and Proxyfgateway Addressing. User addressing describes the
`location of objects within the network, and is independent of the underlying
`bearer. Proxyi'Gateway Addressing describes the location of the WAP proxy!
`gateway that the device is communicating with. Proxyi'Gateway addressing is
`dependent on the bearer type.
`
`The end user deals mainly with Uniform Resource Locators (URL). These
`addresses are text strings that describe the document that is being accessed.
`Typically, the Proxyigateway in conjunction with Internet Domain Name.
`
`Servers resolve these strings into network addresses.
`
`The address of the WAP Proxyigateway is usually a static value that is config-
`ured by the user or network operator. When the user enters a URL, the request
`is forwarded to the configured WAP proxyigateway. If the URL is within the
`domain of a co-located server. then it indicates that the document is actually
`WAP content. If the URL is outside of the WAP proxyi'gateway’s domain, then
`the WAP Proxyigateway typically uses DNS name resolution to determine the
`H3 address of the server on which the document resides.
`
`The client device would first identify a proxyigateway that is reachable through
`Bluetooth, then it would use the service discovery protocol to present the user
`with a server name or description. When the user selects a server, then the
`WAP client downloads the home page of the server (as determined by the dis»-
`covery process; see section 4.1.1.? on page 559'?) Once the user has navigated
`to the home page of the desired server, then all subsequent URLs are relative
`to this home page. This scenario presumes that the WAP Proxyigateway and
`WAP Content server are all co-located in the Bluetooth device, although this
`structure is not required for interoperability.
`
`A WAP Proxyigatewayiserver will typically provide a default URL containing
`the home page content for the server. A proxy-only device typically provides no
`URL or associated content.
`
`4.3 NETWORK SUPPORT FOR WAP
`
`The following specifies a protocol stack, which may be used below the WAP
`components. Support for other protocol stack configurations is optional, and
`must be indicated through the Bluetooth Service Discovery Protocol.
`
`4.3.1 PPPIRFCOMM
`
`Devices that support Bluetooth as a bearer for WAP services using PPP pro-
`vide the following protocol stack support:
`
`WAP in the Bluetooth Piconet
`
`29 November 1999
`
`AFFLT0293737
`
`Samsung Ex. 1019 p. 509
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`interoperability Requirements for Bluetooth as a WAP Bearer
`
`page 510 of1082
`
`Bluetooth-
`
`RFCOMM
`
`RFCOMM
`
`Figure 4.2.’ Protocol Support for WAP
`
`For the purposes of interoperability, this document assumes that a WAP client
`conforms to the role of Data Terminal as defined in LAN Access Profile using
`PPP £8}. Additionally, the WAP server or proxy device is assumed to conform to
`the role of the LAN Access Point defined in {$3}.
`
`The Baseband (page 323), LMP (page 185) and LZCAP (page 245) are the OSI
`layer 1 and 2 Bluetooth protocols. RFCOMM
`35:35) is the Bluetooth adap-
`tation of GSM TS 07.10 {#1. SDP (page 323) is the Bluetooth Service Discovery
`Protocol.
`
`PPP is the IETF Point-to-Point Protocol E33. WAP is the Wireless Application
`Protocol stack and application environment
`
`29 November 1999
`
`WAP in the Bluetooth Pioonel
`
`AFFLT0293'/38
`
`Samsung Ex. 1019 p. 510
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 511 of 1082
`
`interoperabiifly Requirements for Biuetooth as a WAP Bearer
`
`uetooth.
`
`5 INTEROPERABILITY REQUIREMENTS
`
`5.1 STAGE 1 — BASIC INTEROPERABILITY
`
`Stage 1 interoperability for WAP over Bluetooth (all mandatory):
`
`- Provide WAP Class A device compliance £7’:
`
`- Provide, through service discovery mechanisms, the network address for
`devices that support WAP proxyigateway functionality.
`
`5.2 STAGE 2 — ADVANCED INTEROPERABILITY
`
`Stage 2 interoperability for WAP over Bluetooth (mandatory):
`
`- All Stage 1 interoperability requirements are supported
`
`- Provide Server Name and information about Server.’Proxy capabilities
`through service discovery.
`
`Provide Client Name and information about Client Capabilities through ser-
`vice discovery.
`
`Asynchronous Notifications for Server.
`
`Asynchronous Notifications for Client.
`
`Interoperability Requirements
`
`29 November 1999
`
`AFFLT0293739
`
`Samsung Ex. 1019 p. 511
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`interoperabiiity Requirements for Biuefoofh as a WAP Bearer
`
`page 512 of1082
`
`Bluetooth.
`
`6 SERVICE DISCOVERY
`
`6.1 SDP SERVICE RECORDS
`
`Service records are provided as a mechanism through which WAP client
`devices and proxyigateways become aware of each other dynamically. This
`usage differs from other WAP bearers in that the relationship between the two
`devices will be transitory. That is, a Bluetooth device will not have a bearer-
`specific address configured or provisioned to a specific proxyigateway.
`
`Clients and proxyfgateways become aware of each other as they come in prox-
`imity of one another. The Bluetooth Service Discovery Protocol allows the
`devices to query the capabilities of each other as listed in the Interoperability
`Requirements section of this document.
`
`‘facts 5.‘: shows the service record for the WAP Proxyfgateway device.
`
`Definition
`
`Ser\riceC|asslDList
`
`ServiceC|assU
`
`WAP ProxyiGateway
`
`Bluetooth Profi le
`Descriptorust
`
`ProfileDescriptorO
`
`Profile
`
`Version
`
`Protocol
`Descriptorust
`
`Supported Profile
`
`Profile Version
`
`LANAccess
`Usingppp W
`
`(varies)
`
`Descriptorfl
`
`UDP
`
`UDP
`
`Parametero
`
`WSP Conneclionless
`Session Port No.
`
`9200 (default)
`
`Paramete-r1
`
`WTP Session Port No.
`
`9201 (defauiij
`
`Parameterz
`
`Parameter3
`
`WSP Secure Connec-
`lionless Port No.
`
`WTP Secure Session
`Port No
`
`Parameters‘-I
`
`WAP vCard Port No.
`
`Parameter5
`
`Parameter6
`
`Parameter?
`
`WAP vCai Port No.
`
`WAP vCard Secure
`Port No_
`
`WAP vCal Secure
`Port No.
`
`9202 (defaufl)
`
`9203 (defauit)
`
`9204 (defauir)
`
`9205 (default!)
`
`9206 (defauitj
`
`9207 (default!)
`
`Table 6.1: Service Record format for WAP Proxy/Ga tevvay devices
`
`29 November 1999
`
`Service Discovery
`
`AFFLT0293740
`
`Samsung Ex. 1019 p. 512
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 513 of 1082
`
`interoperabiiiiy Requirements for Biuetooth as a WAP Bearer
`i"“""“’“““‘"“""""“"“"“‘
`Item
`
`Defl n itlon
`
`Value
`
`uetooth.
`
`ServiceName
`
`Dispiayable
`Text name
`
`(varies, e.g.
`‘Airport infor-
`mation‘)
`
`NetworkAddress
`
`IP Network Address
`of Server
`
`(Varies)
`
`WAPGateway‘
`
`0x01 = Origin
`Server;
`
`Indicates if device is
`
`.
`
`0x02 = Proxy;
`
`origin server or proxy
`
`M03 2 Origin
`Server and
`Proxy
`
`HomePageURL
`
`URL of home page
`document
`
`Tebie 6.1: Service Record fame: for WAP Proxy/Gateway devices
`
`*. Stage 2 interoperabiity requirements.
`
`T. If this parameter is omitted, then a default is assumed for origin servers as:
`http:i.-‘networks-oidress/1ndex.wm|
`
`ServiceC|ass|DList
`
`Serviceclassfl
`B|uetoothProfi|e
`
`DescriptorList
`
`Profi|eDescriptor0
`
`K UUID WAP_CL|ENT
`
`Profile
`
`Version
`
`ServiceName
`
`Supported Profile
`
`Profile Version
`
`Displayable
`.
`Text name of client
`
`LANAcce-ss
`Usingppp W
`
`(varies)
`
`String
`
`(varies)
`
`Tabie 6.2: Service Record format for WAP Ciienr devices
`
`Service Discovery
`
`29 November 1999
`
`AFFLT0293741
`
`Samsung Ex. 1019 p. 513
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`page 514 of1082
`
`interoperabiiity Requirements for Blue-tooth as a WAP Bearer
`
`Bluetooth-
`
`6.2 sop PROTOCOL DATA uuns
`
`'i"ai3ia
`
`shows the specified SDP PDUs (Protocol Data Units). which are
`
`required for WAP Interoperability.
`
`Ability to Send
`
`Ability to Retrieve
`
`WAP
`Client
`M
`
`WAP
`Proxy
`M
`
`WAP
`Client
`M
`
`WAP
`Proxy
`M
`
`SDP PD”
`
`SdpErrorResponse
`
`Sd pSe rvice Searchmlri buteRequest
`
`Sd pSe Nice SearchAtlributeRespor1se
`
`Table 6.3.’ SDP PDUIS
`
`6.3 SERVICE DISCOVERY PROCEDURE
`
`In the simplest form, the signaling can be like this:
`\

`co.\xxw.\-«x“xxxxmxxxxxx-aw.\-ax-o.\-ax-o.\-aw.\-ax-9%.-o.w.xxx\-o.\-«xxxxxxwxxxwtxxxxxxx-ax-o.\-aw.\-ax-aux-ax-o.w.\-o.\-«x-o.\-o.w\xxxxmxxwfixxxxxxxxx-exxx-A».\-mmxvxmxmxmxwxmx-«xv-.\x\\m\x\\x\\
`3
`E
`.
`§5
`WAP Client or Proxy iv‘
`3 WAP Client or Proxy
`\\r.\\r.\\rL\\9.\\o.\\9.\\9.\\9.\\r\\\9.\\9.\rvs\\>.\\.\\n.\\r.\\n.\
`\r.\\ra\\r.\\r\\\o.\\o.\T.\Vx\V.\Vx\\o.\\r.\rv\\\.x\\.>.\ru\\r:.\\V\\ru\\ru\\r.\\ra\\r\\\r\\\9.\\9.xv.\\r.\\§\\\V.\V.vvs\\.x\\.x\ru\\r.\\ru\\ru\\r\\\r.\\r.\\ru\\r\\\o.\\n.\\r.\\r.\\o.\
`§“
`§ Sd pServiceSearchAttrIbuteReq uest

`§3§
`S
`Q
`gi
`Q Z:::=::=::=:::2::=:::==)
`\
`mxmmwwxvmxmxmmxwwsvmv.:s\>.:w\\\w\wq~évmvmwmwmwwvmwwvia-n:o>.:s\¢:s~:\\\\\:\\~.\a~\r\v:\wN\:\~ru\\n:\\r.:\\n:\\wn:\\§\wm:smwwamxmxmxwmvavmmwxvmmvmxmmvm
`§ SdpServiceSearchAttributeResponse
`t _____________________ __
`Q < ————————————————————— -—-v
`. YB\A\\DL\\N\\A\\D.\\E\\\n\\A\\b.\\9.\\9.\$\EW.\V\\\b.\\9.\K$$\KVA“\\v.\\N\\A\\B.\\EV.\\n\\A\\b.\\9.\\9.\\b.\N(\V\\\b.\$\V\\hb.\\9.VA\A\\‘4.\\N\\‘D.\B.\\EV.\\E\}§A\$\\9.\\9.\\‘r.\N(\\9.\\b.\“\V\\\b.\$\Em\N\\V\\N\\‘D.\D.\\E\\\A\\A\
`
`I
`
`MIA’/N/MIN//h$IYIAV4!/»V/MlfivgAI/JV:
`
`§§§3t y
`
`m W
`
`AP service discovery procedures are symmetrical. Each device must be able
`to handle all of the PDUS without regard for the current device role. A minimal
`implementation must return the service name string.
`
`29 November 1999
`
`Servioe Discovery
`
`AFFLT0293742
`
`Samsung Ex. 1019 p. 514
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 515 of 1082
`
`interoperability Requirements for Biuetooth as a WAP Bearer
`
`uetooth.
`
`7 REFERENCES
`
`[1]
`
`[2]
`
`[3]
`
`TS 101 369 (GSM 07.10) version 6.2.0
`
`Simpson, W., Editor, "The Point—to-Point Protocol (PPP)", STD 50, RFC
`1661, Daydreamer, July 1994.
`
`Simpson, W., Editor, "PPP in HDLC Framing", STD 51, RFC 1662, Day-
`dreamer, July 1994.
`
`[4]
`
`See Appendix VIII, “Bl=..=eto<:>th Assigraso‘ Nurnr.-ere“ on
`
`18-99
`
`[5] Wireless Application Protocol Forum, ‘Wireless Application Protocol",
`version 1.0, 1998
`
`[6] Bluetooth Special interest Group, "Bluetooth LAN Access Profile using
`PPP"
`
`[?] Wireless Application Protocol Forum, "WAP Conformance", Draft version
`27 May 1998
`
`29 November 1999
`
`AFFLT0293743
`
`Samsung Ex. 1019 p. 515
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`page 516 of1082
`
`Jnteroperabflfty Requirements for Biue-tooth as a WAP Bearer
`
`uetooth-
`
`29 November 1999
`
`References
`
`AFFLT0293744
`
`Samsung Ex. 1019 p. 516
`
`

`
`CONTROLLER INTERFACE
`SPECIFICATION
`
`=
`
`:
`
`- This %pocum §nt describes the functional speci-
`ficat' n for tie Host Controller Interface (HCI).
`The s CI proglides a command interface to the
`bas§band cgmtroller and link manager, and
`acgess to Ijardware status and control regis-
`tefs. This filterface provides a uniform method
`ff accesfing the Bluetooth baseband capabili-
`fifties.
`is
`
`AFFLT0293745
`
`Samsung Ex. 1019 p. 517
`
`

`
`BLUETOOTH SPECEFICATION Version 1.0 8
`
`page 518 of 3382
`
`Host Conrrofler Interface Functfonaf Specification
`
`uetooth-
`
`29 November 1999
`
`AFFLT0293746
`
`Samsung Ex. 1019 p. 518
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`Host Conrrofler Interface Functional Specification
`
`CONTENTS
`
`page 519 0f1G82
`
`Bluetouth.
`
`imrcsziuctimz ................................................................................ ......524
`1.‘:
`
`Lower Layers at ‘me Eiuatcoéiu Sefiwara Stack ...................... ..
`
`524
`
`1.2
`
`Biuetooth Hardware Biock Déagram .....

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket