Abstract: A universal plug and play (UPnP) device makes itself known through a set of processes—discovery, description, control, eventing, and presentation. Following discovery of a UPnP device, an entity can learn more about the device and its capabilities by retrieving the device's description. The description includes vendor-specific manufacturer information like the model name and number, serial number, manufacturer name, URLs to vendor-specific Web sites, etc. The description also includes a list of any embedded devices or services, as well as URLs for control, eventing, and presentation. The description is written by a vendor, and is usually based on a device template produced by a UPnP forum working committee. The template is derived from a template language that is used to define elements to describe the device and any services supported by the device. The template language is written using an XML-based syntax that organizes and structures the elements.

Abstract: A method for providing an interface to a Bluetooth compliant device can emulate a modem such that computer software programs can communicate through the Bluetooth compliant device in the same manner in which they would communicate through a standard modem to access a dial-up, wide area network. The method also supports an interface to a Bluetooth compliant device which can emulate a network socket such that computer software programs can communicate through the Bluetooth compliant device seemingly in the same manner in which they would communicate through a standard network interface card to access a local area network. The method also allows for the interface to a Bluetooth compliant device to be dependent on the nature of the Bluetooth compliant device.

Abstract: Handles associate respective native resources with an application that utilizes a library to call for the native resource. Each handle is created to track a native resource that has been allocated to an application. All native resources associated with the application are freed by examining the handles to find those native resources still being held by the application after they are no longer being used, or when that application has been, or is being, terminated. If a native resource is requested by the application and found to be unavailable, the handles are reviewed to collect allocated native resources that are found to be unneeded by their respective applications. A collected native resource corresponding to the requested native resource is thereby made available to be reallocated to the requesting application.

Abstract: A device hosting framework provides hosting for software-implemented logical devices (including peripheral devices bridges) on a computer to expose their services as controlled devices per a peer networking protocol. The device hosting framework encapsulates discovery, description and control protocol operations of the peer networking protocol, which frees the developers of the hosted devices from having to individually implement the peer networking protocol in the hosted devices' software and need implement only the core functionality of the hosted device. The device hosting framework operates as a host supporting device interoperability via the peer networking protocol for multiple hosted devices.

Abstract: A device control model provides an integrated set of addressing, naming, discovery and description processes that enables automatic, dynamic and ad-hoc self-setup by devices to interoperate with other devices on a network. This permits a computing device when introduced into a network to automatically configure so as to connect and interact with other computing devices available on the network, without a user installation experience and without downloading driver software or persisting a configuration setup for connecting and interacting with such other computing devices. Upon completing interaction with such other devices, the computing device automatically releases the setup for such other devices so as to avoid persistent device configurations that might create a configuration maintenance and management burden.

Abstract: Controlled devices according to a device control model maintain a state table representative of their operational state. Devices providing a user control point interface for the controlled device obtain the state table of the controlled device, and may also obtain presentation data defining a remoted user interface of the controlled device and device control protocol data defining commands and data messaging protocol to effect control of the controlled device. These user control devices also subscribe to notifications of state table changes, which are distributed from the controlled device according to an eventing model. Accordingly, upon any change to the controlled device's operational state, the eventing model synchronizes the device's state as represented in the state table across all user control devices.

Abstract: The invention makes possible remote control of devices in a piconet by remote users communicating over the Internet and the like by providing a proxy-bridge device. The proxy-bridge device is a bridge for sending packets to and from between an external device and a device in the piconet. Moreover, the proxy-bridge device also serves as a proxy for the external device to devices in the piconet and as a proxy for devices in the piconet accessing an external device. The proxy-bridge wireless device's protocol stack allows communications with the piconet devices within the piconet. In addition, the protocol stack allows an application to communicate with a remote device e.g., via the Internet Protocol. Thus, the proxy-bridge device, using two protocols, enables remote users discover the presence of a service offered by a device in a piconet as a logical embedded device within the proxy-bridge device and vice-versa.

Abstract: A general programmatic interface-to-network messaging adapter exposes a suitable object integration interface or application programming interface to applications on a controller device and sends network data messages to invoke services or query status of a controlled device. The adapter maps application calls to the interface into network data messages according to service protocols of the controlled device. The general adapter provides the interface suitable to any specific service of a controlled device based on a data description of the interface, and converts the application calls to network data messages based on a data description of a protocol and format for network data messages to interact with the specific service. Once the interface/messaging description is obtained, applications on the controller device can programmatically interact with the adapter, and the adapter then handles appropriate message exchanges with the service of the controlled device.

Abstract: A method, apparatus, and computer program product provide applications and application developers with generic access from user mode to the L2CAP layer of Bluetooth by exposing the L2CAP layer to user mode via a socket interface. In particular, a kernel mode primary component and user mode helper component cooperate to expose a Winsock interface to user mode components, and to manage various Bluetooth-specific functions and operations, allowing a user mode user application to access Bluetooth functionality without providing Bluetooth-specific commands or actions, and without being required to use RFCOMM.

Abstract: A self-installing and configuring peer networking-to-host/peripheral connectivity adapter, such as a set of software modules running on a host, operates to convert between a device control protocol with peer networking connectivity and a host/peripheral connectivity protocol for a set of host-connected peripheral devices. The adapter is automatically installed on the host upon connecting a new peripheral device, such as by a plug-and-play operating system of the host. The adapter operates as a peer-networking addressable controlled device module, which responds to communication in the device control protocol from other peer devices that are networked with the host. The adapter converts the device control protocol communications from the peer devices into a host/peripheral protocol for controlling the peripheral devices. The peripheral devices thereby are controllable as peer networking devices via the peer networking connectivity device control protocol.

Abstract: Handles associate respective native resources with an application that utilizes a library to call for the native resource. Each handle is created to track a native resource that has been allocated to an application. All native resources associated with the application are freed by examining the handles to find those native resources still being held by the application after they are no longer being used, or when that application has been, or is being, terminated. If a native resource is requested by the application and found to be unavailable, the handles are reviewed to collect allocated native resources that are found to be unneeded by their respective applications. A collected native resource corresponding to the requested native resource is thereby made available to be reallocated to the requesting application.

Abstract: Controlled devices according to a device control model maintain a state table representative of their operational state. Devices providing a user control point interface for the controlled device obtain the state table of the controlled device, and may also obtain presentation data defining a remoted user interface of the controlled device and device control protocol data defining commands and data messaging protocol to effect control of the controlled device. These user control devices also subscribe to notifications of state table changes, which are distributed from the controlled device according to an eventing model. Accordingly, upon any change to the controlled device's operational state, the eventing model synchronizes the device's state as represented in the state table across all user control devices.

Abstract: A device hosting framework provides hosting for software-implemented logical devices (including peripheral devices bridges) on a computer to expose their services as controlled devices per a peer networking protocol. The device hosting framework encapsulates discovery, description and control protocol operations of the peer networking protocol, which frees the developers of the hosted devices from having to individually implement the peer networking protocol in the hosted devices' software and need implement only the core functionality of the hosted device. The device hosting framework operates as a host supporting device interoperability via the peer networking protocol for multiple hosted devices.

Abstract: A device control model provides an integrated set of addressing, naming, discovery and description processes that enables automatic, dynamic and ad-hoc self-setup by devices to interoperate with other devices on a network. This permits a computing device when introduced into a network to automatically configure so as to connect and interact with other computing devices available on the network, without a user installation experience and without downloading driver software or persisting a configuration setup for connecting and interacting with such other computing devices. Upon completing interaction with such other devices, the computing device automatically releases the setup for such other devices so as to avoid persistent device configurations that might create a configuration maintenance and management burden.

Abstract: The invention makes possible remote control of devices in a piconet by remote users communicating over the Internet and the like by providing a proxy-bridge device. The proxy-bridge device is a bridge for sending packets to and from between an external device and a device in the piconet. Moreover, the proxy-bridge device also serves as a proxy for the external device to devices in the piconet and as a proxy for devices in the piconet accessing an external device. The proxy-bridge wireless device's protocol stack allows communications with the piconet devices within the piconet. In addition, the protocol stack allows an application to communicate with a remote device e.g., via the Internet Protocol. Thus, the proxy-bridge device, using two protocols, enables remote users discover the presence of a service offered by a device in a piconet as a logical embedded device within the proxy-bridge device and vice-versa.