Apparatus, method and system for an object exchange bridge

FIELD

[0001] The present invention relates generally to an apparatus, method and system to route information from a wireless device across a communications network. More particularly, the disclosed invention relates to an apparatus, method and system to enable short range radio frequency (“RF”) wireless point to point communications to be bridged across a communications network.

BACKGROUND

[0002] Networks

[0003] Networks are commonly thought to consist of the interconnection and interoperation of clients, servers, and intermediary nodes in a graph topology. It should be noted that the term “server” as used herein refers generally to a computer, other device, software, or combination thereof that processes and responds to the requests of remote users across a communications network. Servers serve their information to requesting “clients.” A computer, other device, software, or combination thereof that facilitates, processes information and requests, and/or furthers the passage of information from a source user to a destination user is commonly referred to as a “node.” Networks are generally thought to facilitate the transfer of information from source points to destinations. There are many forms of networks such as Local Area Networks (LANs), Wide Area Networks (WANs), Pico networks, etc.

[0004] Internet

[0005] The Internet is a network of networks. It is an interconnection of various and disparate networks that are disposed in communication with one another. This interconnectivity and intercommunications provided by the Internet is in large part facilitated through the use of common transmission protocols.

[0006] As Internet usage increases, the amount of information and/or services available on the Internet also increases. This makes the Internet a valuable information transportation vehicle.

[0007] Transmission Control Protocol-Internet Protocol (TCP/IP)

[0008] The proliferation and expansion of computer systems, databases, and networks of computers has been facilitated by an interconnection of such systems and networks in an extraterritorial communications network commonly referred to as the Internet. The Internet has developed and largely employs the Transmission Control Protocol-Internet Protocol (TCP/IP). TCP/IP was developed by a Department of Defense (DoD) research project to interconnect networks made by various and varying network vendors as a foundation for a network of networks, i.e., the Internet. The development of TCP/IP was in part driven by a requirement by the DoD to have a network that will continue to operate even if damaged during battle, thus allowing for information to be routed around damaged portions of the communications network to destination addresses.

[0009] The Internet is a packet-switched network and thus, information on the Internet is broken up into pieces, called packets, and transmitted in packet form. The packets contain IP addressing information called headers, which are used by routers to facilitate the delivery of the packets from a source to a destination across intermediary nodes on the Internet. Upon arrival at the destination, the packets are reassembled to form the original message, and any missing packets are requested again.

[0010] The IP component of the protocol is responsible for routing packets of information based on a four byte addressing mechanism; the address is written as four numbers separated by dots, each number ranging from 0 to 255, e.g., “123.255.0.123”. IP addresses are assigned by Internet authorities and registration agencies, and are unique.

[0011] The TCP portion of the protocol is used for verifying that packets of information are correctly received by the destination computer from the source, and if not, to retransmit corrupt packets. Other transmission control protocols are also commonly used that do not guarantee delivery, such as User Datagram Protocol (UDP). The TCP/IP protocol is specified in IEEE/RFC1190, January 1991.

[0012] Object Exchange (OBEX) Protocol

[0013] OBEX is a session protocol and can be described as a binary HTTP protocol. An example of an OBEX server implementation may be OpenOBEX, which may be found at the website: sourceforge.net/projects/openobex.

[0014] The OBEX protocol and specification may be found in: IrOBEX, IrDA Object Exchange Protocol, Counterpoint Systems Foundry, Inc., Microsoft Corporation, Mar. 18, 1999 (Version 1.2).

[0015] Bluetooth Protocol (BT)

[0016] Bluetooth is a wireless technology that operates in the unlicensed Industrial, Scientific, and Medical (ISM) radio band of 2.4 GHz. Bluetooth technology includes a number of protocols that allow Bluetooth enabled devices to operate in a peer to peer environment forming piconets.

[0017] The Bluetooth protocol and specification may be found in: Bluetooth system; Specification Volumes 1 and 2, Core and Profiles: Version 1.1, Feb. 22, 2001.

SUMMARY

[0018] One embodiment of the present invention solves the problem of allowing remote OBEX services to interact with clients that support Bluetooth GEOP profiles. This is a very useful feature when implemented in Bluetooth access point networks as the desired service can be accessed through any access point instead of having to connect directly to the server device.

[0019] In one embodiment of the present invention, the OBEX bridge apparatus comprises a processor; a memory, communicatively connected to the processor; a program, stored in the memory, including, a module to receive the OBEX encoded communications at a short range RF (e.g., Bluetooth) enabled OBEX bridge from an OBEX client, a module to determine a destination IP address to send the received OBEX encoded communications, and a module to send the received OBEX encoded communications from the short range RF enabled OBEX bridge to an OBEX server at the determined destination IP address via IP.

[0020] In another embodiment of the present invention, the OBEX bridge apparatus comprises a processor; a memory, communicatively connected to the processor; a program, stored in the memory, including, a module to obtain OBEX encoded communications, a module to establish a baseband communication channel using a Bluetooth GOEP profile between the OBEX client and a Bluetooth enabled OBEX bridge, a module to encapsulate the OBEX encoded communications into baseband communications, a module to provide the baseband encapsulated communications to the OBEX bridge, a module to assign an internal IP address within the OBEX bridge, a module to bind the IP address to the baseband communication channel, a module to establish a TCP/IP communication channel between the OBEX bridge and a remote OBEX server, and a module to route the OBEX encoded data from the baseband channel to the TCP/IP channel.

[0021] In another embodiment of the present invention, the OBEX bridge apparatus comprises a processor; a memory, communicatively connected to the processor; a program, stored in the memory, including, a module to create a client baseband handle referring to a memory space in an OBEX bridge's memory for incoming baseband communications, a module to create an internal IP address within an OBEX bridge allowing for communications to flow to and from a communications network through the IP address, a module to create an entry in the memory to store the client baseband handle data type, a module to create an entry in the memory to store the IP address data type, and a module to bind the client baseband handle data type with its respective IP address data type.

[0022] In yet another embodiment of the present invention, the OBEX bridge apparatus comprises a processor; a memory, communicatively connected to the processor; a program, stored in the memory, including, a module to receive at an OBEX bridge OBEX encoded communications transmitted from the OBEX client via short range radio link; a module to allocate an internal address to the OBEX client at the OBEX bridge; a module to associate the OBEX client with the allocated internal address at the OBEX bridge; a module to select a certain OBEX server at the OBEX bridge to send the received OBEX encoded communications; a module to determine a destination IP address of the selected OBEX server; a module to send the received OBEX encoded communications from the OBEX bridge to the selected OBEX server via IP.

[0023] The above advantages and features are of representative embodiments only, and are not exhaustive and/or exclusive. They are presented only to assist in understanding the invention. It should be understood that they are not representative of all the inventions defined by the claims, to be considered limitations on the invention as defined by the claims, or limitations on equivalents to the claims. For instance, some of these advantages may be mutually contradictory, in that they cannot be simultaneously present in a single embodiment. Similarly, some advantages are applicable to one aspect of the invention, and inapplicable to others. Furthermore, certain aspects of the claimed invention have not been discussed herein. However, no inference should be drawn regarding those discussed herein relative to those not discussed herein other than for purposes of space and reducing repetition. Thus, this summary of features and advantages should not be considered dispositive in determining equivalence. Additional features and advantages of the invention will become apparent in the following description, from the drawings, and from the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

[0024] The accompanying drawings illustrate certain embodiments of the disclosure.

[0025]FIG. 1 is a schematic overview of a short range RF enabled and object exchange (OBEX) enabled client terminal according to one embodiment of the present invention;

[0026]FIG. 2 details the schematic overview of a short range RF enabled OBEX bridge according to one embodiment of the present invention;

[0027]FIG. 3 is a schematic overview of an OBEX server according to one embodiment of the present invention;

[0028]FIG. 4 shows an OBEX client-server-bridge connection <b>400</b> according to one embodiment of the present invention, and provides an exemplary data flow diagram; and

[0029]FIG. 5 details a flow diagram of an exemplary communications flow between an exemplary OBEX client, OBEX bridge and an OBEX server.

DETAILED DESCRIPTION

[0030] Short Range RF Enabled Client Terminal

[0031]FIG. 1 is a schematic overview of a short range RF and object exchange (OBEX) enabled client terminal (hereinafter called a “client”) according to one embodiment of the invention.

[0032] Client Systemization

[0033] In one non-limiting example embodiment, the client <b>101</b> may comprise a clock <b>103</b>, central processing unit (CPU) <b>102</b>, a memory <b>105</b>, a power source <b>104</b>, input <b>108</b>, <b>109</b> and output <b>110</b>, <b>111</b> (I/O) components <b>112</b>, <b>105</b>, <b>107</b>. The power source <b>104</b> provides power to the client. One of the I/O components is preferably a Bluetooth chip <b>106</b> such as Cambridge Silicon Radio Inc.'s BlueCore IC and Bluetooth transceiver <b>107</b> capable of transmitting and receiving Bluetooth protocol communications. It is to be understood that the use of Bluetooth components/protocols in the exemplary embodiment is intended to be illustrative rather than limiting, and that therefore other short range radio frequency technologies may alternatively be employed. Optionally, the client may also employ other wireless protocol transceivers <b>112</b> such as those employed for cellular telecommunications. Conventionally, although not necessarily, the client components are all interconnected and/or communicating through a system bus <b>177</b>. The system clock <b>103</b> typically has a crystal oscillator and provides a base signal. The clock is typically coupled to the system bus and various means that will increase or decrease the base operating frequency for other components interconnected in the client. The clock and various components in the client drive signals embodying information throughout the client. Such transmission and reception of signals embodying information throughout the client may be commonly referred to as communications. These communicative signals may further be transmitted, received, and the cause of return and/or reply signal communications beyond the instant client to: communications networks, input devices, computer systems (e.g., servers), bridges, other clients, peripheral devices, and/or the like. Of course, any of the above components may be connected directly to one another, connected to the CPU, and/or organized in numerous variations employed as exemplified by various wireless and short range RF enabled devices such as, but not limited to: cellular telephones, Portable Digital Assistants (PDAs), laptop computers, and/or the like. Optionally the client may include various input/output devices, which are also disposed in communication with the CPU through the system bus and/or directly. Such input devices may include a microphone <b>108</b>, an input keypad <b>109</b>, a touch sensitive screen (not shown), and/or like. Output devices may include an LCD <b>110</b> and a speaker <b>111</b>.

[0034] CPU

[0035] The CPU <b>102</b> comprises at least one data processor adequate to execute program modules for executing user and/or system-generated requests. The CPU may be a microprocessor such as the Intel Pentium Processor and/or the like. The CPU interacts with memory through signal passing through conductive conduits to execute stored program code according to conventional data processing techniques. Such signal passing facilitates communication within the communication networks and beyond through various interfaces.

[0036] Memory

[0037] It is to be understood that the client may employ various forms of memory <b>105</b>. In a typical configuration, memory <b>105</b> will include ROM, RAM, and possibly a fixed storage device, e.g., a hard disk drive. Also, the Bluetooth chip <b>106</b> may contain various Bluetooth protocols within its own memory that may be provided to either the CPU <b>102</b> and/or memory <b>105</b>. Generally, any mechanization and/or embodiment allowing a processor to affect the storage and/or retrieval of information is regarded as memory <b>105</b>. Thus, a client generally requires and makes use of memory. However, memory is a fungible technology and resource, thus, any number of memory embodiments may be employed in lieu of or in concert with one another.

[0038] Module Collection

[0039] The memory <b>105</b> may contain a collection of program modules and/or data such as, but not limited to: an operating system module <b>130</b> (operating system); an OBEX client application <b>121</b>; Generic Object Exchange Profile(s) (GOEP), which may also serve as a Bluetooth profile; memory buffers <b>123</b>; cellular communication protocols; Bluetooth protocol stack <b>124</b>, other short range radio frequency protocols and/or the like. Bluetooth protocol stack may include a Link Manager (LM) <b>174</b>, a Logical Link Control and Application Protocol (L2CAP) <b>175</b>, a Service Discovery Protocol (SDP) <b>176</b>, RFCOMM <b>177</b> (i.e., a serial line emulation protocol), and/or the like. Although non-conventional software modules such as those in the module collection, typically and preferably, are stored in memory <b>105</b>, they may also be loaded and/or stored in memory such as: peripheral devices, ROM, remote storage facilities through a communications network, various forms of memory, and/or the like.

[0040] Operating System

[0041] The operating system module <b>130</b> is executable program code facilitating the operation of the client. Typically, the operating system facilitates access of I/O, network interfaces, peripheral devices, storage devices, and/or the like. The operating system also may provide user interface functionality allowing the user to interact with the client. An exemplary client operating system is Linux. An operating system may communicate to and/or with other modules in a module collection, including itself, and/or facilities of the like. Conventionally, the operating system communicates with other program modules, user interfaces, and/or the like. For example, the operating system may contain, communicate, generate, obtain, and/or provide program module, system, user, and/or data communications, requests, and/or responses. The operating system, once executed by the CPU, may enable the interaction with communications networks, data, I/O, peripheral devices, program modules, memory, user input devices, and/or the like. Preferably, the operating system provides communications protocols that allow the client to communicate with other entities through a communications network <b>144</b>. Various communication protocols may be used by the client as a subcarrier transport mechanism for interacting with other short range RF enabled devices, such as, but not limited to: TCP/IP <b>122</b>, Bluetooth (i.e., via RFCOMM), OBEX <b>121</b>, and/or the like.

[0042] Bluetooth protocols

[0043] In memory <b>105</b> various Bluetooth protocols <b>124</b> and/or other short range RF protocols are stored. The Bluetooth protocols may include a link manager protocol <b>174</b> (hereinafter “LM”). The link manager software runs on the CPU in the client to manage communications between itself and other Bluetooth devices. Another protocol is the Service Discovery Protocol <b>176</b> (hereinafter “SDP”). After the connection of a Bluetooth client with another device, the Service Discovery Protocol enables the querying and identification of the abilities of other Bluetooth devices. Another protocol is the Logical Link Control and Adaptation Protocol <b>175</b> (hereinafter “L2CAP”). The L2CAP provides multiplexing, packet segmentation and reassembly of data as it's communicated between the client and other Bluetooth enabled devices. Another protocol held in memory <b>105</b> is the RFCOMM which is a serial line emulation protocol that enables Bluetooth devices to intercommunicate by emulating a serial line. These various protocols interact to encode and decode data as given by the CPU through a base band <b>107</b>. LM and L2CAP run directly on top of base band <b>107</b>. RFCOMM and SDP run on top of L2CAP.

[0044] Furthermore, within the RAM <b>105</b> is an Object Exchange (hereinafter “OBEX”) client application <b>121</b>. The client application creates OBEX requests based on user input into the client device and receives and interprets OBEX responses from an OBEX server <b>199</b>. OBEX is a session layer protocol that was developed to enable the exchange of objects in a simple and spontaneous manner. OBEX enables object exchange services similar to HTTP used in the World Wide Web (the web), however, OBEX requires substantially less resources to run. The OBEX client application enables the client to exchange objects and to communicate over the RFCOMM. Further, the memory may contain a Generic Object Exchange Profile (hereinafter “GOEP” or “Profile”) <b>125</b>. GOEP specifies a manner in which Bluetooth devices may support object exchange facilities including File Transfer Profile, Object Push Profile and Synchronization Profile. The GOEP specification allows Bluetooth devices to interoperate by defining interoperability requirements for the applications and the higher Bluetooth protocol layers (i.e., L2CAP, RFCOMM, etc.). Furthermore, the memory <b>105</b> may provide an area that will act as a buffer <b>123</b>.

[0045] The Client <b>101</b> may communicate through communications network <b>144</b> wirelessly <b>133</b> to eventually reach an OBEX server <b>199</b>. This is facilitated by an OBEX bridge <b>150</b>.

[0046] OBEX Bridge for Short Range RF Communications

[0047]FIG. 2 details the schematic overview of a short range RF enabled OBEX bridge (hereinafter “bridge”) according to one embodiment of the invention.

[0048] OBEX Bridge Systemization

[0049] In one non-limiting example embodiment, the bridge <b>250</b> may comprise a clock <b>203</b>, central processing unit (CPU) <b>202</b>, a memory <b>205</b>, a power source <b>204</b>, I/O components <b>220</b>, <b>207</b>. The power source <b>104</b> provides power to the bridge. One of the I/O components is a Bluetooth chip <b>206</b> such as Cambridge Silicon Radio Inc.'s BlueCore IC and Bluetooth transceiver <b>207</b> capable of transmitting and receiving Bluetooth protocol communications. As discussed above in connection with “Client Systemization” (FIG. 1), the use of Bluetooth components/protocols in the exemplary embodiment is intended to be illustrative rather than limiting, and that therefore other short range RF technologies may alternatively be employed. Conventionally, although not necessarily, the client components are all interconnected and/or communicating through a system bus <b>277</b>. The system clock <b>203</b> typically has a crystal oscillator and provides a base signal. The clock is typically coupled to the system bus and various means that will increase or decrease the base operating frequency for other components interconnected in the bridge. The clock and various components in the client drive signals embodying information throughout the client. Such transmission and reception of signals embodying information throughout the client may be commonly referred to as communications. These communicative signals may further be transmitted, received, and the cause of return and/or reply signal communications beyond the instant bridge to: communications networks, input devices, computer systems (e.g., servers), peripheral devices, clients, and/or the like. Of course, any of the above components may be connected directly to one another, connected to the CPU, and/or organized in numerous variations employed as exemplified by various short range RF enabled computing devices. Optionally the client may include various input/output devices, which are also disposed in communication with the CPU through the system bus and/or directly. The Bluetooth module <b>206</b> enables wireless communications through a wireless transceiver <b>207</b>, while a network interface <b>220</b> such as an Ethernet card, an ISDN card, a DSL card, and/or the like enables communications <b>266</b> with the communications network <b>244</b>. Thus, the bridge <b>250</b> bridges short range RF wireless communications <b>233</b>, <b>207</b> with network communications <b>220</b>, <b>266</b>, <b>244</b>.

[0050] CPU

[0051] The CPU <b>102</b> comprises at least one data processor adequate to execute program modules for executing user and/or system-generated requests. The CPU may be a microprocessor such as the Intel Pentium Processor and/or the like. The CPU interacts with memory through signal passing through conductive conduits to execute stored program code according to conventional data processing techniques. Such signal passing facilitates communication within the communication networks and beyond through various interfaces.

[0052] Memory

[0053] It is to be understood that the bridge may employ various forms of memory <b>205</b>. In a typical configuration, memory <b>205</b> will include ROM, RAM, and possibly a fixed storage device, e.g., a hard disk drive. Also, the Bluetooth chip <b>206</b> may contain various Bluetooth protocols within its own memory that may be provided to either the CPU <b>102</b> and/or memory <b>105</b>. Generally, any mechanization and/or embodiment allowing a processor to affect the storage and/or retrieval of information is regarded as memory <b>105</b>. Thus, a bridge generally requires and makes use of memory. However, memory is a fungible technology and resource, thus, any number of memory embodiments may be employed in lieu of or in concert with one another.

[0054] Module Collection

[0055] The memory <b>205</b> may contain a collection of program modules and/or data such as, but not limited to: an operating system module <b>230</b> (operating system); an OBEX bridge application <b>221</b>; TCP/IP stack <b>222</b>; Generic Object Exchange Profile(s) (GOEP), which may also serve as a Bluetooth profile; memory buffers <b>223</b>; cellular communication protocols; Bluetooth protocol stack <b>224</b>, other short range RF protocols, and/or the like. Bluetooth protocol stack may include a Link Manager protocol (LM) <b>274</b>, a Logical Link Control and Application Protocol (L2CAP) <b>275</b>, a Service Discovery Protocol (SDP) <b>276</b>, RFCOMM <b>177</b> (i.e., a serial line emulation protocol), and/or the like. Although non-conventional software modules such as those in the module collection, typically and preferably, are stored in memory <b>205</b>, they may also be loaded and/or stored in memory such as: peripheral devices, ROM, remote storage facilities through a communications network, various forms of memory, and/or the like.

[0056] Operating System

[0057] The operating system module <b>230</b> is executable program code facilitating the operation of the bridge. Typically, the operating system facilitates access of I/O, network interfaces, peripheral devices, storage devices, and/or the like. The operating system also may provide user interface functionality allowing an administrator to interact with the bridge. An exemplary bridge operating system is Linux. An operating system may communicate to and/or with other modules in a module collection, including itself, and/or facilities of the like. Conventionally, the operating system communicates with other program modules, user interfaces, and/or the like. For example, the operating system may contain, communicate, generate, obtain, and/or provide program module, system, user, and/or data communications, requests, and/or responses. The operating system, once executed by the CPU, may enable the interaction with communications networks, data, I/O, peripheral devices, program modules, memory, user input devices, and/or the like. Preferably, the operating system provides communications protocols that allow the client to communicate with other entities through a communications network <b>244</b>. Various communication protocols may be used by the bridge as a subcarrier transport mechanism for interacting with other short range RF enabled devices, such as, but not limited to: Bluetooth (i.e., via RFCOMM), multicast, OBEX <b>121</b>, TCP/IP <b>122</b>, UDP, unicast, and/or the like. The TCP/IP stack enables TCP/IP communications through the network interface <b>220</b>.

[0058] Bluetooth protocols

[0059] In memory <b>205</b> various Bluetooth protocols <b>224</b> and/or other short range RF protocols are stored. The Bluetooth protocols may include a LM protocol <b>274</b>, SDP <b>276</b>, L2CAP <b>275</b>, RFCOMM <b>277</b>, and Baseband as has already been discussed above. The link manager software runs on the CPU in the bridge to manage communications between itself and other Bluetooth devices such as clients <b>101</b>. After the connection of the Bluetooth bridge with another device, the Service Discovery Protocol enables the querying and identification of the abilities of other Bluetooth devices. These various protocols interact to encode and decode data as given by the CPU through a base band <b>207</b>. LM and L2CAP run directly on top of base band <b>207</b>. RFCOMM and SDP run on top of L2CAP.

[0060] Furthermore, within the memory <b>205</b> is an OBEX bridge application <b>221</b>. The bridge application obtains information from OBEX clients <b>101</b> and further relays them to OBEX servers <b>299</b>.

[0061] The OBEX bridge <b>250</b> communicates via the Bluetooth transceiver <b>207</b> with a client <b>101</b> wirelessly <b>233</b>. Furthermore, the OBEX bridge, via the network interface <b>220</b>, is disposed in communication <b>266</b> with a communications network <b>244</b> which enables communications <b>298</b> with an OBEX server <b>299</b>.

[0062] OBEX Server

[0063]FIG. 3 is a schematic overview of an OBEX server according to one embodiment of the invention.

[0064] OBEX Server Systemization

[0065] In one non-limiting example embodiment, the OBEX server <b>399</b> may comprise a clock <b>303</b>, central processing unit (CPU) <b>302</b>, a memory <b>305</b>, a power source <b>304</b>, I/O components <b>380</b>, <b>381</b>, <b>382</b>, <b>320</b>. The power source <b>304</b> provides power to the OBEX server. The I/O interface <b>380</b> may be any number of busses that allow for the interconnection of peripheral and input output devices, such as, but not limited to a keyboard <b>382</b>, a monitor <b>381</b>, a network interface <b>320</b>, and/or the like. Conventionally, although not necessarily, the client components are all interconnected and/or communicating through a system bus <b>377</b>. The system clock <b>303</b> typically has a crystal oscillator and provides a base signal. The clock is typically coupled to the system bus and various means that will increase or decrease the base operating frequency for other components interconnected in the bridge. The clock and various components in the client drive signals embodying information throughout the client. Such transmission and reception of signals embodying information throughout the client may be commonly referred to as communications. These communicative signals may further be transmitted, received, and the cause of return and/or reply signal communications beyond the instant bridge to: communications networks, input devices, other computer systems (e.g., servers), peripheral devices, bridges, and/or the like. Of course, any of the above components may be connected directly to one another, connected to the CPU, and/or organized in numerous variations employed as exemplified by various computer systems and servers. Optionally the client may include various input/output devices, which are also disposed in communication with the CPU through the system bus and/or directly. The network interface <b>320</b> may be an Ethernet card, an ISDN card, a DSL card, and/or the like enabling communications <b>398</b> with the communications network <b>344</b>.

[0066] CPU

[0067] The CPU <b>102</b> comprises at least one data processor adequate to execute program modules for executing user and/or system-generated requests. The CPU may be a microprocessor such as the Intel Pentium Processor and/or the like. The CPU interacts with memory through signal passing through conductive conduits to execute stored program code according to conventional data processing techniques. Such signal passing facilitates communication within the communication networks and beyond through various interfaces.

[0068] Memory

[0069] It is to be understood that the OBEX server may employ various forms of memory <b>305</b>. In a typical configuration, memory <b>305</b> will include ROM, RAM, and a fixed storage device <b>340</b>, e.g., a hard disk drive. Generally, any mechanization and/or embodiment allowing a processor to affect the storage and/or retrieval of information is regarded as memory <b>305</b>. Thus, an OBEX server generally requires and makes use of memory. However, memory is a fungible technology and resource, thus, any number of memory embodiments may be employed in lieu of or in concert with one another.

[0070] Module Collection

[0071] The memory <b>305</b> may contain a collection of program modules and/or data such as, but not limited to: an operating system module <b>330</b> (operating system); an OBEX server application <b>321</b>; TCP/IP stack <b>322</b>; and OBEX file content <b>341</b>, which may be stored in the storage device <b>340</b> and retrieved into memory <b>305</b> as needed. The OBEX server application.

[0072] OBEX Server Application

[0073] An OBEX Server Application module <b>321</b> is stored program code that is executed by the CPU. The OBEX server may be a conventional OBEX information server such as, but not limited to, OpenOBEX. Optionally, the information server allows for the execution of program modules through facilities such as C++, Java, JavaScript, ActiveX, Common Gateway Interface (CGI) scripts, Active Server Page (ASP), and/or the like. Execution of these program modules in general is required in order to produce dynamic content (equivalent to use as in web servers). Optionally, the information server supports secure communications protocols such as, but not limited to, File Transfer Protocol (FTP); HyperText Transfer Protocol (HTTP); Object Exchange (OBEX) protocol, Secure Hypertext Transfer Protocol (HTTPS), Secure Socket Layer (SSL), and/or the like. Conventionally, an OBEX server provides results in the form of exchange objects, and allows for the manipulated generation of exchange objects through interaction with other program modules. An OBEX server may communicate to and/or with other modules in a module collection, including itself, and/or facilities of the like. Most frequently, the OBEX server communicates with operating systems, other program modules, user interfaces, and/or the like. An information server may contain, communicate, generate, obtain, and/or provide program module, system, user, and/or data communications, requests, and/or responses.

[0074] Operating System

[0075] The operating system module <b>330</b> is executable program code facilitating the operation of the OBEX server. Typically, the operating system facilitates access of I/O, network interfaces, peripheral devices, storage devices, and/or the like. The operating system also may provide user interface functionality allowing an user to interact with the bridge. The operating system preferably is a conventional product such as Apple Macintosh OS X Server, AT&amp;T Plan 9, Microsoft Windows NT Server, Unix, and/or the like operating systems. Preferably, the operating system is highly fault tolerant, scalable, and secure. An operating system may communicate to and/or with other modules in a module collection, including itself, and/or facilities of the like. Conventionally, the operating system communicates with other program modules, user interfaces, and/or the like. For example, the operating system may contain, communicate, generate, obtain, and/or provide program module, system, user, and/or data communications, requests, and/or responses. The operating system, once executed by the CPU, may enable the interaction with communications networks, data, I/O, peripheral devices, program modules, memory, user input devices, and/or the like. Preferably, the operating system provides communications protocols that allow the client to communicate with other entities through a communications network <b>344</b>. Various communication protocols may be used by the bridge as a subcarrier transport mechanism for interacting with other devices, such as, but not limited to: multicast, OBEX <b>121</b>, TCP/IP <b>122</b>, UDP, unicast, and/or the like. The TCP/IP stack enables TCP/IP communications through the network interface <b>320</b>.

[0076] The OBEX server is disposed in communication <b>398</b> with a communications network <b>344</b> via the network interface <b>320</b>. This enables communications <b>366</b> with the OBEX bridge <b>250</b> which is further disposed in communication <b>333</b> with an OBEX client <b>101</b>.

[0077] OBEX Client-Bridge-Server Connection

[0078]FIG. 4 shows an OBEX client-server-bridge connection <b>400</b> according to one embodiment of the invention and provides an exemplary data flow diagram. The data flows are between an OBEX client <b>401</b>, an OBEX bridge <b>450</b> and an OBEX server <b>499</b>. The OBEX client has come within proximity of OBEX bridge <b>450</b> to establish a short range RF communication connection <b>433</b>, such as Bluetooth, via the BaseBand <b>406</b>. The OBEX client is running an OBEX client application <b>121</b>. The OBEX client application creates certain data requests in OBEX format. Those requests are processed by the client's CPU employing short range RF protocols, such as Bluetooth, into RFCOMM data blocks <b>423</b><i>a</i>. The Link Manager <b>428</b><i>a </i>and the L2CAP <b>475</b><i>a </i>help take the RFCOMM encoded OBEX communications and provide those as data to a Baseband transceiver <b>406</b><i>a </i>which will communicate via Bluetooth protocols to an OBEX bridge <b>450</b> by establishing a connection to the OBEX bridge's Baseband transceiver <b>406</b><i>b. </i>The received data signals follow an inverse route in the OBEX bridge; the RF communications received from the OBEX client <b>401</b> by the OBEX bridge <b>450</b> in the OBEX bridge's Baseband facility <b>406</b><i>b </i>are then decoded by the LM <b>478</b><i>b </i>and the L2CAP <b>475</b><i>b </i>up into a serial data format via the RFCOMM <b>423</b><i>b </i>resulting in the original OBEX communication from the client <b>401</b>.

[0079] For each OBEX client establishing a connection <b>433</b>, the OBEX bridge <b>450</b> creates a handle to the communications being provided via RFCOMM <b>423</b><i>b </i>channel (typically the handle is a pointer that references an area of memory of a memory buffer <b>223</b>) and assigns and associates an internal, unique IP address to that handle. Thus, the OBEX bridge creates and maintains a table data-structure of at least two columns (bridge table) <b>489</b> comprising a handle to an RFCOMM channel established from a client communication connection (client RFCOMM handle) <b>487</b> and an associated, generated, internal IP address (client IP address) <b>488</b>. The bridge table may be implemented using various standard data structures, such as an array, hash, (linked) list, struct, and/or the like. Such data structures may be stored in memory and/or in (structured) files.

[0080] The OBEX bridge application <b>421</b> then obtains the OBEX data request that was originally generated by the client <b>121</b> by way of client RFCOMM handles (for data obtained from a particular client <b>401</b>). Upon obtaining the OBEX data request from the memory buffer, the OBEX bridge application <b>421</b> then encapsulates the OBEX data request into TCP/IP packets. These packets are then sent to a TCP/IP layer <b>422</b><i>a, </i>which further provides the TCP/IP communications as a data link <b>407</b><i>a, </i>which is eventually sent over a physical carrier medium such as Ethernet <b>420</b><i>a. </i>When generating the TCP/IP packet headers, the OBEX bridge stamps the originating IP address as being the client IP address <b>488</b> that was generated and associated with a particular client RFCOMM handle <b>487</b>; the OBEX bridge application may do so by looking to the bridge table <b>489</b>. When determining the destination IP address for the OBEX data request, the OBEX bridge application <b>421</b> may consult an internal OBEX server lookup list. This lookup list is comprised of IP addresses. The list may contain a single entry, or a plurality of IP addresses. The choice of which OBEX server is chosen from the lookup list may be governed by any number of load balancing and/or context sensitive heuristics. For example, based on the client's GOEP profile and OBEX server specializing in File Transfer Profile, Object Push Profile or Synchronization Profile may be specified. In another non-limiting example embodiment, an OBEX server with the lowest usage load may be employed. The look-up list may be implemented using various standard data structures, such as an array, hash, (linked) list, struct, and/or the like. Such data structures may be stored in memory and/or in (structured) files. Upon stamping the origination and destination IP addresses in the resulting TCP/IP packets, the TCP/IP communications from the OBEX bridge are communicated <b>466</b> by the OBEX bridges network interface <b>420</b><i>a. </i>The OBEX communications from the OBEX bridge <b>421</b> are then communicated <b>466</b> over a communications network <b>344</b> to a network interface <b>420</b><i>b </i>on the OBEX server <b>499</b>. Those communications are in turn provided to the data link <b>407</b><i>b </i>of the OBEX server <b>499</b> and provided in the form of TCP/IP packets <b>422</b><i>b, </i>which are then interpreted by the OBEX server application software <b>221</b>. The OBEX server application <b>221</b> then can process the OBEX encoded data and requests and provide back results and responses to the client <b>401</b> via the bridge <b>450</b>. Thus, the OBEX response signal from the OBEX server application <b>221</b> take the inverse path by which it originated.

[0081] Thus, the connection between an OBEX client and an OBEX bridge <b>433</b> that occur via Baseband <b>406</b> RF signals are provided by a conceptual RFCOMM channel <b>423</b>, <b>433</b><i>b. </i>Furthermore, the TCP connection between the OBEX bridge and OBEX server <b>466</b> that occur via network interfaces <b>420</b> and a communications network <b>344</b> are provided by a conceptual TCP/IP connection <b>466</b><i>b. </i>Thus, the RFCOMM channel between the client and bridge plus the TCP/IP connection between the bridge and server create a conceptual OBEX connection <b>400</b>. It's important to note that this OBEX connection can take place over a communications network and the OBEX server does not have to be placed in proximity with the OBEX client, rather communications can take place through the OBEX bridge through a communications network such as the Internet.

[0082] OBEX Server

[0083]FIG. 5 details a flow diagram of one example communications flow between an OBEX client, OBEX bridge and an OBEX server. Box <b>501</b> shows that an OBEX client application <b>121</b> is instantiated. The application may be instantiated by invoking commands via an input keyboard or voice or other input means that will cause the client application to be executed by the client's CPU. In one non-limiting example the OBEX client application is instantiated as soon as the client is turned on. Upon this instantiation of the OBEX client application box <b>502</b> shows the client sets up a short range RF connection, such as Bluetooth, with the OBEX bridge as has been discussed in FIG. 4.

[0084] Box <b>503</b> shows that upon establishing the communications between the client and the OBEX bridge application, the client uses the service discovery protocol to inquire about other short range RF device's capabilities and the associated GEOP parameters (in this case the Access Point (AP), i.e., the AP including an OBEX bridge, which contains the bridge application). Box <b>504</b> shows that the OBEX application bridge <b>421</b> responds using service discovery protocol giving out the parameters needed for the GOEP profile. Box <b>505</b> shows the client initiates protocols based on the GOEP profile it received from the server via the OBEX bridge. Box <b>506</b> shows that an RFCOMM channel is formed between the client and the OBEX bridge application.

[0085] Box <b>507</b> shows that upon the formation of an RFCOMM channel between the client and the bridge, the bridge internally assigns an IP address and binds it to a client RFCOMM handle. Box <b>508</b> shows that upon generating and associating an internal IP address to the client RFCOMM handle that the OBEX bridge thereafter establishes a TCP/IP connection with the remote OBEX server. Box <b>509</b> shows that after the establishment of a TCP/IP connection with the OBEX server, the OBEX client may then begin sending data to the OBEX bridge through the RFCOMM connection. Box <b>510</b> shows that the bridge receives data from the client via the RFCOMM connection and encapsulates it into TCP/IP packets. Therefore the OBEX application bridge <b>421</b> routes data from the RFCOMM communications <b>433</b><i>b </i>of the client to the TCP/IP socket in the OBEX bridge. These TCP/IP encapsulated packets are sent to the OBEX bridge's network interface <b>420</b><i>a. </i>After the OBEX application bridge <b>421</b> encodes the data into TCP/IP packets, the data is sent to the OBEX server wherein an OBEX server application <b>221</b> will thereafter obtain the data and process the OBEX requests. Any responses from the OBEX server will be sent back to the bridge via TCP/IP communications through the OBEX server network interface <b>420</b><i>b. </i>

[0086] Box <b>511</b> shows that the responses from the OBEX server <b>499</b> that are destined for the OBEX client <b>401</b> are received by the OBEX bridge <b>450</b> in the corresponding TCP/IP address that was generated by the OBEX bridge. The OBEX bridge uses the bridge table <b>489</b> to look up the client RFCOMM handle <b>487</b> associated to the client IP address <b>488</b> that received the communications from the OBEX server. Next, the bridge encapsulates the data that was received in the form of TCP/IP packets from the OBEX server and routes that data from the TCP/IP socket to the RFCOMM handle. This routing is accomplished by a lookup table that is established upon the creation of an RFCOMM handle as shown in box <b>507</b> and in FIG. 4. Thus, the bridge table <b>489</b> acts as a routing table to ensure that information flows properly between each client's data request and any respective results from an OBEX server. This is important in an environment where there are multiple OBEX and short range RF enabled clients that are disposed in communications with the OBEX bridge. Thus, upon performing a look up for the correct RFCOMM handle, the TCP/IP information obtained from the OBEX server is encapsulated into RFCOMM packets. The OBEX bridge then sends the RFCOMM encoded data through a wireless Baseband channel back to the client.

[0087] Box <b>512</b> shows that the client receives the data through the RFCOMM channel. Box <b>513</b> shows that boxes <b>509</b>, <b>510</b>, <b>511</b> and <b>512</b> may be repeated until the client disconnects from the RFCOMM link or the short range RF link (e.g., Bluetooth).

[0088] Box <b>514</b> shows that the bridge terminates the TCP/IP connection to the remote server and releases the assigned IP address.

[0089] It should be understood that the above description is only representative of illustrative embodiments. For the convenience of the reader, the above descriptions have focused on a representative sample of all possible embodiments, a sample that teaches the principles of the invention. The description has not attempted to exhaustively enumerate all possible variations. That alternate embodiments may not have been presented for a specific portion of the invention or that further undescribed alternate embodiments may be available for a portion is not to be considered a disclaimer of those alternate embodiments. It will be appreciated that many of those undescribed embodiments incorporate the same principles of the invention and others are equivalent. Thus, it is to be understood that the embodiments and variations shown and described herein are merely illustrative of the principles of this invention and that various modifications may be implemented without departing from the scope and spirit of the invention.