US20130232218A2 - Systems, methods and articles for providing communications and services via a peer-to-peer network over a data transport link - Google Patents

Abstract

Network communications, Web-based services and customized services using the Web-based services may be provided over a peer-to-peer network from a first peer to a second peer (e.g., automobile head unit) wherein the first peer has a separate connection to a more general server-based network such as the Internet. A communications device application based on a peer communications framework component in communication with a peer network stack on the communications device may work as middleware, with a connection to both a more general server-based network such as the Internet and to an external device, such as a head unit of an automobile. Although the communications device has a separate connection out to the Internet via a general network stack co-existing on the same communications device, the peer network stack and the general network stack are not directly connected.

Description

BACKGROUND
• 1. Technical Field
• This disclosure relates to providing communications and services to a device (e.g., vehicle head unit) that does not otherwise have a connection to a server-based network such as the Internet.
• 2. Description of the Related Art
• As information services increasingly become Web-based, continuous or near continuous access to the Internet for communications and data processing devices becomes more important for end users and businesses to be able to access these services in a timely and useful manner.
• For example, many communications devices such as cell phones, personal digital assistants and other hand-held form factor mobile communications devices implement Internet access functionality via cellular digital mobile telecommunications systems according to the International Mobile Telecommunications-2000 (IMT-2000), better known as the 3rd Generation (3G), family of standards for mobile telecommunications. However, many other devices such as vehicles, home appliances, and other isolated products having various embedded systems may not have such communications functionality built in, or may not have connections to particular communication service carriers or providers needed to access many Web-based services on the Internet.
• One solution may be to use dial-up networking (DUN) functionality included on various mobile communications devices (e.g., Bluetooth® DUN) to operate the mobile communications device as a modem to allow another device based services through the mobile communications device. However, many mobile communications devices do not have such DUN capability or such DUN functionality is disabled or switched off by the service provider, retailer or cell phone manufacturer.
• Thus, an improved approach that provides connectivity and customized services to a device that does not otherwise have connectivity to a more general server-based network such as the Internet is desirable.
BRIEF SUMMARY
• As described in detail herein, communications, Web-based services and customized services utilizing the Web-based services may be provided over a peer-to-peer network from a first peer to a second peer wherein the first peer has a separate connection to a more general server-based network such as the Internet. For example, the second peer may be a head unit of an automobile and the first peer may be a mobile communications device such as a cell phone, PDA or other communications device having a handheld form factor (i.e., handheld communications device). A communications device application based on a peer communications framework component in communication with a peer network stack on the handheld communications device may work as middleware, with a connection to both a more general server-based network such as the Internet and to an external device, such as the head unit. Although the handheld communications device has a separate connection out to the Internet via a general network stack co-existing on the communications device, the peer network stack and the general network stack are not directly connected.
• A method of providing communications between a head unit of an automobile, a communications device having a handheld form factor, and a server-based network through which Internet access is provided, may be summarized as: receiving one or more requests via a peer-to-peer network stack by the communications device from the head unit over a serial data transport link between the head unit and the communications device; and performing a service specified in the one or more requests in response to the one or more requests, the service comprising: forwarding a request to the server-based network from the communications device via a general network stack separate from the peer-to-peer network stack; receiving a response from the server-based network via the general network stack; and forwarding at least a portion of the response to the head unit over the serial data transport link. Additional embodiments may include a determination of whether the request is to be handled by a service via an external server-based network and performing the service locally or via forwarding the request to the server-based network according to the determination.
• The link and the performing of the service may occur irrespective of whether a network packet sent over the serial data transport link from the head unit containing the one or more requests includes the network address of the communications device as a destination network address. The method may further include configuring a user interface of the head unit to visually match a corresponding user interface of the communications device by communicating information over the serial data transport link from the communications device to the head unit, said information containing data adapted for use by the head unit to configure the user interface of the head unit to visually match the corresponding user interface of the communications device. Information included in the at least a portion of the response forwarded to the head unit may be for display on the user interface of the head unit configured to visually match the corresponding user interface of the communications device. The method may further include: receiving at least one additional request via the peer-to-peer network stack by the communications device from the head unit over a serial data transport link; determining whether the at least one additional request corresponds to a service on a specified list of services; and forwarding the at least one additional request to the server-based network from the communications device through the general network only if it was determined that the at least one additional request corresponds to a service on the specified list of services. The method may further include: caching at least a portion of the response on the communications device based upon previous monitoring on the server-based network types of and patterns of the received one or more requests. The serial data transport link between the head unit and the communications device may be either a Bluetooth® Serial Port Profile (SPP) type serial data transport link or Universal Serial Bus (USB) type serial data transport link.
• A method for communicating in a communication network environment between a first and a second network peer over a direct serial data transport link between the first network peer and the second network peer, wherein there is an established data transport connection between the first network peer and the second network peer over the direct serial data transport link and wherein the first network peer has a separate connection over a separate network interface to a network external to the link, may be summarized as: receiving communications from the second network peer by the first network peer over the direct serial data transport link, the direct serial data transport link supporting at least one network in which only two network addresses are used at a given time on the network, the two network addresses consisting of a first network address for the first network peer and a second network address for the second network peer; extracting payloads by the first network peer from the communications irrespective of whether network packets containing the payloads include the first network address as a destination network address; and responding by the first network peer to a service request included in one or more of the communications received from the second network peer by providing data to the second network peer that was originally obtained by the first network peer through the separate connection to the network external to the direct serial data transport link, and wherein the established data transport connection between the first network peer and the second network peer on the direct serial data transport link is one in which resolution of network addresses of the first network peer and the second network peer to hardware addresses of the first network peer and the second network peer is not necessary for the responding by the first network peer to the service request.
• The data provided to the second network peer may be over the established data transport connection between the first network peer and the second network peer. There may be second established connection using a separate transport on a separate network from the established data transport connection between the first network peer and the second network peer. The network external to the link may be a server-based network.
• A method for communicating in a communication network environment between a first and a second network peer over a peer-to-peer network connection on a serial data transport link between the first network peer and the second network peer, may be summarized as: receiving communications from the second network peer by the first network peer on the peer-to-peer network connection over the serial data transport link, wherein the first network peer has particular network services available natively at the first network peer; and handling the communications received such that the second network peer may send communications over the serial data transport link including requests for one or more particular network services not available natively at the first network peer while keeping the peer-to-peer connection over the serial data transport link between the first network peer and the second network peer active and such that the handling the communications received from the second network peer enables the second network peer to handle network communications in a same manner irrespective of whether the one or more particular network services are available at all to the second network peer.
• The peer-to-peer network connection may be a connection using Transmission Control Protocol/Internet Protocol (TCP/IP) and either Serial Line Internet Protocol (SLIP) or Point to Point Protocol (PPP). At least one of the one or more particular network services not available natively at the first network peer may be an Address Resolution Protocol (ARP) service or a Dynamic Host Configuration Protocol (DHCP) service.
• A system may be summarized as including: at least one computer processor; at least one processor-readable storage medium coupled to the at least one computer processor; a peer communications control component under control of the at least one computer processor; a first communications component that is in operable communication with the peer communications control component and has a peer-to-peer network stack configured to receive requests through a data transport connection over a serial data transport link to a head unit of an automobile and forward requests to the peer communications control component; and a second communications component that is in operable communication with the peer communications control component and has a general network stack configured to send and receive communications from a server-based network that is external to the data transport connection and that is operable to provide Internet access, and wherein the second communications component is configured to: forward a request received from the first communications component via the peer communications control component to the server-based network via the general network stack; receive a response from the server-based network via the general network stack; and forward at least a portion of the response to the head unit over the serial data transport link.
• The at least one computer processor, the at least one processor-readable storage medium, the peer communications control component, the first communications component, and the second communications component may all be housed within a communications device having a handheld form factor. The first communications component may send service requests to the head unit originating from one or more applications under control of one or more processors of the system and may send service requests to the head unit originating from the server-based network that is operable to provide Internet access. The first communications component and the head unit may each have a network address to use over the serial data transport link and the peer-to-peer network stack may receive the requests through the data transport connection irrespective of whether a network packet containing the one or more requests sent over the serial data transport link from the head unit includes the network address of the first communications component as a destination network address. The peer communications control component may configure a user interface of the head unit to visually match a corresponding user interface of the system by communicating information over the serial data transport link from the first communications component to the head unit, said information containing data adapted for use by the head unit to configure the user interface of the head unit to visually match the corresponding user interface of the system. Information included in the at least a portion of the response to forward to the head unit may be for display on the user interface of the head unit configured to visually match the corresponding user interface of the communications device. The peer communications control component may determine whether one or more requests received through the first communications component from the head unit corresponds to a service on a specified list of services and, if it is determined that the one or more requests received through the first communications component from the head unit corresponds to a service on the specified list of services, may forward such one or more requests received to the server-based network through the second communications component. The peer communications control component may monitor types of and patterns of the requests received through the data transport connection and cache on the at least one processor-readable storage medium of the system at least a portion of a response received from the server-based network based upon the types of and patterns of the requests received. The serial data transport link may be either a Bluetooth® type or Universal Serial Bus (USB) type serial data transport link.
• An article of manufacture may be summarized as including: a processor-readable storage medium having processor-executable instructions stored thereon for: providing communications between a head unit of an automobile, a communications device having a handheld form factor, and a server-based network through which Internet access may be provided, the providing communications comprising: receiving one or more requests via a peer-to-peer network stack by the communications device from the head unit over a serial data transport link between the head unit and the communications device; and performing a service specified in the one or more requests in response to the one or more requests comprising: forwarding a request to a server-based network from the communications device via a general network stack separate from the peer-to-peer network stack; receiving a response from the server-based network via the general network stack; and forwarding at least a portion of the response to the head unit over the serial data transport link.
• The communications device and the head unit may each have a network address to use over the serial data transport link and the performing the service may occur irrespective of whether a network packet containing the one or more requests sent over the serial data transport link from the head unit includes the network address of the communications device as a destination network address. The providing communications may further comprise configuring a user interface of the head unit to visually match a corresponding user interface of the communications device by communicating information over the serial data transport link from the communications device to the head unit, said information containing data adapted for use by the head unit to configure the user interface of the head unit to visually match the corresponding user interface of the communications device. Information included in the at least a portion of the response forwarded to the head unit may be for display on the user interface of the head unit configured to visually match the corresponding user interface of the communications device. The article of manufacture may have further processor-executable instructions stored thereon for: receiving at least one additional request via the peer-to-peer network stack by the communications device from the head unit over a serial data transport link; determining whether the at least one additional request corresponds to a service on a specified list of services; and in response to determining that the at least one additional request corresponds to a service on the specified list of services, forwarding the at least one additional request to the server-based network from the communications device via the general network. The article of manufacture may have further processor-executable instructions stored thereon for: caching at least a portion of the response on the communications device based upon previous monitoring on the server-based network types of and patterns of the received one or more requests. The serial data transport link between the head unit and the communications device may be either a Bluetooth® Serial Port Profile (SPP) type serial data transport link or Universal Serial Bus (USB) type serial data transport link.
BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS
• In the drawings, identical reference numbers identify similar elements or acts. The sizes and relative positions of elements in the drawings are not necessarily drawn to scale. For example, the shapes of various elements and angles are not drawn to scale, and some of these elements are arbitrarily enlarged and positioned to improve drawing legibility. Further, the particular shapes of the elements as drawn, are not intended to convey any information regarding the actual shape of the particular elements, and have been solely selected for ease of recognition in the drawings.
• FIG. 1 is a system diagram of a networked environment according to one illustrated embodiment, the networked environment including an automobile head unit, a handheld communications device, a cellular tower and station, and a computer network, the automobile head unit and handheld communications device communicatively linked by a short range wireless signal, the handheld communications device and cellular tower and station communicatively linked by a cellular signal, the handheld communications device and computer network optionally linked by one or more communications networks (e.g., using Wi-Fi signal), and the cellular tower and station and computer network communicatively linked by one or more communications networks (e.g., using a cellular or other signal).
• FIG. 2 is a schematic view of the handheld communications device shown in more detail according to one illustrated embodiment, the handheld communications device having a housing, a display, a graphics engine, a central processing unit (CPU), user input device(s), one or more storage mediums having various software modules thereon that are executable by the CPU, input/output (I/O) port(s), network interface(s), wireless receiver(s) and transmitter(s), and a power source.
• FIG. 3 is a schematic diagram, according to one illustrated embodiment, showing software modules of the handheld communications device in more detail including an application, a peer communications framework component, a network stack of the handheld communications device interconnected with a network stack of the automobile head unit, and another network stack of the handheld communications device interconnected to another computer network.
• FIG. 4 is a schematic diagram showing, according to one illustrated embodiment, the peer communications framework component and the network stacks of the handheld communications device in greater detail including their logical connectivity to each other and a file system of the handheld communications device.
• FIG. 5 is a flow diagram showing a method of providing communications between an automobile head unit, a handheld communications device, and a server-based computer network via which Internet access is provided, according to one illustrated embodiment.
• FIG. 6 is a flow diagram showing a method of providing communications between an automobile head unit, a communications device having a handheld form factor and a server-based computer network, including filtering service requests, according to one illustrated embodiment.
• FIG. 7 is a flow diagram showing a method of providing communications between an automobile head unit, a communications having a handheld form factor device and a server-based computer network, including intelligent caching, according to one illustrated embodiment.
• FIG. 8 is a flow diagram showing a method for communicating in a communication network environment between a first and a second network peer over a direct serial data transport link including responding by the first network peer to a service request included in one or more of the communications, according to one illustrated embodiment.
• FIG. 9 is a flow diagram showing a method for communicating in a communication network environment between a first and a second network peer over a direct serial data transport including handling the communications received which have requests for particular network services, according to one illustrated embodiment.
DETAILED DESCRIPTION
• In the following description, certain specific details are set forth in order to provide a thorough understanding of various disclosed embodiments. However, one skilled in the relevant art will recognize that embodiments may be practiced without one or more of these specific details, or with other methods, components, materials, etc. In other instances, well-known structures associated with computer systems, databases, communications devices, and communications networks have not been shown or described in detail to avoid unnecessarily obscuring descriptions of the embodiments.
• Unless the context requires otherwise, throughout the specification and claims which follow, the word “comprise” and variations thereof, such as “comprises” and “comprising”, are to be construed in an open, inclusive sense, that is, as “including, but not limited to.”
• Reference throughout this specification to “one embodiment” or “an embodiment” means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment. Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
• As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” include plural referents unless the content clearly dictates otherwise. It should also be noted that the term “or” is generally employed in its broadest sense, meaning “and/or” unless the content clearly dictates otherwise.
• The headings and Abstract of the Disclosure provided herein are for convenience only and do not interpret the scope or meaning of the embodiments.
• FIG. 1 shows anetworked environment100 according to one illustrated embodiment. The networked environment may include anautomobile head unit102, a communications device having a handheld form factor (i.e., handheld communications device)104, a cellular tower andstation106, and acomputer network108. Theautomobile head unit102 may be any component of an automobile or vehicle configured to process or communicate information to a driver, passenger or other component of the automobile, or to control other components that process or communicate information to a driver, passenger or other component of the automobile. For example, theautomobile head unit102 may have computer processing, communications and data storage capabilities that are implemented by a combination of one or more embedded processing, memory and communications units or modules of theautomobile head unit102. Many automobile head units are typically a part of or control an automobile's in-dash stereo, navigation and/or other entertainment or driver information system.
• The handheld communications device can take the form of any of a large variety of mobile communications and/or processing devices having a handheld form factor. Examples of such may include cellular phones, personal digital assistants or PDAs (e.g., Blackberry® devices, iPhone® devices, Palm Pre® devices, Android® devices), cellular enabled laptop computers, netbook computers and tablet devices (e.g., IPAD® device).
• Theautomobile head unit102 andhandheld communications device104 may be communicatively linked by a shortrange wireless signal100. For example, this short range wireless signal may be that of a wireless Bluetooth® link. However, other wireless or wired connections that support serial or parallel data transport may also be used. The link between theautomobile head unit102 andhandheld communications device104 may be automatically established when thehandheld communications device104 comes into the vicinity of theautomobile head unit102 according to various protocols and/or standards of the applicable type of short range wireless link. The connectivity over the shortrange wireless signal110 may be enabled by theautomobile head unit102 and/or thehandheld communications device104 having the applicable hardware and software that provides the particular short-range wireless capability. For example, theautomobile head unit102 andhandheld communications device104 may both have wireless transmitters and receivers and, in the case of using a Bluetooth® wireless link, the corresponding executable Bluetooth® compatible network communications software that initiates, controls, maintains and manages the wireless link between theautomobile head unit102 and thehandheld communications device104 over the shortrange wireless signal110.
• Thehandheld communications device104 and cellular tower andstation106 may be communicatively linked by a wirelesscellular signal112 supporting mobile telecommunications. For example, the mobile telecommunications may be various digital mobile telecommunications including those according to the International Mobile Telecommunications-2000 (IMT-2000), better known as the 3rd Generation (3G), family of standards for mobile telecommunications fulfilling specifications by the International Telecommunication Union. Thehandheld communications device104 andcomputer network108 may be optionally linked by one or more communication links or networks. For example, the communications network may be a local area network that uses wireless fidelity (Wi-Fi) high frequency radio signals114 to transmit and receive data over distances of a few hundred feet. The local area network may be a wireless local area network (WLAN) based on the Institute of Electric and Electronic Engineers (IEEE) 802.11 standards. However, other wired and wireless communications networks and protocols may be used to link thehandheld communications device104 to thecomputer network108. Thus, thehandheld communications device104 may have applicable wireless transmitters and receivers and, in the case of using a Wi-Fi wireless link, the corresponding executable Wi-Fi compatible network communications software that initiates, controls, maintains or manages the wireless link between thecomputer network108 and thehandheld communications device104 over the Wi-Fi signal114.
• Thecomputer network108 may comprise other computing entities that provide services to the handheld communications device104 (i.e., a server-based network), and may itself represent multiple interconnected networks. For instance wired and wireless enterprise-wide computer networks, intranets, extranets, and/or the Internet may be included in or comprise a part ofcomputer network108. Other embodiments may include other types of communication networks including other telecommunications networks, cellular networks, paging networks, and other mobile networks. There may be any variety of computers, switching devices, routers, bridges, firewalls, edge devices and other devices withincomputer network108 and/or in the communications paths between thehandheld communications device104, the cellular tower andstation106 and thecomputer network108. In accordance with an aspect of the disclosure, thehandheld communications device104 may contain discrete functional program modules that might make use of an application programming interface (API), or other object, software, firmware and/or hardware, to request services of one or more of the other entities within thecomputer network108. Although the physical environment of thecomputer network108 may have connected devices such as computers, the physical environment may alternatively have or be described comprising various digital devices such as personal digital assistants (PDAs), televisions, MP3 players, etc., software objects such as interfaces, Component Object Model (COM) objects and the like.
• There are a variety of systems, components, and network configurations that may also support distributed computing environments within thecomputer network108. For example, computing systems may be connected to the together within thecomputer network108 by wired or wireless systems, by local networks or widely distributed networks. Currently, many networks are coupled to the Internet, which provides an infrastructure for widely distributed computing and encompasses many different networks. Any such infrastructures, whether coupled to the Internet or not, may be used in conjunction with, be connected to, or comprise part of thecomputer network108.
• The network infrastructure such as that shownFIG. 1 may enable a host of network topologies such as client/server, peer-to-peer, or hybrid architectures. The “client” is a member of a class or group that uses the services of another class or group to which it is not related. In computing, a client is a process, i.e., roughly a set of instructions or tasks, executed by hardware that requests a service provided by another program. Generally, the client process utilizes the requested service without having to “know” any working details about the other program or the service itself. In a client/server architecture, particularly a networked system, a client is usually a computer or device that accesses shared network resources provided by another computer, e.g., a server. In the example ofFIG. 2, any entity including theautomobile head unit102,handheld communications device104, cellular tower andstation106, and entities withincomputer network108, can be considered a client, a server, or both, depending on the circumstances.
• A server is typically, though not necessarily, a remote computer system accessible over a remote network, such as the Internet, or local network. The client process may be active in a first computer system or device, and the server process may be active in a second computer system or device, communicating with one another over a communications medium, thus providing distributed functionality and allowing single or multiple clients to take advantage of the information-gathering capabilities of the server. Any software objects may be distributed across multiple computing devices or objects. Client(s) and server(s) communicate with one another utilizing the functionality provided by protocol layer(s). For example, HyperText Transfer Protocol (HTTP) is a common protocol that is used in conjunction with the World Wide Web (WWW), or “the Web.”Typically, a computer network address such as an Internet Protocol (IP) which may be a component of a Universal Resource Locator (URL) can be used to identify the server or client computers to each other. Communication can be provided over a communications medium, e.g., client(s) and server(s) may be coupled to one another via transmission control protocol/internet protocol (TCP/IP) connection(s) for high-capacity communication. For example, the cellular tower andstation106 andcomputer network108 may be communicatively linked by one or more communications networks or communication mediums (e.g., using a cellular or other wired or wireless signal116) in order to send and receive information to and from thecomputer network108 and receive and provide such information from and to thehandheld communications device104 over a wireless signal on the cellular network using applicable combinations and layers of telecommunications and networking protocols and standards such as 3G, HTTP and TCP/IP, etc.
• FIG. 2 shows an exemplaryhandheld communications device104 shown in more detail according to one illustrated embodiment. Thehandheld communications device104 may have ahousing202, adisplay204, agraphics engine206, a central processing unit (CPU)208, one or moreuser input devices210, one ormore storage mediums212 having various software modules stored thereon comprising instructions that are executable by theCPU208, input/output (I/O) port(s)216, a Wi-Fi receiver/transmitter andnetwork interface218a, a short range wireless receiver/transmitter andnetwork interface218b, a cellular receiver/transmitter andnetwork interface218c, and apower source222.
• As previously noted, thehandheld communications device104 may be any of a large variety of communications devices such as a cellular telephone, a portable media player (PMP), a personal digital assistant (PDA), a mobile communications device, portable computer with built-in or add-on cellular communications, a portable game console, a global positioning system (GPS), a handheld industrial electronic device, or the like, or any combination thereof. Thehandheld communications device104 has at least one central processing unit (CPU)206 which may be a scalar processor, a digital signal processor (DSP), a reduced instruction set (RISC) processor, or any other suitable processor. The central processing unit (CPU)208,display204,graphics engine206, one or moreuser input devices210, one ormore storage mediums212, input/output (I/O) port(s)216, Wi-Fi receiver/transmitter andnetwork interface218a, short range wireless receiver/transmitter andnetwork interface218b, and cellular receiver/transmitter andnetwork interface218cmay all be communicatively connected to each other via asystem bus224. Thesystem bus224 can employ any suitable bus structures or architectures, including a memory bus with memory controller, a peripheral bus, and/or a local bus.
• Thehandheld communications device104 also includes one or more volatile and/or non-volatile storage medium(s)212. Thestorage mediums212 may be comprised of any single or suitable combination of various types of processor-readable storage media and may store instructions and data acted on byCPU208. For example, a particular collection of softwareinstructions comprising software214 and/or firmware instructions comprising firmware are executed byCPU208. The software or firmware instructions generally control many of the operations of thehandheld communications device104 and a subset of the software and/or firmware instructions may perform functions to operatively configure hardware and other software in thehandheld communications device104 to provide the initiation, control and maintenance of applicable computer network and telecommunication links from thehandheld communications device104 to the externalautomobile head unit102, cellular tower andstation106 andexternal computer network108 as shown inFIG. 1 via the Wi-Fi receiver/transmitter andnetwork interface218a, short range wireless receiver/transmitter andnetwork interface218b, cellular receiver/transmitter andnetwork interface218c, and/or I/O ports shown inFIG. 2.
• By way of example, and not limitation, the storage medium(s)212 may be processor-readable storage media which may comprise any combination of computer storage media including volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Processor-readable storage media includes, but is not limited to, random access memory (RAM), read only memory (ROM), electrically erasable programmable read only memory (EEPROM), flash memory, compact disc ROM (CD-ROM), digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, solid state memory or any other medium which can be used to store the desired information and which may accessed byCPU208. Combinations of any of the above should also be included within the scope of processor-readable storage media.
• The storage medium(s)212 may include system memory which includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) and random access memory (RAM). A basic input/output system (BIOS), containing the basic routines that help to transfer information between elements withinhandheld communications device104, such as during start-up or power-on, is typically stored in ROM. RAM typically contains data and/or program modules that are immediately accessible to and/or presently being operated on byCPU208. By way of example, and not limitation,FIG. 2 illustratessoftware modules214 including an operating system, application programs and other program modules that implement the processes and methods described herein.
• Thehandheld communications device104 may also include other removable/non-removable, volatile/nonvolatile computer storage media drives. By way of example only, the storage medium(s)212 may include a hard disk drive or solid state storage drive that reads from or writes to non-removable, nonvolatile media, a magnetic disk drive that reads from or writes to a removable, nonvolatile magnetic disk, and an optical disk drive that reads from or writes to a removable, nonvolatile optical disk such as a CD ROM or other optical media. Other removable/non-removable, volatile/nonvolatile computer storage media that can be used in an operating environment of thehandheld communications device104 include, but are not limited to, flash memory cards, digital versatile disks, micro-discs, digital video tape, solid state RAM, solid state ROM, and the like. The storage medium(s) are typically connected to thesystem bus224 through a non-removable memory interface. The storage medium(s)212 discussed above and illustrated inFIG. 2, provide storage of computer readable instructions, data structures, program modules and other data for thehandheld communications device104. InFIG. 2, for example, a storage medium may storesoftware214 including an operating system, application programs, other program modules, and program data. The storage medium(s)212 may implement a file system, a flat memory architecture, a database, or any other method or combination capable for storing such information.
• A user may enter commands and information into thehandheld communications device104 throughtouch screen display204 or the one or more input device(s)210 such as a keypad, keyboard, camera, motion sensor, position sensor, light sensor, biometric data sensor, accelerometer, or a pointing device, commonly referred to as a mouse, trackball or touch pad. Other input devices of thehandheld communications device104 may include a microphone, joystick, game pad, optical scanner, other sensors, or the like. Example use of the input devices, in particular the microphone, is described in greater detail below in conjunction with communications to external servers. These and other input devices are often connected to theCPU208 through a user input interface that is coupled to thesystem bus224, but may be connected by other interface and bus structures, such as a parallel port, serial port, wireless port, game port or a universal serial bus (USB). Generally, a unique software driver stored insoftware214 configures each input mechanism to sense user input, and then the software driver provides data points that are acted on byCPU208 under the direction ofother software214. The display is also connected to thesystem bus224 via an interface, such as thegraphics engine206. In addition to thedisplay204, thehandheld communications device104 may also include other peripheral output devices such as speakers, a printer, a projector, an external monitor, etc., which may be connected through one or more analog or digital I/O ports216 or network interfaces of the Wi-Fi receiver/transmitter andnetwork interface218a, short range wireless receiver/transmitter andnetwork interface218bor cellular receiver/transmitter andnetwork interface218c.
• Thehandheld communications device104 may operate in a networked environment using connections to one or more remote computers or devices, such as a remote computer or device within thecomputer network108, the cellular tower andstation106, and theautomobile head unit102 shown inFIG. 1 and described above. The remote computer withincomputer network108 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to thehandheld communications device104. Such connections to thecomputer network108 may include local area network (LAN) connections as described above or wide area network (WAN) connections, and/or other networks.
• When used in a LAN or WAN networking environment, thehandheld communications device104 may be connected via the Wi-Fi receiver/transmitter andnetwork interface218aand/or the cellular receiver/transmitter and network interface. When used in a WAN networking environment, thehandheld communications device104 may include a modem or other means as part of the network interface(s) for establishing communications over the WAN, such as the Internet. The Wi-Fi receiver/transmitter andnetwork interface218aand/or the cellular receiver/transmitter and network interface may be communicatively connected to thesystem bus224. In a networked environment, program modules depicted relative to thehandheld communications device104, or portions thereof, may be stored in a remote memory storage device of a remote system.
• Thehandheld communications device104 has a collection of I/O ports216 and/or short Range wireless receiver/transmitter andnetwork interfaces218afor passing data over short distances to and from thehandheld communications device104 or for coupling additional storage to thehandheld communications device104. For example, serial ports, USB ports, Wi-Fi ports, Bluetooth® ports, IEEE 1394 (i.e., FireWire), and the like can communicatively couple thehandheld communications device104 to other computing apparatuses. Compact Flash (CF) ports, Secure Digital (SD) ports, and the like can couple a memory device to thehandheld communications device104 for reading and writing by theCPU208 or couple thehandheld communications device104 to other communications interfaces such as Wi-Fi or Bluetooth transmitters/receivers and/or network interfaces.
• Handheld communications device104 also has a power source222 (e.g., a battery). Thepower source222 may supply energy for all the components of thehandheld communications device104 that require power when a traditional, wired power source is unavailable or otherwise not connected. Other various suitable system architectures and designs of thehandheld communications device104 are contemplated and may be utilized which provide the same, similar or equivalent functionality as those described herein.
• It should be understood that the various techniques described herein may be implemented in connection with hardware, software and/or firmware or, where appropriate, with a combination of such. Thus, the methods and apparatus of the disclosure, or certain aspects or portions thereof, may take the form of program code (i.e., instructions) embodied in tangible media, such as floppy diskettes, CD-ROMs, hard drives, or any other machine-readable or processor-readable storage medium wherein, when the program code is loaded into and executed by a machine, such as a processor of a computer or handheld communications device, the machine becomes an apparatus for practicing various embodiments. In the case of program code execution on programmable computers or handheld communications devices, such generally includes a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device. One or more programs may implement or utilize the processes described in connection with the disclosure, e.g., through the use of an API, reusable controls, or the like. Such programs are preferably implemented in a high level procedural or object oriented programming language to communicate with a computer system including the computer system depicted inFIG. 2 ofhandheld communications device104. However, the program(s) can be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language, and combined with hardware implementations.
• FIG. 3 shows software modules of thehandheld communications device104 in more detail according to one illustrated embodiment. The software modules include anapplication302, a peercommunications framework component304, a network stack of thehandheld communications device104 such as a peer-to-peer (i.e., peer)network stack306 preferably wirelessly interconnected with anetwork stack308 of theautomobile head unit102 via anetwork interface310 of theautomobile head unit102, and another network stack such as a devicegeneral network stack312 of thehandheld communications device104 interconnected to thecomputer network108.
• A network stack (i.e., a protocol stack or communications stack) is a particular software implementation of a group of layered computer networking protocols. Example descriptions of layered communications and computer network protocol design and particular TCP/IP network protocols provided herein are available in the Wikipedia.com articles “OSI Model” found at http://en.wikipedia.org/wiki/OSI_Reference_Model and “TCP/IP Model” found at http://en.wikipedia.org/wiki/TCP/IP_model, which are both hereby incorporated by reference in their entirety and Request for Comments (RFC) 1122 and RFC 1123 available at http://tools.ietf.org/html/rfc1122 and http://tools.ietf.org/html/rfc1123, respectively, published by the Internet Engineering Task Force (IETF) and both also hereby incorporated by reference in their entirety. The network stack is the software implementation of a group of layered protocols. Because each protocol module usually communicates with two others, they are often referred to as layers in a stack of protocols. The lowest protocol deals with “low-level”, physical interaction of the hardware. Every higher layer adds more features. User and other specific applications usually communicate with the topmost layers. Network stacks are often divided into three major sections: media, transport, and applications. A particular operating system or platform will often have two well-defined software interfaces: one between the media and transport layers, and one between the transport layers and applications. The media-to-transport interface defines how transport protocol software makes use of particular media and hardware types. For example, the media-to-transport interface level would define how TCP/IP transport software would communicate with Ethernet hardware. The application-to-transport interface defines how application programs make use of the transport layers. For example, the application-to-transport interface level would define how a Web browser program would communicate with TCP/IP transport software. In the present example, the peercommunications framework component304 may have one or more sub-modules or routines operating at or communicating with various layers of thepeer network stack306 andgeneral network stack312. The structure of the example peer-to-peer network stack is shown in further detail inFIG. 3.
• Theapplication302 may interface with the peercommunications framework component304 through an application programming interface (API) and may work as middleware, with a separate connection to both the computer network108 (e.g., the Internet) and to an external device, such as theautomobile head unit102. Thepeer network stack306 and thegeneral stack312 may be communicatively connected to theautomobile head unit102 and thecomputer network108, respectively, via a separate physical or logical short range wireless network Interface314 (e.g., a Bluetooth® interface) and a Wi-Fi orcellular network interface316 in communication with one or more lower layers of thepeer network stack306 andgeneral network stack312. Thepeer network stack306 andautomobile head unit102 network stack provide a peer-to-peer network connection between theautomobile head unit102 andhandheld communications device104. A peer-to-peer (P2P) connection is a connection between two devices to share resources without going through a separate server computer between them. In particular, the peer-to-peer connection ofFIG. 3 consists of a connection between two devices consisting of thehandheld communications device104 and theautomobile head unit102. There are no other intervening devices or nodes on the peer-to-peer network between thehandheld communications device104 and theautomobile head unit102.
• Although thehandheld communications device104 may have a separate connection out to the Internet via thegeneral network312 stack co-existing on the samehandheld communications device104, thepeer network stack306 and thegeneral stack312 are not directly connected. For example, an HTTP request from the external device (e.g., the automobile head unit102) to thehandheld communications device104 is not merely forwarded out to the Internet, but rather is handled by the peercommunications framework component304 and by theapplication302 using it. The peercommunications framework component304 may service the request in many different ways including, but not limited to returning a file cached on thehandheld communications device104, returning data generated at runtime based on the request, proxying out to the Internet via thegeneral network stack312 and forwarding/caching the results as needed to theautomobile head unit102. These operations are enabled by the peercommunications framework component304 and its associatedapplication302 being connected to both thepeer network stack306 and thegeneral stack312. Thus, the system of thehandheld communications device104 does not merely act as a general proxy, but rather as a service provider with multiple functions.
• Thepeer network stack306 andautomobile head unit102 network stack may provide a peer-to-peer network connection on a serial data transport link between theautomobile head unit102 andhandheld communications device104. As shown inFIG. 1, theautomobile head unit102 andhandheld communications device104 may be communicatively linked by a shortrange wireless signal100. For example, this short range wireless signal may be that of a wireless Bluetooth® or a wired Universal Serial Bus (USB) link. However, other wireless or wired connections that support serial or parallel data transport may also be used. The link between theautomobile head unit102 andhandheld communications device104 may be automatically established when thehandheld communications device104 comes into the vicinity of theautomobile head unit102 according to various protocols and/or standards of the applicable type of short range wireless link.
• The peer-to-peer network connection is relatively secure. It may be specified to be a connection between only two devices using a secure data transport link at the physical layer of thepeer network stack306. Bluetooth® supports automatically and transparently encrypting the data flows and this functionality may be relied upon in particular embodiments using Bluetooth® Serial Port Profile (SPP) as the transport mechanism at the physical layer of thepeer network stack306. In particular embodiments using a wired USB link in the transport mechanism, the connection would be difficult to tap without physically altering the hardware. To add to this security, certain services may require HTTP digest authentication.
• Thehandheld communications device104 may have particular network services available natively at thehandheld communications device104 and others that are not available natively at thehandheld communications device104. The peercommunications framework component304 may handle the communications from theautomobile head unit102 such that the handling the communications received from theautomobile head unit102 via the peer-to-peer connection enables theautomobile head unit102 to handle network communications in a same manner irrespective of whether the one or more particular network services are available at all to theautomobile head unit102 via thehandheld communications device104. For example, both thepeer network stack306 and theautomobile head unit102network stack308 may provide a minimal HTTP or HTTPS server and both may be able to make HTTP or HTTPS requests to the other device. Thepeer network stack306 in conjunction with the peercommunications framework component304 may provide a superset of that minimal support, including, but not limited to: an HTTP or HTTPS server that provides various services available over the peer-to-peer network between theautomobile head unit102 andhandheld communications device104 natively at thehandheld communications device104, the ability to pass other service requests to theapplication302 for processing, and the ability to make HTTP requests to theautomobile head unit102. However, theautomobile head unit102 need not communicate differently with thehandheld communications device104 if particular network services are not available at or via thehandheld communications device104 over the peer-to-peer connection as the corresponding response from thehandheld communications device104 will handle such requests in an appropriate manner according to the particular network protocol (e.g., TCP/IP) to enable further communications between theautomobile head unit102 and thehandheld communications device104 without interrupting the connection. For example, if thehandheld communications device104 does not provide services such as Dynamic Host Configuration Protocol (DHCP) or Address Resolution Protocol (ARP), requests for such services will be ignored or otherwise responded to in a manner enabling the requester to continue communications in a normal manner without interrupting the current network connection or session. Thus, theautomobile head unit102 requires no “knowledge” of whether particular network services are supported or provided by thehandheld communications device104 beyond a minimal set of network services.
• In one example embodiment, each device (e.g., theautomobile head unit102 and handheld communications device104) in the peer-to-peer connection has a specific role. In the present example, thehandheld communications device104 acts as a Bluetooth® server and as the “anchor” of the connection. It uses a specified IP address, for example, “168.100.10.1”. The external device (e.g., the automobile head unit102) acts as an external device without a connection to the server-based computer network108 (in this case, the Internet). It uses a different specified IP address, for example, “168.100.10.2”. However, in a scenario where there exists only two peers on the peer-to-peer connection (e.g., theautomobile head unit102 and handheld communications device104), the destination network address of communications between the two peers may be ignored as it may be assumed that the intended destination is the network peer other than the one which sent the communication. Thehandheld communications device104 or “anchor” device has a connection out to the server-based system computer network108 (e.g., the general Internet), which it uses to retrieve files for caching and for other purposes appropriate to theapplication302. It also controls the peer connection process with the external device (e.g., the automobile head unit102). The external device does not require an Internet connection and will use its “anchor” peer (e.g., the handheld communications device104) to get files and perform services. It may expect to act as the client in the peer connection process.
• Services are provided between thehandheld communications device104 and theautomobile head unit102 via thepeer network stack306 and theautomobile head unit102network stack308 by HTTP GET and POST requests where the service name is the file/path name portion of the URL. These services may use normal HTTP semantics and headers and provide the data using standard Multipurpose Internet Mail Extensions (MIME) types. Thehandheld communications device104 may provide the HTTP server on port80. Thus, a request to the handheld communications device handheld communications devicehandheld communications device104 may look like “http://168.100.10.1:80/servicename?foo=bar”. The external device (e.g., the automobile head unit102) provides the HTTP server on port8080. Thus, a request to the external device may look like “http://168.100.10.1:8080/servicename?foo=bar”. Depending on the service requested, the data returned may be retrieved from a locally cached file, generated at runtime, or requested on a separate network connection and forwarded to the peer or cached locally for the next request. For example, voice can be processed locally on thehandheld communications device104 or sent to a server for processing. If sent to a server, the results of voice processing can be returnedhandheld communications device104 as a parse tree, a list of 1 to N possible matches, an error, or even set to yet another server for processing into code telling thehandheld communications device104 what to do next. For example the server could form a query to another second server that appears to the second server like the results of haptic (touch/keyboard) input and the second server could respond in exactly the same way as if the original input had been haptic on thehandheld communications device104. The voice processing server could then forward those results back to thehandheld communications device104.
• Services may be provided by the associatedapplication302, using API calls to the peercommunications framework component304. Certain services are native to the peer communications framework component and can operate without application intervention. Such services include (but are not limited to) service discovery (which lists available services), file retrieval (which provides files from the cache, with aliasing, and supports cache modification), and controlled Internet proxy (which forwards requests to pre-selected Internet servers, with aliasing).
• Discoverability of available services is provided by a specific service that is provided by at least one peer (e.g., thehandheld communications device104 or the automobile head unit102). In the present example, this would be the handheld communications device104 (the “anchor” device) and the discoverability service is available natively at the peercommunications framework component304. In one embodiment, this service may return a specified Extensible Markup Language (XML) file describing the available services. For example, the URL of the file may be “http://168.100.10.1:80/servicelist”. The service list contains enough information for the external device (e.g., the automobile head unit102) to create menus of available services and to access the available services to obtain more information as needed. In most cases each peer (e.g., theautomobile head unit102 and the handheld communications device104) will request the service list from the other. The details of the service list may be specified with configuration data supplied to the peercommunications framework component304 on initialization. This configuration may be provided by theapplication302 or maintained on the computer network108 (e.g., the Internet). In the latter case, the configuration will be downloaded by theapplication302 on startup of thehandheld communications device104, allowing the available services of thehandheld communications device104 to change over time without refreshing theapplication302. Thehandheld communications device104 may determine whether a request from theautomobile head unit102 corresponds to a service in a file describing the available services. Thehandheld communications device104 may then forward the request to the server-basedcomputer network108 if it was determined that the request corresponds to a service in the file describing the available services.
• Also, information may be communicated from the handheld communications device104 (the “anchor” device) to configure a user interface of the external device (e.g., the automobile head unit102) to visually match a corresponding user interface of thehandheld communications device104 by communicating information over the serial data transport link from thehandheld communications device104 to theautomobile head unit102. Also, information may be communicated from the handheld communications device104 (the “anchor” device) to configure or provide other information to the external device. The information may contain data adapted for use by theautomobile head unit102 to configure the user interface of theautomobile head unit102 to visually match the corresponding user interface of thehandheld communications device104. The information may contain data adapted for use by theautomobile head unit102 to configure other components or applications of theautomobile head unit102. In one example, the information included in the data returned to theautomobile head unit102 may be for display on the user interface of theautomobile head unit102 that is configured to visually match the corresponding user interface of the handheld communications device handheld communications devicehandheld communications device104. The information may also be obtained from and configured on a remote server on the server-basedcomputer network108 and be configured such that a user interface of thehandheld communications device104,automobile head unit102 and one or more remote devices on the server-basedcomputer network108 substantially match each other.
• As thehandheld communications device104 may in some instances not always be connected to thecomputer network108, but preferably still be capable of providing services to the external device (e.g., the automobile head unit102), the peercommunications framework component304 may provide intelligent file caching and pre-loading to increase the chances that data will be available when requested. The peercommunications framework component304 may monitor types of and patterns of requests received from theautomobile head unit102 and cache on one or memories of thehandheld communications device104 at least a portion of a response received from the server-basedcomputer network108 based upon the types of and patterns of the requests received. Particular parts of the file caching service such as the monitoring of types of and patterns of requests received may be implemented on an Internet server, making the intelligence of the system more powerful and easy to extend. The actual management of the cache may occur on the client (e.g., the handheld communications device104), where the capacity and capabilities of that device are known. For example, the peercommunications framework component304 may include a client that requests cache control data from a server on the server-basedcomputer network108, which specifies what files are to be cached along with metadata the client uses to control how the cache is managed. The client then attempts to load those files from thenetwork108 and store them locally on thehandheld communications device104, making them available for the peer communication control component and thelocal application302. If a file is requested from the cache that has not yet been loaded on thehandheld communications device104 or that is not in the cache control data, that file may be immediately requested from thenetwork108 and cached before it is provided to the requester (e.g., the automobile head unit102).
• Either peer (e.g., thehandheld communications device104 or the automobile head unit102), or both peers, in the peer-to-peer connection between the peers may run an application that uses an identical or similar peer communications framework component to communicate with the other peer. This application will control the connection process on the “anchor” peer. The “external” peer can also run an identical or similar peercommunications framework component304 or may act as a “non-anchor” peer. However, the peercommunications framework component304 may be designed to link to oneapplication302 on a device at a time or several applications. If there is a need for several co-operating applications on thehandheld communications device104 to use the peercommunications framework component304 at the same time, a “wrapper” application may be used which provides cross-task communications appropriate for the device.
• On a device (like a head unit102) which is connected to the peercommunications framework component304 but believes it is connected to a general framework, the network stack on thehead unit102 may be used by several applications at the same time without requiring any “wrapper”.
• The peercommunications framework component304 may be implemented and provided as a code library, in both C/C++ and Java™ versions, for multiple platforms. Depending on the platform the peercommunications framework component304 and associated modules and routines may be provided as source code and/or as a pre-compiled binary file that can be linked into the code of theparticular application302. In some embodiments, the binary file may be runtime linkable, allowing several applications to share a single peercommunications framework component304 library on the same device. Examples of versions in which the peercommunications framework component304 may be provided in runtime link form include, but are not limited to, Binary Runtime Environment for Wireless (BREW) as a BREW extension, and Java Mobile Information Device Profile (MIDP) as a Java Archive (JAR) file. Custom versions of the peercommunications framework component304 library can be provided, which may include only some of the peercommunications framework component304 modules. In an embodiment where ahandheld communications device104 can multi-task, the runtime linking described above may be used, and the peercommunications framework component304 may be implemented as a stand-alone application in order to implement this particular embodiment. In an embodiment wherehandheld communications device104 cannot multi-task, the applications on thehandheld communications device104 may co-operate by shutting down and starting a different application when requested by thehead unit102. Such scenarios may involve shutting down and restarting the peercommunications framework component304 when the application changes.
• FIG. 4 is shows the peercommunications framework component304 and the network stacks306312 of thehandheld communications device104 in greater detail according to one illustrated embodiment, including their logical connectivity to each other and afile system402 of thehandheld communications device104. Although the modules ofFIG. 4 are described in the present example as being components of the “anchor” peer (e.g., the handheld communications device104), such modules of the peercommunications framework component304 may also be present in the external device (e.g., the automobile head unit102) such that it may also act as a service provider and requester and provide peercommunications framework component304 functionality.
• The peercommunications framework component304 provides an integrated framework comprising of several components, each with their own APIs that anapplication302 can use to control the peercommunications framework component304 and communicate with a peer device. These components are also leveraged within the peercommunications framework control404 to provide the basic services. The peercommunications framework component304 may have two components including, but not limited to, acontrol routine404 and ahardware abstraction layer406. The peercommunications framework control404 initializes the peercommunications framework control404, supplies global utilities, and provides a way to initiate and terminate peer connections. The peercommunications framework control404 andhardware abstraction layer406 components operate at or communicate with various layers of thepeer network stack306,general network stack312, and theservice requester408 andservice provider410 modules such that they may receive, process and send information in order to request and provide services, and control communications and operations of the device on which the peercommunications framework component304 is running. In particular, thehardware abstraction layer406 isolates the peercommunications framework component304 code from the underlying device (e.g., the handheld communications device104), by providing abstractions of the serial data transports (Bluetooth® SPP, USB, etc.), the devicegeneral network stack312 functionality (cellular, Wi-Fi, etc.), and thedevice file system402. These abstractions are then implemented for each local device, creating a unique port of the peercommunications framework component304 for that device. Alternative embodiments of the peercommunications framework control404 include peer network port objects with TCP and UDP support that theapplication302 can use to implement protocols other than HTTP.
• On application startup theapplication302 may initialize and start the peercommunications framework control404, passing in the location of an appropriate configuration file. The peercommunications framework control404 configuration file may have an XML layout with sections for each of the major functional areas. An example XML layout appears below:

• 	<peer communications framework control 404-config>

  <network-control>

  <data-transport name =″TRANSPORT-NAME″

  role=″anchor|floater″>

  <info name=”infoName”>value</info>

  	<data-transport>
  	<ip-config ipaddr=″IP-ADDRESS″ servicePort=″PORT-

  NUMBER″

  requestPort=″PORT-NUMBER″/>

  	</network-control>
  	<service-control>

  <service name=”serviceName” profile=″profileName″

  type=″app|file=filename|proxy=url|custom″>

  <info name=”infoName”>value</info>

  </service>

  	</service-control>
  	<cache-control>

  <cache-clear>

  <clear-files pattern=″filepattern???.*″/>

  	</cache-clear>
  	<cache-files>

  <file name=″fileName″ profile=″profileName″

  	url=″http://some.domain/file.ext?foo=bar″
  	refreshFlag=″true|false″ priority=″0-N″
  	estimatedSize=″numbytes″ />

  </cache-files>

  	</cache-control>

• In some embodiments, the peercommunications framework control404 does not define the meaning of service names, profile names, or the name/value pairs used to provide information to the containing tags. This is configurable by the particular implementation. For this reason, it may be desirable for network peers to namespace the particular service and info names of the network peer in a manner to avoid name collisions with other implementations and/or establish open naming standards which include detailed specifications for how a service works or a profile is used. Each peer is configured to know how to access the services and profiles it recognizes.
• The network section of the configuration file defines how the network is initialized and the data transport over which the peer connection is made. The data transport configuration specified in the configuration file specifies the data transport to use, the role the device plays in the connection, and includes a set of name/value pairs that have meaning to that data transport. If the named transport is not available, the configuration is aborted and an error is returned to theapplication302. The IP configuration specified in the configuration file specifies the IP address the device will use and what service ports on which it will receive requests and to which it will make requests. The services section of the configuration file provides a list of services a peer can perform and, optionally, lists of arbitrary name/value pairs attached to a service that have meaning in context with the service. For example, the name Services may be associated with a profile. Services have a type, which specifies how the peercommunications framework control404 handles a request to that service. In the present example, the following types are supported: app, file, proxy, and custom. Services may contain a list of name/value pairs associated with that service, the meanings of which are application dependent. For example, these name/value pairs could provide the information required to determine which arguments the service supports. The cache section of the configuration file indicates how to clear the cache on startup and provides a list of files to cache. Cached files may be associated with a profile. The proxy control section of the configuration file supports a set of “allow” and “deny” patterns defining which URLs are valid for remote proxy and file caching requests. For example, a valid URL must match at least one of the “allow” patterns and cannot match any of the “deny” patterns. The profiles section of the configuration file provides application dependent metadata about groups of items (e.g., services and files) which are associated with that profile. Profiles may contain a list of name/value pairs associated with that service, the meanings of which are application dependent. For example, these name/value pairs provide the information required to build a menu of the available services for an example profile named “weatherApp”.
• After the location of an appropriate configuration file is passed, the peercommunications framework control404 will then obtain a fresh copy of the configuration file (e.g., from a server on the Internet or from a local file system). The configuration file may be parsed and the appropriate configuration data is then supplied to the various components. When theapplication302 requests, the peercommunications framework control404 will start looking for another peer using the data transport and device role defined in the configuration. When a connection is made, the peercommunications framework control404 will inform theapplication302. If no connection is made, the peercommunications framework control404 will continue to search for a peer until told to stop. At any time after a connection is made, theapplication302 can request the connection to be terminated. If the connection fails for any reason (e.g., normal termination, timeout, etc.) theapplication302 will be informed.
• The filecache manager component424 handles downloading and caching of files from an external network such as computer network108 (e.g., the Internet) supplying them to theapplication302 and to theservice provider410 on request from a peer device (e.g., the automobile head unit102). For example, the configuration file (e.g., an XML file) managed by the peercommunications framework control404 includes a cache control section that specifies what files to download and cache, along with metadata that determines how each file is handled. Using the applicable cache control XML from the configuration as a guide, the filecache manager component424 then starts cleaning up the local cache and loading new files as a background process for as long as theapplication302 runs. The cache itself may be a standard directory on thedevice file system402 and the files may be saved there in the same format as they were retrieved from thenetwork108. A combination of device specific rules for the total size of the cache, the cleanup section of the cache control, and the individual file cache control metadata will determine what older files are removed from the cache before loading starts or as it progresses. Thecache manager component424 will prevent the total cache size from exceeding a device specific value. The files themselves are retrieved from the network using a URL supplied in the individual file cache control metadata. The filecache manager component424 also provides the ability for theapplication302 and the connected peer (e.g., the automobile head unit102) to add files to the cache list and/or override the cache metadata of a file in the cache control. Once added to the list, a file requested locally is handled using the caching rules described above.
• The filecache manager component424, for example, may provide two methods to retrieve file data: as a binary stream and as a file location in the form of a URL. A particular file may be requested as a binary stream by name from the filecache manager component424 at any time. The request may optionally include cache metadata that overrides the metadata supplied in the cache control. If the requested file name is not in the cache control, it is added to the cache using either the metadata previously passed or default values for optional metadata. When a file is requested, the filecache manager component424 will look first to see if it is currently in the cache. If it is not in the cache, the filecache manager component424 will then request the file using the standard file cache rules, but moving it up in load order to that moment. For files already in the cache, the file is opened and the data is supplied as a binary stream. For files not yet in the cache, the file is retrieved from the network first, written to the file cache, and then opened as previously described.
• The filecache manager component424 may provide a second method of file access that is indirect and bypasses the automatic caching mechanism described above. In such a case, a file's location is requested by name and either the file cache manager returns a local file system URL (for example, “file://some/path/foo.bar”) when the file is already in the cache or the filecache manager component424 returns a network URL (for example “http://some.domain/foo.bar”) when the file is not in the cache. The local system URL format will be device dependent.
• As described above, caching metadata may be optionally provided and the requested file name does not have to already be in the cache control. However, in this case, the requested file is not automatically retrieved and normal cache loading procedures are applied to it. As a result, this method may return a network URL on one request and a file URL on a later request because the file has been loaded into the cache between those requests.
• Cached files may be used by theapplication302 associated with the peercommunications framework control404. The application may request the file data from the filecache manager component424 as a binary stream or request the file location from the filecache manager component424 and open it normally. Cached files are also available to theservice provider component410, which can then provide them to an external device such as anautomobile head unit102. In the present example, the binary stream method is used.
• The cache control data that specifies the files and metadata used to maintain the cache may be generated on a client (e.g., the handheld communications device104) or on a server within the server-basedcomputer network108 at runtime. How this data is generated may be as simple or as complex as needed and can change over time based upon needs of theapplication302 or experience gained from tracking and monitoring types of files and actual use patterns of theapplication302. The rules for caching applied on the server or the device (e.g., the handheld communications device104) can be based on, but are not limited to, one or more of the following: files chosen by the application designers for likelihood of use or because they must be available on the device with a minimum time delay, files selected based on the current user's gestures (usage patterns), files selected based on aggregate user gestures, files selected based on user preferences, files selected based on the user's vehicle, files selected based on the user's current location, files selected based on the user's typical locations throughout the day, files selected based upon a partner or customer's requirements, files selected based on a connected device (e.g., the automobile head unit102), and calling a service requesting the file in the future (e.g., thehandheld communications device104 service may update the server database as needed).
• The initial implementation of the file selection process may be simple, adding complexity later as needs dictate. The handheld communications device client application (e.g., the service requester component408) and the connected device (e.g., the automobile head unit102) may request files from the cache which are not specified in the cache control data and those files will be cached normally after requested.
• Theservice requester component408 andservice provider component410 may each have corresponding client and server modules (e.g.,HTTP client412 andHTTP server414 modules, respectively) to request and/or provide services via thepeer network stack306 or thegeneral network stack312 in order to support such requests and services coming from theapplication302 and managed by the peercommunications framework component304. In one example embodiment, the peernetwork stack component306 implements a minimal TCP/IP stack over appropriate serial data transport functionality. The data transport functionality may vary based upon the device and the peercommunications framework control404 configuration. Thepeer network stack306 may, for example, includeTCP functionality416 at the transport layer,IP functionality418 at the network layer, Serial Line Internet Protocol (SLIP) or Point to Point Protocol (PPP)functionality420 at the data-link layer, and serialdata transport functionality422 such as Bluetooth® SPP or USB at the physical layer. For Bluetooth® SPP, the connection service name will use a specified value, for example “peer communications framework v1.0”. The external device (e.g., the automobile head unit102) may look for this value when enumerating the Bluetooth® profiles on the connecting device (e.g., the handheld communications device104).
• Theservice provider component410 may be a minimal HTTP server with support for GET and POST semantics. Incoming HTTP requests resolve either to files in the file cache or to service requests, which are handled by native services of the peercommunications framework control304 or forwarded to the associatedapplication302 for servicing. Files may be requested using a specialized service native to the peercommunications framework control404 called “file” (e.g., http://168.100.10.1:80/file/filepath/filename.ext). Optional arguments can specify file-caching metadata, including the Internet URL the file is retrieved from. However, this is not an open proxy, as the Internet URL is subject to a match against cache control configuration options. Files may also be requested using an alias defined in the service configuration. In the present example, the file is requested using only the service name (e.g., “http://168.100.10.1:80/filealias”). Services may be requested by service name. (e.g., “http://168.100.10.1:80/servicename?foo=bar”). As the request may be in the form of an HTTP POST, it can include contents of any data type.
• Services native to the peercommunications framework control404 are handled by the peercommunications framework control404 internally, after theapplication302 is notified and given the option to abort the request. Application services are forwarded to theapplication302 along with a “request” object that the application uses to determine the contents of the request and to respond to the request. TheHTTP server414 of theservice provider component410 may provide some services native to theservice provider component410. For example, these may include, but are not limited to, servicelist (which returns a list of available services using the same format as the service list in the configuration, filelist (which returns a list of available files, formatted as a service list), and file (which returns a file from the cache, adding it to the cache first if not already there). Theservice requester component408 allows the application associated with the peercommunications framework control404 to make an HTTP request to the external peer device (e.g., the automobile head unit102) using GET and POST semantics. Services are requested as defined by the external peer device and may be formed as HTTP GET or POST requests. For example, the request may be formed as “http://168.100.10.1:8080/servicename?foo=bar”. To make the request, theapplication302 gets a new request object from the peercommunications framework control404, sets its properties as needed and then calls the “send” method. The request object described above fires an event for success or for failure and the content of the response, if successful, is made available to theapplication302 in the form of a binary stream.
• Particular modules described above and other optional modules of the peercommunications framework component304 may or may not be present in other embodiments. However, excluding particular modules results in the device from which they are excluded not being able to act as an “anchor” device in the sense of being able to provide particular services to an external device that expects the full functionality of the peercommunications framework component304. For example, in the case of an external device (e.g., the automobile head unit102) which has no connection to the Internet and therefore no need to cache and serve files, one can easily eliminate the filecache manager module424 and the service provider component410 (unless the particular external device needs to provide services other than cached files from the Internet).
• Of the two peers participating in a connection between the “anchor” and external device as described above, only one need implement functionality of the peercommunications framework component304. The other peer may connect using any standards-compliant network stack with an appropriate data transport. For example, theautomobile head unit102 with ageneral network stack308 and support for SLIP over Bluetooth® SPP (the external device) can connect to thehandheld communications device104 running the peer communications framework component304 (the “anchor”). Each peer (e.g., thehandheld communications device104 and the automobile head unit102) provides an appropriate data transport and a network stack capable of communicating via the appropriate network addresses, along with the protocol support required to make and handle service requests. Peers are provided this functionality by a peercommunications framework component304 library. Peers that do not have a peercommunications framework component304 implement this functionality separately. For example, this particular functionality may include data transport functionality (Bluetooth® SPP/SLIP or others), TCP/IP functionality, HTTP client functionality (to request services from the “anchor” peer), and other optional protocols. For example, peers that do not have a peer communications framework component (e.g., the automobile head unit102) may optionally provide an HTTP server to act as a service provider to the “anchor” peer (e.g., the handheld communications device104).
• When two peers connect, one or more peers may receive information indicating that they are participating in a peer-to-peer network wherein one peer has a peercommunications framework component304 so they can configure themselves appropriately. The “anchor” peer is the peer that has the peercommunications framework component304 and will already be configured appropriately. However, the external peer may support other kinds of connections over the same physical serial transport and may learn what kind of connection has been initiated by the external peer looking for the value of the connection service name as described above.
• FIG. 5 is a flow diagram showing amethod500 of providing communications between an automobile head unit of an automobile, a communications device, and a server-based computer network via which Internet access is provided, according to one illustrated embodiment.
• The method starts at502, in which a request may be received over a serial data transport link from theautomobile head unit102 via a peer-to-peer network stack. At503 it may be determined whether the request is to be handled by a service via an external server-based network. For example, some services are available native to (i.e., locally on) the handheld communications device and others may be available via a server-based network external to the handheld communications device. An example of such a service that may be available locally on the handheld communications device may be one that changes the station on an Internet radio application. However, this determination of whether the request is to be handled by a service via an external server-based network would not be needed if all services were available natively on the handheld communications device or if no services were available natively on the handheld communications device and embodiments including such various processes and systems excluding such a decision are contemplated. If it is determined that the request is to be handled by a service via an external server-based network, then at504 the request is forwarded to a server-based computer network via the general network stack of the device. At506, the response is received from the server-based computer network via the general network stack and at508 the response is sent to the automobile head unit over the serial data transport link. In one embodiment, the serial data transport link between the head unit and the communications device is either a Bluetooth® Serial Port Profile (SPP) type serial data transport link or Universal Serial Bus (USB) type serial data transport link.
• If it is determined at503 that the request is not to be handled by a service via an external server-based network, then at510 the service is performed locally according to the request. For example, the service may be performed locally on the handheld communications device. At508, the response resulting from the performance of the service is then sent to the automobile head unit over the serial data transport link. For example, in the case of the service being one that changes the station on an Internet radio application, the radio Internet station would be changed using a service locally on the handheld communications device without forwarding the request to an external network.
• FIG. 6 is a flow diagram showing a method of providing communications between an automobile head unit, a communications device and a server-based computer network, including filtering service requests, according to one illustrated embodiment.
• The method starts at602, in which a request is received over serial data transport link from an automobile head unit via a peer-to-peer network stack. At604 it may be determined whether the request corresponds to a service on a specified list of services. For example, the specified list of services may be a list of services available via a peer other than the automobile head unit (e.g., a handheld communications device). If it is determined that the request does not correspond to a service on the specified list of services, the method may then return an error code612 (e.g., return an HTTP error code to a client requesting the service). At606, if it had been determined that the request corresponds to a service on the specified list of services, then at605 it may be determined whether the request is to be handled by a service via an external server-based network. For example, some services are available native to (i.e., locally on) the handheld communications device and others may be available via a server-based network external to the handheld communications device. An example of such a service that may be available locally on the handheld communications device may be one that changes the station on an Internet radio application. However, this determination of whether the request is to be handled by a service via an external server-based network would not be needed if all services were available natively on the handheld communications device or if no services were available natively on the handheld communications device and embodiments including such various processes and systems excluding such a decision are contemplated. If it is determined that the request is to be handled by a service via an external server-based network, then at606 the request may be forwarded to a server-based computer network via a general network stack. For example, the general network stack resides on the same device (e.g., the communications device) on which the peer-to-peer network stack resides. At608 a response is received from the server-based computer network via the general network stack. At610, the response may then be sent to the automobile head unit over the serial data transport link.
• If it is determined at604 that the request is not to be handled by a service via an external server-based network, then at614 the service is performed locally according to the request. For example, the service may be performed locally on the handheld communications device. At614, the response resulting from the performance of the service is then sent to the automobile head unit over the serial data transport link. For example, in the case of the service being one that changes the station on an Internet radio application, the radio Internet station would be changed using a service locally on the handheld communications device without forwarding the request to an external network.
• FIG. 7 is a flow diagram showing a method of providing communications between an automobile head unit, a communications device and a server-based computer network, including intelligent caching, according to one illustrated embodiment.
• The method starts at702, in which a request is received over a serial data transport link from the automobile head unit via a peer-to-peer network stack. For example the request may be received at the communications device on the peer network having a peer-to-peer connection with the automobile head unit. At704, the request is forwarded to a server-based computer network via a general network stack. For example, the general network stack resides on the same device (e.g., the communications device) on which the peer-to-peer network stack resides. At706, types and patterns of requests received are monitored. For example, this monitoring is performed on one or more servers on the server-based computer network but, optionally, may also or instead be performed locally on the communications device. At708, a response is received from the server-based computer network via the general network stack. At710 the response (or at least a portion of the response) may be cached based upon the monitoring types and patterns of the received requests. For example, the response may be received and at least a portion of the response cached on the communications device according to various caching data received from the server-based computer network indicating what files or responses to cache on the communications device. The method may then repeat714 starting at702 as more requests are received.
• FIG. 8 is a flow diagram showing amethod800 for communicating in a communication network environment between a first and a second network peer over a direct serial data transport link including responding by the first network peer to a service request included in one or more of the communications, according to one illustrated embodiment.
• The method starts at802, in which communications are received over a direct serial data transport link on a network in which only two network addresses are used at a given time. There may be an established data transport connection between the first network peer and the second network peer over the direct serial data transport link and the first network peer may have a separate connection over a separate network interface to a network external to the link. At804, a payload is extracted from a communication received irrespective of the communication packet's destination network address. For example, the destination network address may be ignored or otherwise not used. Also, the established data transport connection between the first network peer and the second network peer on the direct serial data transport link may be one in which resolution of network addresses of the first network peer and the second network peer to hardware addresses of the first network peer and the second network peer is not necessary for the responding by the first network peer to the service request. At806 a service request included in the communication is responded to by providing data that was originally obtained via the separate connection to a network external to the direct serial data transport link. For example, the network external to the direct serial data transport link may be the Internet. The method may then repeat808 starting at802 as more communications are received.
• FIG. 9 is a flow diagram showing amethod900 for communicating in a communication network environment between a first and a second network peer over a direct serial data transport including handling the communications received which have requests for particular network services, according to one illustrated embodiment.
• The method starts at902, in which a communication is received over a direct serial data transport link by a first network peer from second network peer. At904, the communication received is then handled such that the second network peer is not required to know that it is on a peer-to-peer network as opposed to a more general network in order. The second network peer is enabled to handle network communications in a same manner as if the first network peer did provide particular general network services, even if the first network peer does not provide the requested network service. A corresponding response from the first network peer will handle a service request in the communication in an appropriate manner according to the particular network protocol (e.g., TCP/IP) to enable further communications between the first and second network peer without interrupting the connection. For example, if the first network peer does not provide services such as Dynamic Host Configuration Protocol (DHCP) or Address Resolution Protocol (ARP), requests for such services will be ignored or otherwise responded to in a manner enabling the requester to continue communications in a normal manner without interrupting the current network connection or session. The method may then repeat906 starting at902 as more communications are received.
• The above description of illustrated embodiments, including what is described in the Abstract, is not intended to be exhaustive or to limit the embodiments to the precise forms disclosed. Although specific embodiments of and examples are described herein for illustrative purposes, various equivalent modifications can be made without departing from the spirit and scope of the disclosure, as will be recognized by those skilled in the relevant art. The teachings provided herein of the various embodiments can be applied to other devices, not necessarily the exemplaryautomobile head unit102 andhandheld communications device104 generally described above.
• For instance, the foregoing detailed description has set forth various embodiments of the devices and/or processes via the use of block diagrams, schematics, and examples. Insofar as such block diagrams, schematics, and examples contain one or more functions and/or operations, it will be understood by those skilled in the art that each function and/or operation within such block diagrams, flowcharts, or examples can be implemented, individually and/or collectively, by a wide range of hardware, software, firmware, or virtually any combination thereof. Those skilled in the art will recognize that the embodiments disclosed herein, in whole or in part, can be equivalently implemented in standard integrated circuits, as one or more computer programs executed by one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs executed by on one or more controllers (e.g., microcontrollers) as one or more programs executed by one or more processors (e.g., microprocessors), as firmware, or as virtually any combination thereof, and that designing the circuitry and/or writing the code for the software and or firmware would be well within the skill of one of ordinary skill in the art in light of the teachings of this disclosure.
• When logic is implemented as software or firmware and stored in memory, logic or information can be stored on any computer-readable medium (i.e., processor-readable storage medium) for use by or in connection with any processor-related system or method. In the context of this disclosure, a memory is a computer-readable medium that is an electronic, magnetic, optical, or other physical device or means that contains or stores a computer and/or processor program. Logic and/or the information can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions associated with logic and/or information.
• In the context of this specification, a “computer-readable medium” or “processor-readable storage medium” can be any physical element that can store the program associated with logic and/or information for use by or in connection with the instruction execution system, apparatus, and/or device. The computer-readable medium can be, for example, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus or device. More specific examples (a non-exhaustive list) of the computer readable medium would include the following: a portable computer diskette (magnetic, compact flash card, secure digital, or the like), a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM, EEPROM, or Flash memory), a portable compact disc read-only memory (CDROM), digital tape.
• The various embodiments described above can be combined to provide further embodiments. To the extent that they are not inconsistent with the specific teachings and definitions herein, all of the U.S. patents, U.S. patent application publications, U.S. patent applications, foreign patents, foreign patent applications and non-patent publications referred to in this specification and/or listed in the Application Data Sheet are incorporated herein by reference, in their entirety. Aspects of the embodiments can be modified, if necessary, to employ systems, circuits and concepts of the various patents, applications and publications to provide yet further embodiments.
• These and other changes can be made to the embodiments in light of the above-detailed description. In general, in the following claims, the terms used should not be construed to limit the claims to the specific embodiments disclosed in the specification and the claims, but should be construed to include all possible embodiments along with the full scope of equivalents to which such claims are entitled. Accordingly, the claims are not limited by the disclosure.

Claims (37)

1. A method of providing services to a user via a head unit of an automobile and a communications device having a handheld form factor, the method comprising:

establishing a peer-to-peer connection between the communications device and the head unit over a wireless data transport link;

receiving information via the peer-to-peer network stack by the communications device or by the head unit over the wireless data transport link between the head unit and the communications device; and

in response to the received information, the head unit performing a service at the head unit based on the received information.

2. The method ofclaim 1 wherein the performing the service comprises:

forwarding a request originating from the communications device or from the head unit to a server-based network via the wireless data transport link between the head unit and the communications device;

the head unit or the communications device receiving a response from the server-based network; and

the head unit that received the response or the communications device that received the response automatically forwarding over the wireless data transport link, at least a portion of the response to the head unit from which the request originated or to the communications device from which the request originated.

3. A method of providing communications between a head unit of an automobile and a communications device having a handheld form factor, the method comprising:

receiving, by the communications device, information regarding a user of the communications device;

facilitating, by the communications device, establishment of a peer-to-peer connection between the communications device and the head unit over a wireless data transport link between the head unit and the communications device; and

causing, by the communications device, the head unit to provide a service to the user at the head unit based on the information regarding the user by communicating the received information regarding the user to the head unit via the peer-to-peer connection over the wireless data transport link between the head unit and the communications device.

4. The method ofclaim 3 wherein the information regarding the user includes information received by the communications device regarding typical locations of the user of the communications device.

5. The method ofclaim 3 wherein the information regarding the user includes information received by the communications device regarding a current location of the user of the communications device.

6. The method ofclaim 3 wherein the information regarding the user includes information received by the communications device regarding user preferences of the user of the communications device.

7. The method ofclaim 6 further comprising:

the communications device repeating the receiving, the facilitating and the causing for other head units of other automobiles to cause the other head units to provide the service to the user at the other head units based on the user preferences of the user of the communications device.

8. A method of providing communications between a head unit of an automobile, a communications device having a handheld form factor, and a server-based network through which Internet access is provided, the method comprising:

receiving one or more requests via a peer-to-peer network stack by the communications device from the head unit over a serial data transport link between the head unit and the communications device; and

performing a service specified in the one or more requests in response to the one or more requests, the service comprising:

forwarding a request to the server-based network from the communications device via a general network stack separate from the peer-to-peer network stack;

receiving a response from the server-based network via the general network stack; and

forwarding at least a portion of the response to the head unit over the serial data transport link.

9. The method ofclaim 8, further comprising:

determining whether the request is to be handled by a service via an external server-based network; and

according to the determination, performing the service locally or via forwarding the request to the server-based network.

10. The method ofclaim 8 wherein the performing of the service occurs irrespective of whether a network packet sent over the serial data transport link from the head unit containing the one or more requests includes the network address of the communications device as a destination network address.

11. The method ofclaim 8, further comprising:

configuring a user interface of the head unit to visually match a corresponding user interface of the communications device by communicating information over the serial data transport link from the communications device to the head unit, the information containing data for use by the head unit to configure the user interface of the head unit to visually match the corresponding user interface of the communications device.

12. The method ofclaim 11 wherein the information included in the at least a portion of the response forwarded to the head unit is for display on the user interface of the head unit configured to visually match the corresponding user interface of the communications device.

13. The method ofclaim 8, further comprising:

receiving at least one additional request via the peer-to-peer network stack by the communications device from the head unit over a serial data transport link;

determining whether the at least one additional request corresponds to a service on a specified list of services; and

forwarding the at least one additional request to the server-based network from the communications device through the general network only if it is determined that the at least one additional request corresponds to a service on the specified list of services.

14. The method ofclaim 8, further comprising:

caching at least a portion of the response on the communications device based upon previous monitoring on the server-based network types of and patterns of the received one or more requests.

15. The method ofclaim 8 wherein the serial data transport link between the head unit and the communications device is one of a Bluetooth® Serial Port Profile (SPP) type serial data transport link or Universal Serial Bus (USB) type serial data transport link.

16. A method for communicating in a communication network environment between a first and a second network peer over a direct serial data transport link between the first network peer and the second network peer, wherein there is an established data transport connection between the first network peer and the second network peer over the direct serial data transport link and wherein the first network peer has a separate connection over a separate network interface to a network external to the link, the method comprising:

receiving communications from the second network peer by the first network peer over the direct serial data transport link, the direct serial data transport link supporting at least one network in which only two network addresses are used at a given time on the network, the two network addresses consisting of a first network address for the first network peer and a second network address for the second network peer;

extracting payloads by the first network peer from the communications irrespective of whether network packets containing the payloads include the first network address as a destination network address; and

responding by the first network peer to a service request included in one or more of the communications received from the second network peer by: providing data to the second network peer that as originally obtained by the first network peer through the separate connection to the network external to the direct serial data transport link, and

wherein the established data transport connection between the first network peer and the second network peer on the direct serial data transport link is one in which resolution of network addresses of the first network peer and the second network peer to hardware addresses of the first network peer and the second network peer is not necessary for the responding by the first network peer to the service request.

17. The method ofclaim 16 wherein the data provided to the second network peer is provided over the established data transport connection between the first network peer and the second network peer.

18. The method ofclaim 16 wherein there is a second established connection using a separate transport on a separate network from the established data transport connection between the first network peer and the second network peer.

19. The method ofclaim 16 wherein the network external to the link is a server-based network.

20. A method for communicating in a communication network environment between a first and a second network peer over a peer-to-peer network connection on a serial data transport link between the first network peer and the second network peer, the method comprising:

receiving communications from the second network peer by the first network peer on the peer-to-peer network connection over the serial data transport link, wherein the first network peer has particular network services available natively at the first network peer; and

handling the communications received such that the second network peer may send communications over the serial data transport link including requests for one or more particular network services not available natively at the first network peer while keeping the peer-to-peer connection over the serial data transport link between the first network peer and the second network peer active and wherein the handling the communications received from the second network peer enables the second network peer to handle network communications in a same manner irrespective of whether the one or more particular network services are available at all to the second network peer.

21. The method ofclaim 20 wherein the peer-to-peer network connection is a connection using Transmission Control Protocol/Internet Protocol (TCP/IP) and either Serial Line Internet Protocol (SLIP) or Point to Point Protocol (PPP).

22. The method ofclaim 20 wherein at least one of the one or more particular network services not available natively at the first network peer is an Address Resolution Protocol (ARP) service or a Dynamic Host Configuration Protocol (DHCP) service.

23. A system, comprising:

at least one processor;

at least one processor-readable storage medium coupled to the at least one processor;

a peer communications control component under control of the at least one processor;

a first communications component that is in operable communication with the peer communications control component and has a peer-to-peer network stack to receive requests through a data transport connection over a serial data transport link to a head unit of an automobile and forward requests to the peer communications control component; and

a second communications component that is in operable communication with the peer communications control component and has a general network stack to send and receive communications from a server-based network that is external to the data transport connection and that is operable to provide Internet access, and wherein the second communications component:

forwards a request received from the first communications component via the peer communications control component to the server-based network via the general network stack;

receives a response from the server-based network via the general network stack; and

forwards at least a portion of the response to the head unit over the serial data transport link.

24. The system ofclaim 23 wherein the at least one processor, the at least one processor-readable storage medium, the peer communications control component, the first communications component, and the second communications component are all housed within a communications device having a handheld form factor.

25. The system ofclaim 23 wherein the first communications component sends service requests to the head unit originating from one or more applications under control of one or more processors of the system and sends service requests to the head unit originating from the server-based network that is operable to provide Internet access.

26. The system ofclaim 23 wherein the first communications component and the head unit each have a network address to use over the serial data transport link and the peer-to-peer network stack receives the requests through the data transport connection irrespective of whether a network packet containing the one or more requests sent over the serial data transport link from the head unit includes the network address of the first communications component as a destination network address.

27. The system ofclaim 23 wherein the peer communications control component configures a user interface of the head unit to visually match a corresponding user interface of the system by communicating information over the serial data transport link from the first communications component to the head unit, the information containing data for use by the head unit to configure the user interface of the head unit to visually match the corresponding user interface of the system.

28. The system ofclaim 27 wherein the information included in the at least a portion of the response to forward to the head unit is for display on the user interface of the head unit configured to visually match the corresponding user interface of the communications device.

29. The system ofclaim 23 wherein the peer communications control component determines whether one or more requests received through the first communications component from the head unit corresponds to a service on a specified list of services and, if it is determined that the one or more requests received through the first communications component from the head unit corresponds to a service on the specified list of services, the peer communications control component forwards such one or more requests received to the server-based network through the second communications component.

30. The system ofclaim 23 wherein the peer communications control component monitors types of and patterns of the requests received through the data transport connection and caches on the at least one processor-readable storage medium of the system at least a portion of a response received from the server-based network based upon the types of and patterns of the requests received.

31. The system ofclaim 23 wherein the serial data transport link includes at least one of a Bluetooth® type or Universal Serial Bus (USB) type serial data transport link.

32. An article of manufacture comprises a processor-readable storage medium having processor-executable instructions stored thereon to provide communications between a head unit of an automobile, a communications device having a handheld form factor, and a server-based network through which Internet access may be provided, wherein the instructions cause the communications to be provided by:

receiving one or more requests via a peer-to-peer network stack by the communications device from the head unit over a serial data transport link between the head unit and the communications device; and

performing a service specified in the one or more requests in response to the one or more requests, by:

forwarding a request to a server-based network from the communications device via a general network stack separate from the peer-to-peer network stack;

receiving a response from the server-based network via the general network stack; and

forwarding at least a portion of the response to the head unit over the serial data transport link.

33. The article of manufacture ofclaim 32 wherein the communications device and the head unit each have a network address to use over the serial data transport link and the performing the service occurs irrespective of whether a network packet containing the one or more requests sent over the serial data transport link from the head unit includes the network address of the communications device as a destination network address.

34. The article of manufacture ofclaim 32 wherein the communications are provided further by:

configuring a user interface of the head unit to visually match a corresponding user interface of the communications device by communicating information over the serial data transport link from the communications device to the head unit, the information containing data for use by the head unit to configure the user interface of the head unit to visually match the corresponding user interface of the communications device.

35. The article of manufacture ofclaim 32 wherein the information included in the at least a portion of the response forwarded to the head unit is for display on the user interface of the head unit configured to visually match the corresponding user interface of the communications device.

36. The article of manufacture ofclaim 32 wherein the communications are provided further by:

receiving at least one additional request via the peer-to-peer network stack by the communications device from the head unit over a serial data transport link;

determining whether the at least one additional request corresponds to a service on a specified list of services; and

in response to determining that the at least one additional request corresponds to a service on the specified list of services, forwarding the at least one additional request to the server-based network from the communications device via the general network.

37. The article of manufacture ofclaim 32 wherein the communications are provided further by:

caching at least a portion of the response on the communications device based upon previous monitoring on the server-based network types of and patterns of the received one or more requests.

Images