WO2002015076A1

WO2002015076A1 - Method and apparatus for location dependent information services

Info

Publication number: WO2002015076A1
Application number: PCT/SE2001/001743
Authority: WO
Inventors: Gilbert Bengtsson; Roberto Busso; Georg De Laval; Anders Holmberg; Kjell Svensson
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2000-08-16
Filing date: 2001-08-10
Publication date: 2002-02-21
Also published as: AU2001280392A1; TW511383B; WO2002015076B1

Abstract

A method and apparatus is described for providing location dependent information services to customers in a WAP-Bluetooth environment. WAP-Bluetooth server units are provided to customers including qualified third party developers. A WAP-Bluetooth SDK is provided to third party developers and qualified WAP-Bluetooth applications are developed thereby. Qualified applications are loaded on WAP-Bluetooth server units for providing location dependent information services. Connections are made with WAP-Bluetooth client terminals and location-dependent WAP pages are pushed toward the WAP-Bluetooth client terminals using a WAP-Bluetooth application. A WAP-Bluetooth signal is transmitted in a coverage area associated with the location dependent information service and connections made with client terminals to provide the location dependent information service. Qualified applications are registered such that applications are available to customers and third party developers in a product registry. Qualified applications are presented and provided on a trial basis to customers using a website. The SDK includes a WAP-Bluetooth development environment, WAP-Bluetooth software modules, WAP-Bluetooth application examples, a bootloader, a software platform, and a basic WAP-Bluetooth application, and documentation. The software platform includes a Bluetooth stack, an operating system, and drivers. The WAP-Bluetooth development includes a graphical user interface development tool.

Description

A METHOD AND APPARATUS FOR LOCATION DEPENDENT INFORMATION SERVICES

BACKGROUND

The present invention relates to wireless radiocommunication systems. In particular, the present invention relates to a method and apparatus for providing location dependent information services.

In today's wireless network there is a large and growing flow of information. It is estimated that the number of wireless subscribers will increase by a factor of ten in the next three years from somewhere around 100 million to around 1 billion in 2003. While the bulk of wireless data traffic is voice oriented, there is an increasing flow of information related to the provision of Internet related services to wireless devices. With the increase in information flow resulting from, for example, providing Internet services, it becomes increasingly hard for information providers who want to reach a specific target group as well as for subscribers who want to get specific information. One solution to this problem is providing wireless customers with location-oriented services on a wireless network wide basis.

Some location based services now exist such as, for example, that described in U.S. Patent No. 6,091,956 to Hollenberg. Therein, a system is described for providing services and time-critical information about places and events to mobile users proximate to their current location. Included in the system is a specialized auxiliary computer terminal which is provided on the theory that by using, for example, a cellular telephone for the provision of location based services, costs would be prohibitive. In addition, costly GPS services are provided in the auxiliary terminal to provide the locating function. Problems arise in this system in that, for example, several locating functions must be provided to correlate mobile users and their locations to merchants and their locations through notoriously unreliable and band-limited satellite links. In addition there is no clear provision for how applications are developed and where and how they will run. For example, a description of menus is given but no provision as to whether menus are provided by service providers or the developer of the terminal. Another system, described in U.S. Patent No. 6,058,098 to Moon, et al, includes automatically configuring software in a portable intelligent communication device where the software settings are dependent on location information. Again, location information may be provided, for example, by GPS and may be correlated to within a cell size. It is not disclosed that location based information such as that provided by merchants or other location based services are provided. It is further not disclosed whether applications are necessarily designed specifically for a portable intelligent communications device by the manufacturer of the device or whether it is possible to provide such location information to any software application. With the emergence of Wireless Applications Protocols (WAP) has come the realization that there are virtually unlimited possibilities for application development, particularly by third parties, to serve users in new and, in many cases, very specialized ways. The expansion of Internet use has also given rise to boundless possibilities in the provision of information services. Opportunities for providing value-added services in conjunction with providing access to World Wide Web (www) pages or WAP pages using the wireless media as a conduit abound in today's high bandwidth environment. In addition, the trend towards "push" services, where information is sent to users in an unsolicited manner, gives rise to the opportunity for providing applications which, for example, give a user information in which they are interested and information which may be provided depending on factors which are known to the terminal and which, for example, can be entered into a mobile terminal through an operator interface or may be preprogrammed or the like. Further examples of WAP applications may include Internet information retrieval, where WAP may be used to allow wireless subscribers to access the Internet. It should be noted that certain mobile terminals may limit the ability of a user to access the Internet. Limitations such as memory size and the like may significantly reduce the ability of a user to navigate the Internet using a mobile wireless terminal. However, other applications may be facilitated by WAP including the dispatching of servicemen, email notification including interactive requests for additional information, access to payment services, telephone call setup service menus and the like. Unfortunately, the opportunity to provide WAP services has traditionally been limited to only those with the knowledge and the contacts within industries closely linked to the wireless community and, as a result, application development has been sparse. In addition, due to the need to provide WAP services on a fairly broad basis, smaller potential beneficiaries of WAP, e.g. small merchants and the like, and small proprietary users are effectively cut out of the WAP market. Further, the undesirable consequence associated with the limited number of appealing WAP applications has been to limit the appeal of wireless devices in general. Thus, it is believed that the wider availability of a richer array of WAP applications will drive an increasing demand for mobile terminals of every kind. For additional information on WAP, see "WAP - The wireless application protocol", Christer Erlandson, and Per Ocklind, Ericsson Review, No. 4, 1998. While some mention is made of Bluetooth, an example is provided of specialized calculators in a banking environment with no disclosure of how applications might be developed to serve such calculators. Problems arise in specialized applications designed for specialized hardware in that by operating only on the target hardware, the applications are limited in then attractiveness to a broader base of users.

Accordingly, it would be desirable in the art for a method and apparatus for providing location based information services and applications related thereto in an efficient and cost effective manner which would further stimulate the demand for wireless terminals.

It would be further desirable in the art for a method and apparatus for providing location based information services which would be scalable and which would be applicable to a number of broad application categories which would, again, further stimulate the demand for mobile terminals and like devices in accordance therewith.

It would be still further desirable for a method and apparatus which would facilitate the development of software applications which would further contribute to increasing the demand for mobile terminals by providing increased features and conveniences for mobile terminal users.

It would be still further desirable for a method and apparatus which would facilitate the development of software applications which would further contribute to an increasing demand for itself in that by developing better applications, demand would be increased for the method and apparatus itself.

SUMMARY

To fulfill these and other needs of the art, a method and apparatus for is described for providing location dependent information services to one or more customers in a WAP-Bluetooth environment.

Thus in accordance with various exemplary embodiments of the present invention, one or more WAP-Bluetooth server units may be provided to customers, including one or more qualified third party developers. In addition, a WAP-Bluetooth Software Developer Kit (SDK) may be provided to the qualified third party developers for the development of applications. It should be noted that developers as well as the applications they provide may be subject to qualification by way of, for example, a certification process. Thus one or more qualified WAP- Bluetooth applications developed by the third party developers may be provided to the customers such that the qualified applications may be loaded on the WAP- Bluetooth server units for actually providing location dependent information services to one or more customers and one or more mobile WAP-Bluetooth terminals.

Further in accordance with various exemplary embodiments of the present invention, one or more WAP-Bluetooth client terminals may be connected with, for example, one or more WAP-Bluetooth servers. One or more location-dependent WAP pages may be pushed toward the WAP-Bluetooth client terminals using a WAP-Bluetooth application executing on the WAP-Bluetooth servers. Further, a WAP-Bluetooth signal may be transmitted, for example, by one or more WAP- Bluetooth servers in a coverage area associated with the location dependent information service and connections made with one or more WAP-Bluetooth client terminals to provide the location dependent information service. One or more qualified WAP-Bluetooth applications may be registered such that the qualified WAP-Bluetooth applications are available to the customers and the third party developers in, for example, a product registry such as a database or the like. Accordingly, the qualified WAP-Bluetooth applications may be presented and provided on a trial basis to the customers using for example, a website.

Further in accordance with providing an SDK to qualified third party developers, the SDK may include, for example, a WAP-Bluetooth development environment, WAP-Bluetooth software modules, and documentation. The SDK may further include a bootloader, a software platform, and a basic WAP-Bluetooth application which WAP-Bluetooth application may serve as an examples although other examples ranging from simple to complex may be provided in the SDK. The software platform provided with the SDK may further include, for example, a Bluetooth stack, an operating system, and drivers corresponding to one or more hardware interfaces which are to be supported. It should be noted that he SDK may includes one or more open source software components.

Further in accordance with the present invention, the WAP-Bluetooth development environment may includes a graphical user interface development tool which may be associated with Microsoft^® Windows^® operating environment, UNIX operating environment, or the like.

BRIEF DESCRIPTION OF THE DRAWINGS

The objects and advantages of the invention will be understood by reading the following detailed description in conjunction with the drawings, in which: FIG 1A is a diagram illustrating an exemplary Bluetooth service environment in accordance with the exemplary embodiments of the present invention;

FIG IB is a diagram illustrating an exemplary Bluetooth service environment using an exemplary WAP-Bluetooth server in accordance with exemplary embodiments of the present invention;

FIG 2 consists of FIG 2A and FIG 2B and is a diagram illustrating the entity relationships among exemplary components of an exemplary WAP-Bluetooth server environment in accordance with exemplary embodiments of the present invention; FIG 3 is a block diagram illustrating exemplary blocks of an exemplary

WAP-Bluetooth server in accordance with exemplary embodiments of the present invention;

FIG 4 is a block diagram further illustrating exemplary blocks of an exemplary WAP-Bluetooth server in accordance with exemplary embodiments of the present invention;

FIG 5A is a diagram illustrating exemplary layers of an exemplary WAP- Bluetooth application development environment in accordance with exemplary embodiments of the present invention;

FIG 5B is a diagram illustrating an exemplary memory map for use in an exemplary WAP-Bluetooth application development environment in accordance with exemplary embodiments of the present invention; FIG 6A is a mechanical diagram illustrating an exemplary circuit board layout in accordance with an exemplary embodiment of the present invention showing exemplary antenna module placement; and

FIG 6B consists of FIG 6B-1, FIG 6B-2, and FIG 6B-3 and is a mechanical diagram illustrating an exemplary packaging design in accordance with exemplary embodiments of the present invention.

DETAILED DESCRIPTION

The various features of the invention will now be described with reference to the figures, in which like parts are identified with the same reference characters. Thus a method and apparatus are described for providing location based information services. In accordance with various exemplary embodiments of the present invention, a location-oriented service may be provided wherein local information is communicated in accordance with the Bluetooth standard to a WAP- Bluetooth device, such as, for example, a mobile phone, PDA, and the like, or any device which has a Bluetooth interface and an appropriate application developed, for example, in accordance with the present invention, for providing services from a WAP-Bluetooth server further in accordance with the present invention.

As can be seen in FIG 1A where exemplary Bluetooth environment 100 is shown, when user 140 approaches a Bluetooth equipped premise with coverage area 121, a connection may be established between Bluetooth terminal 130 and, for example Internet 110 where Customer Location-oriented information 120 may be transferred to user 140 through message 122 sent to Bluetooth terminal 130. In this way information which is highly localized may be transferred to user 140 in a location specific manner not possible with prior art solutions. Since the potential applications of such a proximity oriented or location dependent service are literally boundless and will be described in greater detail hereinafter, it will be sufficient for now to understand basic Bluetooth service in accordance with various exemplary embodiments of the present invention. Bluetooth service environment 100 may be further understood by considering WAP-Bluetooth server 140 which may be connected, for example, to a standard computer 150 for providing an adjunct, a high speed connection to the Internet, an auxiliary server to an adjunct website or may simply operate in a stand alone manner. It should be noted that standard computer 150 may be used for downloading applications to WAP-Bluetooth server 140 through a serial interface using, for example, a cable. In addition, software for maintenance of WAP- Bluetooth server 140 may be developed so that it runs on, for example, standard computer 150. Accordingly, Bluetooth terminals 130 may be provided with push services that, for example, a third party application development customer may want to mediate. It should be noted that information that such a third party customer may prefer to mediate in such a manner may be isolated from other information services due largely to the limited range accorded to Bluetooth server 140. While ranges of 100 meters are possible, a typical range of from 10m to 30m ensures that a certain amount of inherent isolation is possible using Bluetooth based service provision in accordance with the present invention and in accordance with the Bluetooth standard as outlined in the Bluetooth Specification v 1.0A. In particular, the Interoperability Requirements for Bluetooth as a WAP Bearer at pages 495 to 513 of the Bluetooth specification, id. , may provide a basis for further understanding provision of location dependent information services and WAP-Bluetooth application development in accordance with the present invention. Accordingly, server 140 may push, for example, web pages onto user 140 's WAP- Bluetooth terminal 130 that application development and/or service provision customers, e.g. customers which have purchased one or more WAP-Bluetooth servers 140, want to mediate.

It should be noted that in order to increase the probability that user 140 will actually look up the information provided, WAP-Bluetooth server 140 may preferably, in accordance with various embodiments of the present invention, provide pushed information for free. It should further be noted that if a service provision/application developer customer only has an Internet address, a conventional user would have to connect to the Internet via, for example, a conventional GSM device which involves additional costs and additional time. Accordingly, WAP-Bluetooth server 140 provides a service that uses both WAP and Bluetooth to mediate location-specific information to a WAP-Bluetooth terminal 130 which while illustrated as, for example, a cellular phone, may also take the form of a PDA or like device for providing, for example, mobile Internet or additional integrated services. With reference to FIG 2, consisting of FIG 2A and FIG 2B, a more detailed entity relationship diagram is shown illustrating comprehensive WAP-Bluetooth service provision and application development environment 200. Details of hardware and software operation in accordance with exemplary embodiments of the present invention are further illustrated. At bottom, power supply 221 represents the hardware needed to generate a minimum regulated voltage of 3.3V that all circuits may use. Power supply 221 may further operate with input voltages of between 4.5 and 12V and will preferably not be damaged if input polarity is reversed or if input voltage rises as high as 30V. Reset circuitry 222 may be provided and may be responsible for forcing hardware into a known and well-defined startup state when power supply voltage rises to over 3.1V. An active low reset signal, for example, may be distributed to any hardware within the WAP-Bluetooth server such as, for example, a CPU, a Bluetooth transceiver module (hereinafter referred to as "Bluetooth interface"), and FLASH memory. Init 223 may be software executed by bootloader 233 immediately after start-up from reset. Init 223 may perform basic setup of, for example, WAP- Bluetooth server hardware environment 220, e.g. setting up connections to memories and the like. It should be noted that since bootloader 233 itself may reside in an external FLASH memory, the FLASH memory must be connected so that it can be reached during start-up before init 223 software has set up any chip- selects. As part of init 223 process, status LED 211 may be turned on in order to indicate to a user that valid power is present in the system. Further as part of init 223, basic hardware tests may be performed in power-on self test 226. Any errors found may be communicated as error indication 227. The unit may attempt to continue with operation if only minor errors are found, but major errors will result in a halt attempt.

After init 223 has executed with no serious errors, SW integrity test 225 may be performed including, for example, a memory integrity check of the WAP- Bluetooth application software load. Accordingly, a checksum may be calculated over the stored application and compared with a separately stored checksum stored when the application was downloaded. If a checksum error is found, process execution will remain within bootloader 233, without launching the erroneous application. If errors are found during SW integrity check 225 a coarse indication of the cause of the error may be indicated to the user by flashing the LED in accordance with different error types. Error types may be indicated by use of a different number of flashes for each error and preferably only the most severe may be indicated if multiple errors have been found. It should be noted that such indication may not be applicable if the LED itself is the cause of the error.

RS232 port 228 may be provided for serial connection. Included in RS232 port 228 may be, for example, an advanced buffered UART which may be built- into the CPU, and an, for example, an external RS232 transceiver which handles the conversion between electrical RS232 levels and logical 3.3V signal levels. RS232 port 228 circuitry may also includes some filtering facilities in order to avoid/suppress EMC/ESD problems. It should be noted that RS232 port 228 hardware may preferably be designed to operate at up to 115.2 kbps. A set of serial drivers 230 may also be needed to communicate over the serial line. By default, the serial line should be set up for standard asynchronous communication, such as, for example, 8 data bits, no parity bits, 1 stop bit, 9600 bps. It should further be noted that bootloader 233 may communicate with, for example, maintenance application 234 using a simple bootloader protocol 235.

If a valid WAP-Bluetooth application is present in FLASH memory, and if no connection from a maintenance tool has been established, a WAP-Bluetooth application may be launched after a well-defined time after start-up. The purpose of the time delay is that a malfunctioning application might fail to enter the bootloader upon request from a maintenance tool. Therefore there may be a time- window at start-up where the maintenance tool can connect with bootloader 233 before the WAP-Bluetooth application is launched. The CPU in an exemplary WAP-Bluetooth server may further feature an advanced timer driver 231.

However, in order to make full use it, some additional software drivers may be required. FLASH drivers 232 may be stored in bootloader 233 to be protected, so that a malfunctioning application cannot by accident erase itself. Furthermore, the sector in which bootloader 233 is stored may be hardware protected so that no software will be able to erase it accidentally. In order to write or erase sectors in a FLASH memory, special software drivers are required. A special characteristic of FLASH programming is that FLASH drivers 232 cannot be executed from the same memory chip that it attempts to write/erase in. Therefore, FLASH drivers

232 must be copied from the FLASH into the RAM before it is used. As will be appreciated by those skilled in the art, bootloader 233 is a small standalone application responsible for basic HW initialization, basic system testing, and for launching the WAP-Bluetooth application. Optionally, the administrator can update or replace the WAP-Bluetooth application by downloading new data to the device using a serial Bootloader Protocol. Bootloader 233 may be stored in a dedicated sector of FLASH memory, which may be possible to boot from during start-up. It should be noted that bootloader

233 may be programmed into WAP-Bluetooth server as part of the manufacturing process. It should also be noted again that bootloader 233 may be protected so that it cannot be accidentally overwritten by the applications software. In addition to bootloader 233, eCos 295 may be used for low level operation. ECos 295 may preferably be an open-source, royalty-free, highly configurable, operating system ideal for embedded systems. In accordance with supporting a WAP-Bluetooth application, eCos 295 operating system may provide support for different kinds of hardware, e.g. serial device drivers and may be considered to be a vital part of SDK 280, making it easier for third party developers to develop applications. In addition, eCos 295 makes it easier to port, for example, Bluetooth stack 290 to a WAP-Bluetooth server because it implements components such as threads, mutexes and timers. Accordingly, eCos makes it easier to extend WAP-Bluetooth server functionality, e.g. by adding a TCP/IP stack or the like.

Host Controller Interface (HCI) 294 is an additional part of Bluetooth stack 290. HCI 294 may provide a uniform interface between the Host and Bluetooth Hardware, i.e. the Link Manager in the Bluetooth hardware. HCI 294 also provides transparency, e.g. the same Host software may be used on different hardware, e.g. RS232 and USB. Service Discovery Protocol (SDP) 291 is yet another part of Bluetooth stack 290. SDP 291 may provide the ability, for example, for terminal applications to discover the existence of services provided by server applications. WAP-Bluetooth server is a typical server application providing service to terminals. It should be noted however that the use of SDP

291 might be restricted in initial versions of WAP-Bluetooth server because of the lack of a WAP-over-Bluetooth profile. Logical Link Control and Adaptation Protocol (L2CAP) 293 is yet another part of Bluetooth stack 290. L2CAP 293 provides the capability for: protocol multiplexing, e.g. enables usage of several higher layer protocols; segmentation and reassembly, e.g. may segment higher layer protocols packets; guaranteeing quality of service, e.g. negotiates QoS contracts. RFCOMM 292 is still another part of Bluetooth stack 290. RFCOMM

292 simulates a simple serial cable replacement between two Bluetooth devices. It should be noted that a WAP-Bluetooth server in accordance with the present invention may use up to seven instances of RFCOMM 292 component to simulate serial communication with up to seven terminals. It should further be noted that in an exemplary WAP-Bluetooth application WAP information may be stored together with the application, for example, as linked in the maintenance application or may be stored separately from the application. If WAP information is stored separately, a WAP-Bluetooth server in accordance with exemplary embodiments of the present invention preferably requires a FLASH memory file system. Such a component simulates a file system, e.g. using functions such as open file, write to file and close file, using a FLASH memory. In order to provide a graphical user interface for exemplary application

270, the Microsoft Windows version of SDK 280 may preferably be using CygWin development environment 275 preferably consisting of parts of the popular GNU development tools and utilities for Windows NT and 9x. CygWin development environment 275 may be available without charge and its components are covered by a number of different licenses, e.g. GPL and public domain.

Accordingly, binutils 271 is a set of small basic tools to manipulate binary, e.g. object and library files for the target platform. In addition, GNU Compiler Collection (gcc) 272 may include C and C+ + crosscompilers for the CPU in the WAP-Bluetooth hardware, e.g. ARM7TDMI processor. Gcc 272 may also include a linker, capable of linking relocatable object modules into located ELF binaries. Gdb/insight 273 is preferably a text-mode cross-debugger, which may either be used for simulation of the target environment, or for remote debugging of the WAP-Bluetooth hardware. Remote debugging can be done either by using a low-cost serial RS232 connection in conjunction with a gdb stub 274 as will be described in greater detail herein below, or by connecting through a high- performance JTAG debugger directly to the hardware emulation facilities built-into the CPU core of the WAP-Bluetooth hardware. Insight is a convenient and powerful graphical user interface to the gdb. There are a number of graphical interfaces to gdb to choose from, but one advantage with the Insight user interface is that it is portable to both Windows and Unix platforms. For remote serial debugging of WAP-Bluetooth hardware, gdb/insight 273 preferably requires communication with a software monitor running in the target hardware called a stub, and may preferably be either a stand-alone application, or may be linked into the debugged application. In an exemplary WAP-Bluetooth server in accordance with the present invention, gdbstub 274 may be linked, for example, into bootloader 233, and may also be supplied as code in SDK 280 to link into the WAP-Bluetooth application.

The CPU in a WAP-Bluetooth server in accordance with the present invention may preferably be a 32-bit RISC architecture such as may be available, for example, from ARM Ltd. Such a CPU may have the ability to execute code in either an "ARM" 32-bit mode, or in a "Thumb" 16-bit mode. Since advantages and disadvantages exist with running in either mode, SDK 280 may preferably be designed to support both ARM and Thumb modes in the form of toolset 283. In accordance with documentation 282 provided with SDK 280, examples 281 may be provided containing well-structured and commented source code, and documentation e.g. README files. The purpose of examples 281 is to make it easy for the third party developer to get started developing applications for the WAP-Bluetooth hardware. Simple examples 281 will include, for example, getting the LED to blink, while complex examples 281 include a WAP-Bluetooth application itself. The amount of work necessary to understand examples 281 will be less than trying to understand the WAP-Bluetooth application directly if made only from coarse specifications. It should be noted that the supplier of the WAP- Bluetooth server hardware may preferably provide examples 281 written in a manner and to a standard most conducive to eventual certification of third party software as will be described in greater detail hereinafter.

As previously noted, SDK 280 may preferably contain a GNU development environment, SW components and Documentation 282 for example including installation and operation and may further include some examples and Application Notes. GNU toolset 283 may be designed for use in multiple development platform environments including, for example, WinNT and Linux as main targets. It should be noted however that other Win32-and UNIX-platforms may also be expected to serve as suitable development platforms. As an option, an application may be provided for servicing the WAP-Bluetooth device, it includes functions for downloading binary WAP-pages onto the WAP-Bluetooth device. Signed applets 218 may be provided in which, for example, a Java script may be granted special privileges by a browser, such as the ability to read and write local files, not normally available to untrusted applets. Signed applets 218 may implement the functionality described in the sections below related to the WML Templates 219a and WAP/WML Compiler 219b

As the name implies, WML Templates 219a may be used for creating WAP- pages. Moreover, WAP/WML Compiler 219b may be a compiler for WAP-pages which converts pages written in WML to binary WAP-format which may then be loaded onto a WAP-Bluetooth server device. Outer casing 217 may be provided which protects the WAP-Bluetooth server circuit board and gives an attractive impression of the device. It should further be noted that the outer casing may provide functional and non-functional features as may be further described in copending design application number D00828, supra. It should be noted that it may be further desirable to provide examples 281 including source code examples of how to make file transmission to PDAs and related mobile terminals as a standard part of SDK 280. Thus in accordance with various embodiments of the present invention, it is envisioned that third party SW application developers may be involved in an early stage in the initial release of WAP-Bluetooth server hardware in order to create a base 282 of quality applications that may be of interest to customers wanting to provide a particular service using the WAP-Bluetooth server as a delivery platform. Resources 283 may further be provided for third party developers, such as SW downloads of around 50K in size. It should be noted that further in accordance with the present invention, WAP-Bluetooth server may create new business 284 for third party SW developers. Provisions of SDKs interaction of third party developers with each other through the website and the like may be provided as according to a business method further described in copending application number 040042-003, supra. Special features at, for example, a proprietary web site 250, such as promotion for third party developers applications, news group and the like may have the benefit of stimulating the growth of developer community 259. Accordingly, web site 250 for application developers for WAP-Bluetooth server may include information about when WAP-Bluetooth is available for user's and third party application developers and the like. In addition, single session 213 Bluetooth data transfer may include transfer between a WAP-Bluetooth server and one mobile terminal. This functionality will use the RFCOMM layer to simulate a simple serial cable replacement between two devices. WAP-Bluetooth server must not be able to connect automatically to the mobile terminal and is preferably hard coded. Multi session 212 Bluetooth data transfer may include transfer between WAP- Bluetooth server and several terminals. Accordingly, WAP-Bluetooth server must not be able to connect automatically to new terminals entering the area and, for example, connections with terminals can be hard coded. Each mobile terminal may be sent the same WAP contents upon request. In alternative exemplary embodiments in accordance with the present invention, WAP-Bluetooth server may automatically establish a connection with Bluetooth mobile terminals or other WAP-Bluetooth servers entering the area of reception, as long as the total number of connected devices do not exceed the maximum number which can be services by one WAP-Bluetooth server which is preferably seven. It will be appreciated that several WAP-Bluetooth servers may be ganged together within the same premise for providing additional capacity for terminal service. Mobile Bluetooth terminals leaving the service area will automatically be disconnected. Upon connection, each new mobile Bluetooth terminal may be sent the same WAP contents. It should be noted that when the WAP-over-Bluetooth profile is completed, WAP-Bluetooth server will try to contact any terminal with WAP capability, but before that WAP-Bluetooth will only try to contact certain specified terminals identified as having, for example, WAP-Bluetooth capabilities. It should further be noted that included in the terminals serviced by the WAP-Bluetooth server may be other WAP-Bluetooth servers in the context of, for example, a scatternet configuration or industrial application covering sectors of a larger area, or similar applications in commercial and private categories.

As previously noted, the status of the WAP-Bluetooth application may be indicated with status LED 211. For example status LED 211 might signal contact with a mobile Bluetooth terminal by blinking with a high frequency and further may signal that it is waiting for a mobile Bluetooth terminal to get in to reach with a low frequency blink.

Because the WAP standard is not complete and certain mobile terminals such as, for example, cellular phones do not support "WAP push" WAP-Bluetooth server will use a function called AT command 214 to push the web page into the unsupported device with, for example, LUKAS blocks. WAP push 215 may provide functionality for pushing WAP web pages onto other terminals. It should be noted that WAP-Bluetooth system 252 may be provided in accordance with the present invention and may include: WAP-Bluetooth server hardware 220, web site 250, a WAP-Bluetooth application 270, 210 for transferring binary WAP-pages to WAP-Bluetooth devices, and SDK 280. User manual 251 may further be provided for the WAP-Bluetooth system 252, describing how to use, for example, WAP- Bluetooth server hardware 220 with a default software application for, for example, sending web pages to WAP-Bluetooth terminals. It should be noted that user manual 251 is preferably not intended as a detailed developer manual for the third party application developers.

Thus in accordance with the present invention, by enabling new applications carried by WAP-Bluetooth server hardware 220, a demand 253 for WAP-Bluetooth equipped terminals may be generated and thus enabling the terminal owner to benefit 254 from the applications and further increasing the demand for WAP-Bluetooth server hardware 220. WAP-Bluetooth will enable information push 255 from information supplier to terminal owners. By enabling information push 255, e.g. wireless distribution of services, WAP-Bluetooth will be able to promote the owners business 257. Moreover, new applications carried by WAP-Bluetooth provide services which, again benefit 254 to the user and the provider. WAP-Bluetooth through appearance and performance, generates 256 a desire to own WAP-Bluetooth related hardware. It should further be noted that possession of, for example, a WAP-Bluetooth mobile terminal or a WAP- Bluetooth server may have increased social value 258.

It should be again noted that only a basic WAP-Bluetooth application may be developed and provided as part of the standard delivery of a WAP-Bluetooth server. Instead, third party developers are preferably encouraged to develop applications geared toward enhancing the value of WAP-Bluetooth servers and systems to customers. In this context, a number of different entities might be regarded as a third party developers for the WAP-Bluetooth server in accordance with the present invention. For example, companies working professionally developing applications for various wireless devices such as for example, wireless organizers presently known as, 3Com, Palm Pilot, and the like may be considered. OEM entities who are buying a WAP-Bluetooth server and extend and/or exchange the application to suit their customers needs. Advanced end-users, extending or completely designing then own applications for their own personal needs. Free-software organizations, developing software that could be downloaded for free over the Internet.

Third party developers therefore may be categorized generally into three main categories: business developers, private developers, and industry developers. Examples of different groups may include, for the business category: local broadcast of shopping information such as, for example, WAP-Bluetooth servers placed within the produce and/or meat sections of a grocery store indicating information related to the product in the vicinity of the server. Freshness of products, origin of products, anticipated dates of next shipments and the like may be provided to a proximate user. In the private category, a home voice mail post which could indicate to users proximate to a private developer's home when the private developer might return, the location of the private developer and the like could be provided. It should be noted however that it may be desirable to protect such information using a password or other user identification in order not to provide strangers with overly sensitive information regarding the homeowner's whereabouts. In addition it should be noted that separate business applications may be provided to allow private developers to do private development. In other words, using the above example, a business development application might include a home voice mail port development kit which makes development easier for a private user. Alternatively, sophisticated private users might be able to use the basic WAP- Bluetooth application and SDK to do development. Other examples of private developer applications might include personal agents for filtering information provided by WAP-Bluetooth servers. For example, if a user is a vegetarian it may be desirable for a user to exclude location-dependent information related to meat products.

Additionally the industry category might include, for example, a robotics control application using one or more WAP-Bluetooth servers. Such industry applications could be developed as a joint effort or may be developed solely by the equipment provider or industrial developer customer. Accordingly, a number of advantages have been identified by using such a strategy for the development and distribution of third-party software. Many available applications for a wide number of different use-cases will encourage the sales of WAP-Bluetooth devices of every kind. Applications may be developed without excessively burdening the hardware provider's development organization. Advanced application areas where a hardware provider has no strategic interest could be developed enhancing demand for hardware without the hardware provider having to gain competence in those specific areas.

The open source software paradigm which has evolved during a number of years within, for example, the software development community, is now gaining an increasing amount of momentum and attention generally within industry. The details of the open source concept has grown rather complex, and may be appreciated more fully with reference to several widely available publications. Thus in accordance with the present invention, tools used to develop all software within the WAP-Bluetooth development environment are preferably open source. Tools are preferably known and used by a large developer community, and preferably have a reputation of being products of high quality. Thus software platform components shipped within, for example, SDK 280 are preferably open source. For example, if suitable open source components are available, for example, on the Internet, such components are preferably used in the WAP- Bluetooth development environment rather than custom components, although custom development is possible. By offering open source software costs for third party developers may be decrease for application development for WAP-Bluetooth devices enabling increasingly larger third party development efforts. Other benefits such as quick time-to-market may be realized.

It should be noted that within open source aware user groups, open source software products developed today often experience considerable goodwill benefits, compared to products developed and marketed in more traditional ways. Related products therefore may be potentially easier to market and sell simply by providing the product with open source. In addition, user groups may be more patient in awaiting the release of software with extended functionality and may be even more tolerant of bugs and errors within the system with the expectation that open source software allows bugs to be fixed more easily. As a consequence, an open source product could be brought to market earlier in the development phase by bypassing a large amount of development and testing before being acceptable to the user community. It should be noted however that in accordance with the present invention the WAP-Bluetooth standard will be TG4 compatible.

It should further be noted that while Bluetooth provides for ad hoc- networking such as scatternet, the WAP-Bluetooth server is preferably not configured for ad-hoc networking in general although ad-hoc configurations may be useful in some applications. It should still further be noted that hardware associated with a WAP-Bluetooth server in accordance with the present invention may be configured depending on the size of the WAP-Bluetooth application to be developed. For example, the WAP-Bluetooth hardware may be designed for later add-on extensions to memory size and the like. As there is no comprehensive standard for WAP-Bluetooth, no one general solution will support all potential clients. Therefore, it is preferable to support a few clients although it should be noted that application developers may be inclined and are in fact encouraged to support as many different clients as possible.

It should be noted that while two way communication is possible, one-way communication is preferably supported by the WAP-Bluetooth server, i.e. WAP- pages may be pushed onto a mobile WAP-Bluetooth terminal or client; while the WAP-Bluetooth client will not be able to, for example, search the Internet through the WAP-Bluetooth server.

As illustrated in FIG 3 and FIG 4, WAP-Bluetooth hardware is preferably built from several primary functional blocks. In order to maintain a degree of similarity in performance, a WAP-Bluetooth server in accordance with the present invention may include Bluetooth radio module 321 for providing a standard Bluetooth interface 320. Further included is a set of low-level Bluetooth protocol parts (the "baseband") available as a software library, which is described in greater detail hereinafter and may be executed preferably in specially designed ARM7TOMI RISC-based baseband /^-controller 322 from standard baseband FLASH memory 323. Bluetooth interface 320 may be provided as a standard module and may be connected to external Bluetooth antenna 310 such that the antenna is not part of the module, and is preferably connected to "master" CPU 330 via either a USB or via standard asynchronous serial connection 324 at up to 460.8 kbps. USB may be provided preferably for interfacing larger systems such as, for example, PCs, whereas serial connection 324 is preferably used within embedded systems. It should be noted that in accordance with various embodiments of the present invention Bluetooth radio module 321 and baseband protocol software will preferably be available as separate stand alone products. By using integrated Bluetooth interface 320 as a core design component and connecting it to, for example, master CPU 330 via serial connection 324, complex and unnecessary USB master circuitry may be avoided. It should be noted that the Basic WAP-Bluetooth application preferably provided in accordance with the present invention probably requires only moderate communication speeds, but the hardware design should nevertheless be capable of communicating with Bluetooth interface 320 at up to 460.8 kbps in order not to hmit the bandwidth requirements of any third-party applications.

It should be noted that Bluetooth antenna 310 for Bluetooth interface 320 may be designed in some different ways. Two ways for antenna 310 to be provided for a WAP-Bluetooth server in accordance with the present invention include an antenna provided as a pattern etched directly into PCB 300, or to use an existing

Bluetooth antenna "component" as will be illustrated hereinafter. It should be noted that the etched antenna is potentially the most cost-effective solution at virtually zero cost, but may have some drawbacks. An etched antenna may require more PCB space, and could require additional effort to correctly adapt the correct lobe characteristics. With regard to an antenna component, a simple passive component, which is small, cheap and fairly simple to fit into other designs may be used. Since such a component is small, cheap and preferably already available use of it minimizes risks associated with realizing the antenna directly into the PCB. It should be noted that baseband controller 322 in Bluetooth interface 320 does not permit user-mode applications to be executed on it. Therefore, master CPU 330 may be required for executing embedded applications, e.g. the Basic WAP-Bluetooth Application or any third party applications. A major requirement for master CPU 330 includes adequate processing-power capabilities to accommodate any possible third-party application processing needs. In addition, master CPU 330 should be supported by RS232 interface 335 which may include 2 built-in UARTs to avoid external components for interfacing to Bluetooth interface 320 and RS232 interface 335. To avoid excessive CPU load when running the serial channels at high speeds, the UARTs should be buffered. Master CPU 330 may further preferably be supported by a powerful and high-quality toolset which may be bundled in the SDK without added cost, and should be available as open-source. The family of master CPU 330 should preferably be easily adaptable and portable to possible future adaptations and should preferably be a member of a family of processors supporting various optional on-chip memory configurations, including both RAM and FLASH memory variants. A number of candidates for master CPU 330 are available on the present processor market, however, one specific processor has been identified as an almost ideal candidate for a WAP-Bluetooth server in accordance with the present invention, namely the AT91 x40xxx manufactured by the Atmel Corporation of San Jose.

The Atmel controller family is built around the same processor core as baseband μ-controller 322 in Bluetooth interface 320 providing an advantage in that porting software to possible future processor versions should be greatly simplified. Moreover, the core of the AT91 x40xxx is a high-performance 32-bit RISC, which should offer more than enough processing power for the types of functionality expected in WAP-Bluetooth applications. Ideally, the choice of master CPU 330 should be a low-power low-cost design and should offer an excellent code density, i.e. should have low memory requirements for code storage. The AT91 x40xxx family provides such features through its 16-bit "Thumb" instruction set. In addition, fairly inexpensive commercial toolsets are available from ARM, but open- source toolset are also available such as, for example, the GNU cross-compiler tools, which are well recognized for its high-quality and efficiency. In addition, the Atmel AT9I family includes 2 advanced buffered high-speed UARTS built-in, and has various available options for on-chip RAM and FLASH memories. More specifically, a variant which may be preferably for a WAP-Bluetooth server in accordance with the present invention is the AT9I R40807 made by Atmel Corporation of San Jose which features 136kB of zero-waitstate 32-bit on-chip

SRAM, but without internal ROM/FLASH. On-chip memory of up to 2Mbytes of dual-plane FLASH and, as mentioned, 136Kbytes of SRAM are included however, it is difficult to predict how much memory will be adequate for Basic WAP- Bluetooth applications and third-party applications will preferably require more. In order not to limit possibilities for third-party applications over-provisioning of both external RAM and FLASH memories is preferred.

It should be noted that FLASH memories are generally known to have bad availability for purchasing from time to time, therefore it is preferred that the final choice of FLASH memory be made together with any manufacturing sub-suppliers responsible for purchasing FLASH in the required quantities. One choice for

FLASH is a 4Mbyte 16 bit-wide in-system-programmable single-plane flash made by Intel Corporation. Such FLASH features a hardware-protectable Boot block which is very well-suited for placement of a bootloader and features a number of 64Kbytes sectors capable of 100.000 erase/write cycles well-suited for both application and data storage, as well as a set of smaller sectors suited for EEPROM- emulation and device parameter storage, e.g. serial number, Mipv6 address, and the like. In order to avoid complicated DRAM refresh circuitry, external SRAM 332 is preferred. External SRAM devices however are unusual in sizes over 512Kbytes, and most are available only in 8-bit wide devices. Therefore, it is preferred that 2 pieces of 8-bit 51 2Kbytes SRAMs are used, resulting in a 1Mbyte 16-bit wide external SRAM. Since another 136Kbytes of zero-waitstate 32-bit SRAM is preferably available on master CPU 330, external SRAM 332 need not be of the fastest and thus most costly type. Instead, standard low-cost 70ns types should be enough. RS232 interface 335 is preferably intended for use between a WAP- Bluetooth server and a host-PC, and should preferably comply with RS232 electrical standards. Compliance could easily and effectively be accomplished by using, for example, a RS232 level converter server, such as, for example, the MAX32xx provided by Maxim Corporation including, for example, a small set of external passive components such as capacitors for charge-pumps. RS232 interface 335 connector should be designed so that a cheap standard "straight-through" serial cable can be used. Accordingly the connector on a WAP-Bluetooth server should preferably be, for example, a 9-pin female D-sub, pin-configured as a DCE. Since the UARTs which are preferably built into master CPU 330, are of preferably of an advanced buffering type, the use of hardware handshake control lines, i.e. RTS/CTS may be omitted. A WAP-Bluetooth server therefore will preferably always be capable of receiving an uninterrupted stream of high-speed serial data. However, it should be noted that to enable communication with a host configured for hardware handshaking, the RTS/CTS lines should be bridged just behind the connector as is known in the art. Accordingly, the bundled serial cable could preferably be of the absolutely cheapest and lightest type; a straight through cable with only three conductors. It should be noted that the typical 'non-industrial" working conditions of a WAP-Bluetooth server does not motivate the need for a costly galvanically isolated RS232 interface, but rather that the built-in ESD protection of a typical interface will be sufficient. However, to protect both server and environment from through cable transmitted EMC, separate filter components on all connected lines are preferred. As a result of highly software-configurable I/O structure preferable in master CPU 330, hardware required to support an auto-baudrate software feature, i.e. pulsewidth timing measurement, should preferably be present without added extra cost.

As previously described, one single-color LED is preferably require to be used in a WAP-Bluetooth server in accordance with the present invention. Such an LED may be used to indicate to a user a number of conditions such as, for example, Power-on, Failure, State-of-operation and the like. While the color of the LED can be flexible, it is preferably - blue. The LED is preferably a surface mounted component however a hole fitted or light conducted alternatives could also be used depending on the mechanical design. Since the LED is intended for multi-purpose use, it should be under software control, i.e. it should be controlled from an output pin of master CPU 330. Except for using outputs as normal "state-controlled" outputs, a processor for master CPU 330 in accordance with the present invention may preferably features that output pins could also be under timer-control such that an LED could be flashed at a controlled frequency with on-chip timer support. Further, the intensity of the LED could conveniently be adjusted by using the timer to, for example, PWM-control the LED as is known in the art.

Since a WAP-Bluetooth server might be marketed in a number of countries with varying high- voltage regulations, it is preferred that an external high- voltage power supply 340 be used purchased off-the-shelf and bundled as part of the WAP- Bluetooth server delivery without any further modifications. However, it could be foreseen that a WAP-Bluetooth server might be used in more than one place. For example, a WAP-Bluetooth server could normally be used in a shopping area, but for maintenance it could be brought into an office to connect to a PC. Therefore, it would be preferable to accommodate standard power supplies. Standard power supplies however come in different voltages of typically 4.5 to 12V, and with different polarity in the power plugs. The circuits in the WAP-Bluetooth server hardware require a stabilized 3.3V to operate correctly. Therefore voltage regulation within the WAP-Bluetooth server would be preferred. Accordingly, it is preferred that an internal power supply capable of transforming cheap unstabihzed 4.5 to 12V input voltages to a stable 3.3V on-board voltage is used. Maximum current required by a WAP-Bluetooth server may be in the range of 300mA. However, at times

Bluetooth interface 320 may use approx 300mA itself, while 50mA is specified as typical. Thus to avoid an under dimensioned power supply, a top current of approximately 500mA is preferred. While a simple linear voltage regulator is normally the cheapest choice for line-powered designs, such a regulator might be quite hot when delivering 3.3V from 12V in the 500mA range. In order therefore to avoid unnecessary heating, a switching-mode regulator is preferred. Such regulators are available from a number of manufacturers and may be supported by only a small number of external components. The power connector for power supply 340 may preferably be a standard 2.1mm power connector, with positive power connected to the center of the connector which is the most usual configuration found. The input to power supply 340 should be equipped with protection for reversed polarity and over voltage inputs. Protection for abnormal current consumption, e.g. an automatically "healing" Polyfuse, and ESD protection including through cable transmitted EMC should also preferably be included.

For the Printed Circuit Board (PCB) it is preferred that one single PCB be used where all components may be mounted with the possible exception of the LED. Since it can be foreseen that future adaptations of the WAP-Bluetooth server will decrease the need for PCB space because of revisions, PCB space should not be over dimensioned space limitations should preferably be addressed using multilayer boards, e.g. 4- or 6-layer PCBs, and/or double-sided mounting. Since the material in the PCB could influence the characteristics of the Bluetooth antenna, cheaper PCB materials should be avoided. Therefore, the PCB material should be approved by, for example, RF-design specialists and should be suitable for optimal RF characteristics. In addition, for production testing purposes, important network nodes should be available on PCB 399 for test pins, as well as Vdd and ground points. In order to get the circuitry into a well-defined startup state after power-up, a reset-generating voltage supervising server should be used. The reset should be routed to master control 330, FLASH memory 331, and Bluetooth interface 320. It should further be noted that the core of baseband μ- controller 322 preferably features built-in support for JTAG debugging, using a standardized 2x10 pin connector. Though not needed for normal use, such a debugging feature may be highly valuable for advanced error-tracing and debugging of prototypes. However, since a 2x10 pin connector would occupy unnecessarily PCB space, it is preferred that the debugging lines are made available as "pads" on the PCB, so that a JTAG connector could easily be soldered in by hand when needed. If EMC testing shows that too much energy is radiated, the PCB should be mounted a shielded enclosure. Shielding should preferably cover the power supply 340, the master CPU 330, Bluetooth interface 320 and external memories 331 and 332, since these components are anticipated to be potential problem sources of radiated emissions. However, if the EMC test indicates that shielding is not needed, the shield should not be mounted in order so save component and manufacturing cost. It is important to note that as illustrated in FIG 4, various components of a

WAP-Bluetooth server in accordance with the present invention could be integrated into ASIC 420. For example baseband controller 422, and FLASH 420 could be integrated together. Radio interface 430, power supply 440, antenna 410, LED 423, and RS232 port 450 could be provided as external components on PCB 400. Operation would be virtually the same as described herein above with reference to FIG 3 with the possibility of improvements in speed and the like that normally accompany such integration.

In order to provide Bluetooth capability in accordance with the present invention, WAP-Bluetooth server may be provided with software features as described herein below. Since the WAP-Bluetooth server is preferably intended to provide a software development platform for third parties, limited WAP capability is provided. Such capability may preferably be provided by third party applications. The goals of the software envhonment preferably make it possible to download new software, to use as much open source software as possible, and the like. The software envhonment may be divided into the following components as illustrated in FIG 5 A. The three basic components are: basic WAP-Bluetooth application 520, software platform 510, and boot loader 530.

Basic WAP-Bluetooth application 520 may implement the WAP functionality of the WAP-Bluetooth server software package. The purpose of Basic WAP-Bluetooth application 520 is preferably to implement enough functionality to make a WAP-Bluetooth server an appealing product out-of-the-box, but may also serve as an application example for third party developers. The functionality of basic WAP-Bluetooth application 520 is preferably to establish contact with WAP capable clients using Bluetooth stack 513, when such clients enter within the range of Bluetooth interface 320. Basic WAP-Bluetooth application 520 may further send static WAP information to clients stored together with the application in, for example, WMLC format, i.e. precompiled WAP binary format. Basic WAP- Bluetooth application 520 may further provide for disconnecting from clients when static information has been sent. Basic WAP-Bluetooth application may still further support downloading of WAP information by implementing a downloading protocol enabling a host to download individual WMLC files. If a new file is downloaded, the previous file is overwritten. This functionality may be provided in basic WAP-Bluetooth application 520 such that third party developers may implement a more advanced file system without changing the bootloader. Basic WAP-Bluetooth application 520 may further support reset of the WAP-Bluetooth server and preferably needs to be able to receive a RESET command and pass it to the bootloader. Otherwise, a customer may have to manually reset the WAP- Bluetooth server when downloading new applications, for example, from the WAP-Bluetooth website.

It should be noted that, as previously described, a WAP-Bluetooth server is preferably limited to contact with seven clients simultaneously which limitation derives directly from the Bluetooth standard, supra. Morever, a limited number of different WAP clients may be supported by basic WAP-Bluetooth application 520 with the number expected to increase as specific information on how to establish a connection with each WAP client is provided on establishing contact with, for example, Ericsson WAP clients, Nokia WAP clients, and the like. It should further be noted that basic WAP-Bluetooth application 520 is preferably configured to support only enough of the WAP protocol to be able to send static WAP information to the WAP client. Basic WAP-Bluetooth application 520 is preferably written in a version of ANSI C licensed using a open source license, e.g. GPL, to be included in the SDK.

Software platform 510 preferably implements the core functionality of the WAP-Bluetooth server software package, i.e. the ability to communication using Bluetooth. Software platform 510 thus is expected to be used by most third party developers who are attracted by Bluetooth capabilities associated with the WAP- Bluetooth server. Bluetooth stack 513 is preferably an open source implementation of a Bluetooth stack such as the AXIS Bluetooth stack provided as part of open source Linux operating system. The AXIS Bluetooth stack was originally developed by Axis Communication and will preferably be ported to eCos operating system 512, which may be an eCos operating system. For additional information see: developer.axis.com/software/Bluetooth. Bluetooth stack 513 preferably includes HCI, 2CAP, SDP, and RFCOMM layers and may be written in ANSI C and may further be licensed using GPL (the copy holder being Axis Communications) and may be included in the SDK.

Operating system 512 as previously indicated is preferably eCos, a highly configurable embedded open source operating system developed by Cygnus, currently owned by Red Hat. Using eCos does not directly add any end customer value, but may be included to assist third party developers during development of applications to the WAP-Bluetooth server. For more information see: sourceware.cygnus.com/ecos . Operating system 512 may further preferably provide standard operating system features, such as threads, timers and queues, drivers for hardware, e.g. the serial communication port and the like. Operating system 512 preferably supports master CPU 330 in general but eCos may not support, for example, the ATMEL ATM7TDI processor. eCos will preferably be configured to support this processor with help from the open source community. eCos is licensed using RHEPL (Red Hat eCos Public License) and may further be included in the SDK. The RHEPL license is a slightly stricter version of GPL, e.g. it gives the provider the right to distribute applications using eCos without releasing the source code.

The WAP-Bluetooth server software package further preferably provides drivers 511 for different hardware, e.g FLASH memory. To provide a well defined interface between upper layer software, e.g. eCos and WAP-Bluetooth server hardware, drivers 511 are preferably accessible to third party developers even if they decide, for example, not to use the eCos operating system. Drivers 511 are preferably written in ANSI C, may be licensed by GPL with the hardware provider as the copy holder, and are preferably included in the SDK. Bootloader 530 is preferably a small standalone application residing in

FLASH memory and may be responsible for, for example, initializing the WAP- Bluetooth server, e.g. memory setup and the like, performing basic error detection, e.g. memory check and the like, downloading new applications into RAM, saving applications from RAM to FLASH, and starting the currently stored application. Bootloader 530 preferably has knowledge of memory map 540 of the WAP-Bluetooth server as is illustrated in FIG 5B.

Accordingly, as shown, data area 541 may include starting address 0x40 00 00 hexadecimal and may end at Address 546, which address may be configurable by a developer. Memory map 540 may further include application area 548, configuration area 543, and boot area 544 which may be configured at base address 545 at address 0x00 00 00 hexadecimal.

Boot area 544 may be configured to hold bootloader 530 itself and may be protected by hardware and thus cannot be updated. Configuration area 543 may hold configuration parameters, such as, for example, part numbers, user identification, and the like. Configuration area 543 may be updated by bootloader 530. Application area 542 may be configured to hold one application. If a developer upgrades the application, the prior application may be overwritten. Application area 542 may be updated by bootloader 530. Data area 541 is preferably unreachable from bootloader 530 and may be updated by the application. Accordingly, it may be possible for third party developers to implement flash file systems on the WAP-Bluetooth server.

It should be noted that the individual sizes of the application and data areas are configurable by software making it possible to have different WAP-Bluetooth configuration depending on the application with some third party applications needing a greater amount of data area 541 and other applications needing greater amounts of application area 542. Bootloader 530 may preferably communicate with the development platform using a bootloader protocol. Bootloader 530 may also contain a gdb stub as previously described making it easy for third party developers to debug applications using the gdb debugger. Bootloader 530 may be written in ANSI C and may be provided as part of the SDK.

In addition to providing a WAP-Bluetooth server in accordance with the present invention a web site may be included within the overall system WAP- Bluetooth architecture. To build a substantial developer community around the WAP-Bluetooth server as a product, a developer's website, e.g. developer. WAP- Bluetooth.com containing, for example, a project charter, i.e. a description of the WAP-Bluetooth project, downloadable software packages, a third-party developer mailing list, FAQs, project documentation in HTML format, links to related sites, and the like, is preferable. The WAP-Bluetooth web site preferably has two target groups including WAP-Bluetooth application users and third party developers. The basic WAP-Bluetooth application 520 will preferably be supported as a proprietary product however maintenance and support of the WAP-Bluetooth SDK will also be provided, for example, by email notification and through the web site. It should be noted however that third party developers are preferably expected to contribute material and peer support. Further in accordance with exemplary embodiments of the present invention, third party applications will not be supported by the equipment provider. The WAP-Bluetooth web site is preferably the main repository for WAP-Bluetooth project documentation and for customer support. Depending on the sales method, some support will be offered at the point of sale with primary support be offered preferably at the WAP-Bluetooth web site. Also available at the WAP-Bluetooth website will be the WAP-Bluetooth application WAP tool, user-friendly interface with, for example, integrated downloading facilities. Thus, for example, an inexperienced user may be enabled to easily construct a WAP page for his WAP-Bluetooth server. In addition Info/news may be provided as well as support, product documentation, FAQ, and links to additional support, for example, for open source components. It may further be possible for a user community through the WAP-Bluetooth website to meet other WAP-Bluetooth developers, learn about WAP-Bluetooth promotions, purchase items from an online store and view advertisements related to WAP- Bluetooth.

As has been previously referred to, a SDK may be provided and used for development of software for the WAP-Bluetooth server. The SDK is preferably targeted for internal and external developers. Initial developers may use the SDK for initial development of, for example, the WAP-Bluetooth basic WAP-Bluetooth application 520 while third party developers may use the SDK for independent development of WAP-Bluetooth applications. As will be appreciate by those skilled in the art, a development platform may be used for iterative development of an application and may not necessesarily include the WAP-Bluetooth server. However the development platform must resemble the target operating environment sufficiently to allow completed applications to be ported to the target hardware, e.g. the WAP-Bluetooth server. Accordingly, the development platform may include a standard PC running, for example, either Linux or Windows 9x NT 2000. If a developer is using Windows 9x certain restrictions may apply, e.g. it is not possible to build a cross-compiler. The development environment may include necessary software tools running on the development platform to support the development, e.g. a compiler, a debugger, and the like. The target platform is preferably the WAP-Bluetooth server which may be coupled to the development platform using, for example, an RS232 connection.

The SDK preferably includes a collection of software tools, e.g. the development envhonment, documentation, and examples derived from previous successful and model developed software for the target platform. The development environment provided with the SDK preferably includes the GNU development environment to allow development of software for the target platform. The GNU development envhonment consists of two different sets of tools: tools for the development platform, i.e. tools used to produce programs that execute on a standard PC, and tools for the target platform, i.e. tools used to produce programs that execute on WAP-Bluetooth server and the master-CPU in particular. Development platform tools may preferably consist of components such as a gcc compiler, a gdb debugger, a make utility, and a Unix shell, e.g. bash. If the development platform is running Linux, tools are preferably installed together with the operating system, and are not considered part of the SDK. If the development platform is running Windows, development tools must be installed separately and may be provided as part of the SDK. The SDK will preferably contain the CygWin development envhonment, which is a Win32 open source version of the GNU development environment. CygWin is distributed in binary format, but a developer may download source code if necessary. For more information see: sourceware.cygnus.com/cygwin. Tools for the development platform preferably serve two purposes. Tools may serve to build the tools for the target platform. The tools for the target platform may be found on the Internet in source code format and need to be compiled or built for a specified target platform, e.g the ARM CPU. Tools may further serve to support development of software for the target platform, e.g. the make utility is used when building software.

Tools for the target platform preferably consist of components such as the gcc compiler and the gdb debugger whose purpose is for building and debugging software for the target platform. Tools such as gcc and gdb will preferably be included in the SDK both as executable files for Linux and Windows and as source code. Master CPU 330, for example, when embodied, for example, as an ARM7TDMI processor is capable of executing code in two different modes, ARM mode and Thumb mode. These two modes currently require two different sets of development tools thus the SDK will preferably include both sets of tools. The SDK will also preferably contain, apart from the development environment, the following tools: a WML to WMLC compiler, and a tool for downloading applications and data to the WAP-Bluetooth server. It should be noted that if the WAP-Bluetooth server contains a gdb-stub in FLASH memory, such a tool for downloading may be the gdb debugger.

As previously noted, the software components in the SDK include the basic WAP-Bluetooth application 520 and software platform 510. While Bootloader 530 may be part of the SDK one reason for excluding it is that since bootloader 530 can not be updated by the third party developer there is no reason to publish the source code. Bootloader 530 preferably does not contain, for example, any know- how that a equipment provider wants to protect. Further, it should be noted that if bootloader 530 contains a modified gdb-stub it should be published since gdb is licensed using GPL. Operating system 512, for example, when provided as eCos may be distributed in the SDK as an installation file which installs the operating system for a number of different target platforms. Configuration tools may further be provided, which are used for configuring eCos for a specified target platform. The result of installation and configuration is a "build" directory containing all source code files needed for the specified target platform. The SDK will preferably, apart from the complete installation of eCos, contain the build directory for the WAP-Bluetooth server.

The purpose of documentation is to support third party developers using the SDK. The documentation may contain the following parts: Documentation on how to use the development envhonment, documentation on other software tools, and documentation on software components. It should be noted that the amount of documentation necessary may not be the same for the different component, e.g. eCos is delivered with a very good documentation that will preferably be included in the SDK. It is further preferably that the documentation format is readable on all supported platforms, e.g. Windows and Linux. Writing documentation in

Microsoft Word, for example, can be acceptable if it is also distributed in HTML and Acrobat PDF format.

The SDK preferably further contains examples and application notes to support the third party developer. Each example should preferably contain the following parts: commented and well-structured source code, binary file for direct downloads to WAP-Bluetooth server, and a short description in a text file. The complexity of the examples may range from simple "hello world" type applications to a complete WAP-Bluetooth application.

The SDK will preferably be developed and packaged according to the Linux common practice, according to, for example, the "Software Release Practice HOWTO", see metalab.unc.edu/LDP/H0WTO/Soft ware-Release- Practice, html). Packaging practice includes: delivery of all software in source code format, and, where applicable, in binary format also for all supported platforms; delivery of all software in compressed format; delivering source code capable of being built using the familiar " ./configure; make; make install" sequence implying that the SDK must preferably be made using autoconf and automake; naming of all deliverables according to Linux common practice; including standard top-level files, e.g. README. INSTALL and FAQ in all SDK deliverables. In accordance with naming practices, all SDK deliverables are preferably named using the following convention:

[COMP]-[VERSION] . [src/bin] . [TYPE] . [ARCH] where

COMP Name of software component, e.g. gcc

VERSION Version or date of component, e.g. 1.2.3 or 991223

TYPE arm-AT9I-elf ARCH Archive and compression extension, e.g tar.gz

examples: gcc-2.95.2.bin.arm-AT91-elf-win32.tar.gz gdb-991223.src.tar.gz

In accordance with various exemplary embodiments in accordance with the present invention, an Ethernet interface could be useful in some applications. For example, an Ethernet interface would be useful in WAP-Bluetooth applications where the WAP-Bluetooth server needs to be connected to the Internet in order to receive constantly updated information. An Ethernet interface could further be useful for handling many WAP-Bluetooth servers in a network configuration where a wider area is desired to be covered or where information should be shared between WAP-Bluetooth servers. It should be noted that adding an Ethernet interface would require some extra components, such as an Ethernet controller, an isolation server, and a connector. While adding such additional components is possible, space on the WAP-Bluetooth server PCB may be somewhat limited, Thus, an Ethernet interface may preferably be provided in the context of an upgrade to the WAP-Bluetooth server for additional cost.

As previously noted, in addition to serial interface 450, for example, being configured as an RS232 port, it may also be configured as USB interface. Replacing the RS232 interface with an USB-slave interface could be advantageous as a further potential upgrade since virtually all modern PCs today support the

USB interface, and the bandwidth offered is substantially higher than on an RS232 port. Moreover, the WAP-Bluetooth server could receive power from the USB host, thereby omitting the need for an extra power supply. It should be noted that while the above configuration is possible, the WAP-Bluetooth server, in order to derive power from the USB host would be required to draw no more than a maximum of 50mA. It should also be noted that to provide a USB slave interface in the WAP-Bluetooth server, software drivers are necessary. It should still further be noted that the amount of components, PCB space, and cost associated with providing an USB slave interface is approximately within the same range as for providing the RS232 interface.

It may further be useful in accordance with various exemplary embodiments in accordance with the present invention to provide delivery, via the WAP-Bluetooth server, not only data, but also "voice" type of information. As can be appreciated, such an application could be useful for, for example, distributing music within an office to users wearing Bluetooth headsets. However, it is important to note that the WAP-Bluetooth server has a limited capability for locally storing large amounts of data such as, for example, mp3 music files. Therefore, in accordance with various exemplary embodiments of the present invention voice/music information is preferably either fairly short, or voice/music information preferably is provided from an external server via an interface, e.g. RS232, Ethernet, or USB. Adding audio capabilities to the WAP-Bluetooth server is possible preferably by adding only a few extra components requiring only moderate extra PCB space with minimal component cost. It should further be noted that in addition to providing voice, video may further be provided as long as certain system parameters are met. For example, WAP version 2.0 or later must be used and the WAP-Bluetooth terminal must be capable of entering a graphics mode on its local display. Accordingly a graphics driver must be present on the WAP-Bluetooth terminal. Appropriate resolution and, for example, color display capabilities would further be desirable.

Since most of the advanced and thus hardware-demanding applications are expected to come from third-party developers, challenges exist, as previously noted, in estimating an optimal amount of memory to offer in the WAP-Bluetooth server. By providing an amount of memory corresponding to, for example, the amount necessary for average or even large applications, some memory is likely to be wasted for many types of applications. On the other hand, some applications may require huge amounts of memory, such as, for example, applications for providing playback of locally stored mp3 -music files. One way of handling varying memory demands includes adding a "memory expansion slot" to the WAP-Bluetooth server, thus enabling a user to, for example, insert a memory card or appropriate memory expansion module with an amount of memory appropriate for the application. It should be noted that there are a number of memory devices commercially available such as, for example, RAM, FLASH, "combos" and the like. Further, each type of memory device may have memory different capacity in the amount of from several to several hundreds of megabytes and several "standards", e.g. "MemoryCard", "FlashStick", and "PC-Card" exist which must be supported.

It may still further be desirable in accordance with various exemplary embodiments of the present invention for The WAP-Bluetooth server to be equipped with a USB master interface which interface may be used to connect USB peripherals with the needed resources to the WAP-Bluetooth server, thereby avoiding the need to add extra hardware like Ethernet and memory slots directly to the hardware. However, a USB master interface is a significantly more complex interface than its "slave" counterpart. In fact, the USB standard is designed to provided for cheap and simple slaves by putting the cost and complexity on the master side, which is expected to be a server in the range of a PC. Thus the USB master requires a few rather expensive components, but the most complex part would be the USB master software stack, which is both complex and potentially memory-demanding .

In accordance with alternative exemplary embodiments in accordance with the present invention, the WAP-Bluetooth server is preferably battery-powered, particularly if there is no specific need to have it continuously connected by a wire to a wall outlet. A batter powered WAP-Bluetooth server design would benefit from hardware configured for low-power-mode support, however, such support is provided by fahly complex "power-management" software which is not part of the standard software load. In addition, extra components are needed, most notably a battery adding considerable implications to the cost and space requirements associated with the WAP-Bluetooth server.

It should be noted that in accordance with exemplary embodiments of the present invention, a WAP-Bluetooth server is preferably designed for indoor "office" conditions. Therefore, in order to use the WAP-Bluetooth server in outdoor applications, of which there are potentially many, and also "industrial" applications where hostile environmental conditions may exist, existing design must be altered. "Outdoor" use might include use under extremely wet, extremely dry, extremely cold, extremely hot, and/or extremely dusty, dirty, or otherwise where conditions of fine particulate matter is present. Accordingly, the mechanical design would need to be modified to suit the particular application or range of expected environmental conditions. The normally packaged WAP- Bluetooth server is expected to perform normally down to approx +5degC. Most components are available in versions tolerating more extreme operating conditions, however Bluetooth interface 320 is presently available in commercial temperature range only. This can be expected to change over time with improved Bluetooth interface module coming into production as the popularity and corresponding demand for WAP-Bluetooth servers and devices increases. "Industrial" use might further mean that the WAP-Bluetooth server could be exposed to, for example, vibrations, fluctuating temperatures, and harsh electromagnetic fields, none of which are handled in the standard commercial design. Several problems related to industrial and outdoor use could be handled at once by designing a more "rugged" mechanical packaging, which is, for example, shock and vibration proof, water proof, dust proof, and resistant to temperature extremes, but it might also have hnplications for the hardware design. For example, it is common to require that interfaces like RS232 which are connected to industrial equipment are galvanically isolated from each other. It should further be noted that in accordance with ruggedized and battery powered units for use in remote industrial and/or outdoor applications, the use of a solar panel to maintain a battery charge would also be useful. Since it is possible to envision a number of different combinations of requirements it may be useful to consider variants separately for each intended requirement specification rather than a single WAP-Bluetooth server for all possible physical conditions. As previously noted, the RS232 interface could either be exchanged with another interface such as, for example, an USB-slave, or completely removed. Maintenance work intended to be carried out over it might instead be transferred via the Bluetooth interface itself. Removing the components for the RS232 would save some PCB space mostly from the vicinity of the connector, and possibly also some degree of costs. Although the RS232 interlace is not very costly, removing the RS232 interface might have a few implications worth noting. One implication is that the RS232 connector in one embodiment is used for anchoring the PCB into the enclosure. Removing the RS232 connector would then imply that the PCB must be anchored in a different way. Another implication is that the RS232 line is used for debugging during application development. Thus, if the RS232 connector is removed, a different way of providing debugging support must be included in the SDK and in the WAP-Bluetooth server. Possible solutions might include, for example, a simple two-pin SIP connector.

Another simplification of the WAP-Bluetooth server would be to remove the need for external memories. If only on-chip memories were needed the WAP- Bluetooth server design could potentially require much less space, and the component cost would likely be considerably reduced. Avoiding the use of external data and address buses would also make the PCB design simpler, and reduce potential risks for EMC problems which often originate from external data and address buses. It should be noted that in accordance with various exemplary embodiments of the present invention, the μ~controller for use with, for example, master CPU 330 or baseband -controller 322, 422, e.g. ARM7TDMI comes in a family which offers a maximum combination of 2Mbyte FLASH + 136Kbyte of SRAM memory in one single package. Though this would be fully sufficient for many use-cases, as previously described, restricting the memory capacity could mean that some applications would not fit within the memory provided and third- party developers may avoid investing effort into developing applications for the server. Such difficulties may be avoided by using, for example, the 2Mbyte + 136Kbyte server, and exchange the external memories with either a memory card slot or a permanent connection to another server with larger memory capacity. Then, third-party developers could develop software for a wide range of memory configuration needs, while still not wasting too much cost by providing applications with low memory demands on over-provisioned hardware. Also as previously noted, it may further be desirable in accordance with various exemplary embodiments of the present invention, to exchange the Bluetooth antenna component with a pattern on the PCB. Although the Bluetooth antenna component is a rather low-cost component, it could be completely removed if an antenna was realized as a pattern directly into the PCB. Such a solution would take some effort to correctly design, but once designed it would mean that the antenna would come virtually at zero marginal cost. However, it should also be noted that an exemplary embodiment including antenna component provides a compact solution while a PCB variant is anticipated to require somewhat more PCB space. As previously described with reference to FIG 3, Bluetooth interface 320 is a complete embedded microcomputer, having both powerful baseband _/^-controller 322 and FLASH memory 323. Bluetooth interface 320 is stand-alone priced at around US$30, which is a considerable portion of the total WAP-Bluetooth server product cost. It is further now understood that only around 30% of the capacity of baseband _/i-controller 322 in Bluetooth interface 320 is used for Bluetooth related communication, and that the remainder of the capacity is intended for end-user applications. However, since the baseband software has not yet been "packaged" so that it can safely coexisting on a single CPU together with an end-user application, the additional capacity is not presently available though it is expected that this problem will soon be solved in due course. If a WAP-Bluetooth application could be stored and executed in baseband μ-controller 322 and FLASH module 323 with the Bluetooth baseband software, both the external master CPU 330 and external memories 331 and 332 could potentially be removed from the PCB. Doing so presents an attractive solution for high-volume second generation of the WAP-Bluetooth hardware, for example as embodied on PCB 400 as illustrated in FIG 4, considerably reducing cost, PCB space, and power consumption of the WAP-Bluetooth server. Moreover, simple migration to a single-CPU solution is provided for in a two processor design. For example, by providing an AT91 μ-controller for master CPU 330, and using the same core processor for baseband μ-controller as Bluetooth interface 320, a good foundation may be provided for porting all software to integrated baseband μ-controller 422 with little additional effort. Yet another level of integration could preferably be achieved if WAP-Bluetooth- ASIC 420 is designed starting from the Bluetooth baseband μ-controller 422.

Extended WAP-Bluetooth application functionality may be provided in accordance with the present invention by providing additional features such as for example, an Embedded Flash File System and/or EEPROM emulation. An embedded flash file system is preferably part of software platform 510 simulating an ordinary file system, e.g. DOS, using FLASH memory. With such a file system, WAP-Bluetooth may implement the following functionality. With an embedded flash file system more than one file with WAP contents may be saved allowing, for example, the possibility of sending different information to different clients. With an embedded flash file system better information security may be added since each file may be given, for example, security access attributes, thus preventing anyone from updating the information. With an embedded flash file system file security may be added in the form of, for example, crash recovery. It should be noted that embedded flash file systems may be available as commercial products although the WAP-Bluetooth server, in various exemplary embodiments in accordance with the present invention may be provided with enough FLASH memory to support an embedded flash file system.

EEPROM emulation on the other hand, may be used for storing small pieces of information in, for example, FLASH memory 331, 421. Accordingly, FLASH memory 331, 421 may be configured to act as EEPROM memory which may be useful if, for example, basic WAP-Bluetooth application 520 is updated to store certain information elements, e.g. how many successful Bluetooth connections have been made during a particular time period, which time period may also be stored. It should be noted that the addition of a TCP/IP stack may be required for converting WAP-Bluetooth server into a web server/gateway using, for example, the Ethernet connection as previously described. It should be noted that it may further be possible to add TCP/IP functionality to both the Bluetooth connection and the RS232 connection. It should further be noted that a TCP/IP stack is preferably included as a component of the eCos operating system for use as operating system 512, however, other open source and commercially available alternatives may also be available.

Extended functionality of Bluetooth stack 513 may preferably be provided on an ongoing basis. Consequently, software platform 510 preferably must be updated periodically until the such a time that Bluetooth stack 513 is considered finished. Software platform 510 may be updated periodically despite whether or not Bluetooth stack 513 extensions have been released. For, example, if any kind of new software functionality is added, e.g. support for new client profiles, which makes it possible to implement new and interesting functionality in WAP- Bluetooth envhonment, software platform 510 might also be updated.

The addition of an embedded web server to software platform 510 may further be desirable in accordance with various exemplary embodiments of the present invention, and may have different consequences depending on whether the ' embedded web server is added to a Bluetooth connection, an RS232 connection, or both. Web support added to a Bluetooth connection may be used to convert the WAP-Bluetooth server into a web server for Bluetooth and web capable clients such as for example, a PDA or laptop computer. Web support added to the RS233 connection makes it possible for the WAP-Bluetooth server to operate as a WAP server for shifting data between the Internet and a WAP client.

While WAP-Bluetooth service may be partially maintained, for example, by downloading new WAP contents using a web browser on the host, only those maintenance features supported by basic WAP-Bluetooth application 520 can be supported with an embedded web server. Maintenance features supported by bootloader 530 may not be supported by an embedded web server. It should be noted that an embedded web server may require the addition of a TCP/IP stack to software platform 510. As previously noted TCP/IP stacks may be available as both open source and commercial products. In accordance with additional exemplary embodiments in accordance with the present invention, a web interface to bootloader 530 would make it possible to perform maintenance such as basic diagnostics and the downloading of new applications using a web browser on the host. The WAP-Bluetooth maintenance web page could be located locally in the WAP-Bluetooth server or could be connected remotely through a host interface to a main WAP-Bluetooth website for remote maintenance. As with the embedded web server, the bootloader web interface may require the addition of a TCP/IP stack to software platform 510.

A complete WAP stack implementation would add WAP functionality such as support for security transactions and the possibility of implementing, for example, a WAP gateway. It should be noted that complete WAP stacks may be available as commercial products.

Further in accordance with various exemplary embodiments of the present invention, developers of the eCos operating system are presently defining an Application Programming Interface (API) called EL/IX, which unifies the kernel API for Linux, embedded Linux, and eCos. If software platform 510 is updated to support the EL/IX API the conversion of Linux applications such as, for example, the Axis bluetooth stack would be greatly simplified. See, for example, sourceware.cygnus.com/elix for more information. It should be noted that the eCos operating system is implemented in C+ + language and not in C language. However eCos contains C wrapper code making it possible to implement applications in C. It should be noted that basic WAP- Bluetooth application 520 and Bluetooth stack 513, for example, are implemented in C language. If the functionality of basic WAP-Bluetooth application 520 is dramatically extended it may be advisable to shift to an object oriented programming language, such as C+ + . Doing so will require C + + wrapper code for code written in C, e.g. Bluetooth stack 513.

High-level language interpretation support may further be provided in accordance with various exemplary embodiments in accordance with the present invention. Instead of offering a C or C+ + API for the third party developers as a software platform, a high-level interpreted language may be implemented in WAP- Bluetooth server, e.g. Java, Pert, or Python. It should be noted that due to open source community requirements, an equipment provider preferably must implement a language interpreter or adapt an open source implementation of the WAP-Bluetooth server. All functionality necessary for thhd party developers such as, for example, Bluetooth functionality, must be provided as an WAP-Bluetooth library of functions. Accordingly the addition of high-level language interpretation makes the WAP-Bluetooth server an extremely easy platform for developing and implementing an increasingly diverse array of new Bluetooth functionality. It should be noted that basic WAP-Bluetooth application 520 may be implemented preferably in less than 50 lines of code. It should further be noted that the WAP-Bluetooth server could fairly easily be implemented in a cellular phone. As is illustrated in FIG 6A and FIG 6B (consisting of FIG 6B-1, FIG 6B-2, and FIG 6B-3), the industrial design will be the base for the mechanical design. For example, CAD-files from a designer may be used to make basic data for the purchase of mechanical details. The mechanical details are basically the plastic and aluminum parts of the casing. The layout of PCB 600, for example, may be configured to provide for a circuit area 630, a ground plane 610 and and antenna area 620, surrounded by ground plane 610 to minimize RF noise coupling into and from circuit area 630. In addition antenna area 620 may be configured, as shown, for a component antenna or may be used as an approximate location for an antenna which may be etched into PCB 600. Casing 640 as illustrated in FIG 6B may be configured for a number of possible orientations as shown which facilitate both convenience of placement for WAP-Bluetooth server customers and optimal antenna radiation patterns. Because of the nature of the dual orthogonally oriented half-taurus radiation patterns of, for example, the component antenna used in conjunction with various embodiments of the present invention, many different orientations of the WAP-Bluetooth server are possible making the WAP-Bluetooth server more convenient to locate. Included in the packaging is base 641, logo strip 642, cover 640, 650, 660, mounting slot 651, bottom surface 652, footings 653, information label 654, top surface 661, power input jack 652, Ethernet jack 663, and D-type serial connector 664. While aspects of packaging are subject of co-pending design patent application docket number D00828, supra, some elements shown in FIG 6A and 6B such as, for example, mounting slot 651 provide convenient functionality.

Claims

WHAT IS CLAIMED IS:

1. A method for providing location dependent information services to one or more customers in a WAP-Bluetooth envhonment, the method comprising the steps of: providing one or more WAP-Bluetooth server units to the one or more customers, the one or more customers including one or more qualified third party developers; providing a WAP-Bluetooth Software Developer Kit (SDK) to the one or more qualified thhd party developers; and providing one or more qualified WAP-Bluetooth applications developed by the one or more thhd party developers to the one or more customers such that the qualified applications are loaded on the one or more WAP-Bluetooth server units for providing the location dependent information services to one or more customers and one or more mobile WAP-Bluetooth terminals.

2. A method for providing location dependent information services in a WAP- Bluetooth environment the method comprising the steps of: connecting with one or more WAP-Bluetooth client terminals; and pushing one or more location-dependent WAP pages toward the one or more WAP-Bluetooth client terminals using a WAP-Bluetooth application.

3. A method for providing location dependent information services in a WAP- Bluetooth enviroment the method comprising: transmitting a WAP-Bluetooth signal in a coverage area associated with the location dependent information service; and connecting with one or more WAP-Bluetooth client terminals to provide the location dependent information service.

4. The method of claim 1 , further including the step of registering the one or more qualified WAP-Bluetooth applications such that the one or more qualified WAP-Bluetooth applications are available to the one or more customers and the one or more thhd party developers in a product registry.

5. The method of claim 1, further comprising: presenting the one or more qualified WAP-Bluetooth applications to the one or more customers using a website; and providing the one or more qualified WAP-Bluetooth applicaitons on a trial basis to the one or more customers using the website.

6. The method of claim 1, wherein the SDK includes one or more of: a WAP- Bluetooth development envhonment, WAP-Bluetooth software modules, and documentation.

7. The method of claim 1, wherein the SDK includes WAP-Bluetooth application examples.

8. The method of claim 1, wherein the SDK includes one or more of: a bootloader, a software platform, and a basic WAP-Bluetooth application.

9. The method of claim 8, wherein the software platform further includes a Bluetooth stack.

10. The method of claim 8, wherein the software platform further includes an operating system.

11. The method of claim 8, wherein the software platform further includes one or more drivers corresponding to one or more hardware interfaces.

12. The method of claim 1, wherein the SDK includes open source software components.

13. The method of claim 6, wherein the WAP-Bluetooth development environment includes a graphical user interface development tool.

14. The method of claim 13, wherein the graphical user interface development tool is associated with a Microsoft^® Windows^® operating environment.

15. The method of claim 13, wherein the graphical user interface development tool is associated with a UNIX operating environment.

16. An apparatus for providing location dependent information services to one or more customers in a WAP-Bluetooth environment, the apparatus comprising: a standard computer; a website; one or more WAP-Bluetooth terminals; and one or more WAP-Bluetooth servers, wherein the apparatus is configured to: provide the one or more WAP-Bluetooth server units to the one or more customers, the one or more customers including one or more qualified thhd party developers; provide a WAP-Bluetooth Software Developer Kit (SDK) to the one or more qualified thhd party developers using the website; and provide one or more qualified WAP-Bluetooth applications developed by the one or more thhd party developers to the one or more customers over the website such that the qualified applications are loaded on the one or more WAP-Bluetooth server units for providing the location dependent information services to one or more customers and to the one or more mobile WAP-Bluetooth terminals.

17. An apparatus for providing location dependent information services in a WAP-Bluetooth envhonment including one or more WAP-Bluetooth client terminals, the apparatus comprising: a WAP-Bluetooth server, having a Bluetooth interface, a memory, and a processor, wherein the processor is configured to: connect with the one or more WAP-Bluetooth client terminals using the Bluetooth interface; and push one or more location-dependent WAP pages stored in the memory toward the one or more WAP-Bluetooth client terminals using a WAP-Bluetooth application stored in the memory and executing on the processor.

18. An apparatus for providing location dependent information services in a WAP-Bluetooth environment including one or more WAP-Bluetooth client terminals, the apparatus comprising: a WAP-Bluetooth server, having a Bluetooth interface, a memory, and a processor, wherein the processor is configured to: transmit a WAP-Bluetooth signal in a coverage area associated with the location dependent information service using the Bluetooth interface; and connect with the one or more WAP-Bluetooth client terminals to provide the location dependent information services.

19. The apparatus of claim 16, further comprising a product registry and wherein the apparatus is further configured to register the one or more qualified WAP-Bluetooth applications such that the one or more qualified WAP-Bluetooth applications are available to the one or more customers and the one or more third party developers in the product registry and which product registry is avaiable on the website.

20. The apparatus of claim 16, wherein the apparatus if further configured to: present the one or more qualified WAP-Bluetooth applications to the one or more customers using the website; and provide the one or more qualified WAP-Bluetooth applicaitons on a trial basis to the one or more customers using the website.

21. The apparatus of claim 16, wherein the SDK includes one or more of: a WAP-Bluetooth development envhonment, WAP-Bluetooth software modules, and documentation.

22. The apparatus of claim 16, wherein the SDK includes WAP-Bluetooth application examples.

23. The apparatus of claim 16, wherein the SDK includes one or more of: a bootloader, a software platform, and a basic WAP-Bluetooth application.

24. The apparatus of claim 23, wherein the software platform further includes a Bluetooth stack.

25. The apparatus of claim 23, wherein the software platform further includes an operating system.

26. The apparatus of claim 23, wherein the software platform further includes one or more drivers corresponding to one or more hardware interfaces.

27. The apparatus of claim 16, wherein the SDK includes open source software components.

28. The apparatus of claim 21, wherein the WAP-Bluetooth development environment includes a graphical user interface development tool.

29. The apparatus of claim 28, wherein the graphical user interface development tool is associated with a Microsoft^® Windows^® operating envhonment.

30. The apparatus of claim 28, wherein the graphical user interface development tool is associated with a UNIX operating environment.

31. The apparatus of claim 16, wherein the memory includes a FLASH memory.