Telecommunications – Transmitter and receiver at separate stations – Short range rf communication
Reexamination Certificate
2000-11-30
2004-11-30
Milord, Marceau (Department: 2682)
Telecommunications
Transmitter and receiver at separate stations
Short range rf communication
C455S061000, C455S557000, C455S556200, C455S517000, C455S426100, C370S338000
Reexamination Certificate
active
06826387
ABSTRACT:
TECHNICAL FIELD
The present invention relates to the field of networks of devices connected using wireless links, in particular those devices that use the Bluetooth technology. Specifically, the present invention pertains to a method and system for registering a service record for a legacy application running on a virtual serial port.
BACKGROUND ART
Computer systems and other types of consumer electronic devices are commonly linked to each other and to peripheral devices using a myriad of different types of cables and connectors. As these devices grow in number and variety, their cables and connectors can often become quite cumbersome to work with. Accordingly, efforts are underway to develop technologies allowing hardware connections to be replaced with wireless ones.
One such technology is the Bluetooth technology. Bluetooth is the code name for a technology specification for short-range radio links that will allow the many proprietary cables that connect devices to one another to be replaced with short-range radio links.
The Bluetooth technology is based on a high-performance, yet low-cost, integrated radio transceiver. For instance, Bluetooth transceivers built into both a cellular telephone and a laptop computer system would replace the cables used today to connect a laptop to a cellular telephone. Printers, personal digital assistants (palmtop computer systems, hand-held devices and the like), desktop computer systems, fax machines, keyboards, joysticks and virtually any other digital device can be part of a Bluetooth system. Bluetooth radio technology can also provide a universal bridge to existing data networks and a mechanism to form small private ad hoc groupings (“scatternets” or “piconets”) of connected devices away from fixed network infrastructures.
One issue that arises with the introduction of Bluetooth technology is the treatment of “legacy applications;” that is, those applications developed before the advent of Bluetooth and still residing on a Bluetooth-enabled device. These legacy applications are predicated on the use of actual (physical) serial cables, such as RS232 or similar serial cables, to connect the server and client devices. However, as described above, the Bluetooth technology replaces such cables with wireless connections. To address the issue of legacy applications, the Bluetooth specification (“Specification of the Bluetooth System, Core,” version 1.0B, dated Dec. 1, 1999, herein incorporated by reference as background) defines protocols and procedures that can be used by Bluetooth devices to emulate serial cables.
Prior Art
FIG. 1A
is a block diagram illustrating the protocol layers and applications residing on Bluetooth-enabled devices A
10
and B
20
in one embodiment. For Bluetooth-enabled devices, the protocol layers are described by the Bluetooth specification referenced above. In general, baseband
19
and
29
carry out baseband protocols and other low-level link routines, and logical Link Control and Adaptation Protocol (L2CAP)
18
and
28
support higher level protocol functions.
Because they pre-date Bluetooth, legacy applications
12
and
22
are not configured to implement Bluetooth procedures for setting up emulated serial cables. Accordingly, RFCOMM
16
and
26
provide a transport protocol for emulation of serial ports over L2CAP
18
and
28
, respectively. Serial port emulation blocks
14
and
24
are the entities that emulate serial ports and/or provide an application program interface to legacy applications
12
and
22
, respectively. Thus, legacy applications
12
and
22
can run on devices A
10
and B
20
, respectively, and communicate using the “virtual” serial ports as if there were a real serial cable connecting the devices.
It is expected that the number of Bluetooth devices will increase significantly, and that the number of services (e.g., applications) that can be provided over Bluetooth links will also increase significantly. To help users of Bluetooth devices sort through the increasing number of services and applications that will become available, procedures are being developed to standardize how services are to be located and identified on Bluetooth devices. These standards and procedures are described in the above-referenced Bluetooth specification and summarized below.
The protocol stack used by Bluetooth devices includes a Service Discovery Protocol (SDP) that is used to locate (discover) services and applications that are available on a Bluetooth-enabled device, or that are in the vicinity of such a device. SDP provides direct support for search inquiries by service class and/or service attributes, and also supports service browsing. Search inquiries by service class are for identifying whether a known service is available, and search inquiries by service attributes are used for identifying whether services having particular characteristics are available. Service browsing is used for general searches to identify, for example, what services of a particular type (e.g., news, reference, gaming, etc.) are available.
Service discovery can be initiated by either a master device or a slave device. Generally, in the context of service discovery and service use, the terms “server” and “client” are used. “Server” is used to refer to a device with services and applications waiting for a connection from a client device, and “client” refers to a device that initiates (requests) a connection to the application or service. A server device is also sometimes called an “acceptor,” and a client device is also sometimes called an “initiator.”
The Bluetooth service discovery process provides the means for client applications to discover the existence of services provided by server applications, as well as the attributes of those services. The attributes of a service are maintained by the server in a service record. The attributes of a service include the type or class of service offered, and the protocol information needed to utilize the service. Significantly, the attributes of a service should also include a service name, which is a text string containing a user-friendly (e.g., human-readable) name for the service.
An issue with regard to legacy applications (e.g.,
12
and
22
of
FIG. 1A
) is that they are not able to participate in the Bluetooth service discovery process. As mentioned, legacy applications
12
and
22
pre-date Bluetooth, and thus are not configured for the Bluetooth service discovery process.
Regarding service records for legacy applications, the Bluetooth. specification (specifically, Section 3.1.3 of the Serial Port Profile) states: “All services/applications reachable through RFCOMM [that is, legacy applications] need to provide an SDP service record that includes the parameters necessary to reach the corresponding service/application . . . In order to support legacy applications running on serial ports, the service registration must be done by some helper-application, which is aiding the user in setting up the port” (emphasis added).
Prior Art
FIG. 1B
is a table exemplifying a service record
50
for an available service or application, in particular for a legacy application. “ServiceClassIDList” identifies the type of service (e.g., serial port) represented by the service record
50
. The “ProtocolDescriptorList” specifies the protocol stacks (e.g., L2CAP and RFCOMM) that may used for the service. The “ProtocolSpecificParameter0” represents the RFCOMM server channel of the legacy application. The “ServiceName” is a text name displayable to and readable by a user.
The Bluetooth specification defines most of the values in service record
50
for a legacy application, with the notable exception of the service name (ServiceName). Other than the reference to “some helper application,” the Bluetooth specification provides no guidance regarding how the service name for the legacy application is to be provided for service record
50
.
The service name represents an important piece of information, enabling a user to readily identify an application and distinguish it from other appl
Milord Marceau
PalmSource Inc.
Wagner , Murabito & Hao LLP
LandOfFree
Efficient service registration for legacy applications in a... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Efficient service registration for legacy applications in a..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Efficient service registration for legacy applications in a... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3305630