Transmitting custom advertisements to a client device   

Abstract: Systems and methods are provided for transmitting an advertisement to a client device. The method comprises, receiving from a client device via a communication network a profile that includes information concerning a user, selecting, via a processor, an advertisement from a plurality of available advertisements based on the information concerning the user included in the profile and also based on targeting criteria associated with each of the available advertisements, and transmitting to the client device via the communication network the advertisement selected from the plurality of available advertisements so that the advertisement can be presented via the client device.

This application is a continuation of, and claims priority to, U.S. application Ser. No. 13/073,837, filed Mar. 28, 2011, which is a continuation of U.S. application Ser. No. 12/345,420, filed Dec. 29, 2008, now U.S. Pat. No. 7,917,439, issued Mar. 29, 2011, which is a continuation of U.S. application Ser. No. 10/154,016, filed May 23, 2002, now U.S. Pat. No. 7,487,112, issued Feb. 3, 2009, which is a continuation-in-part of U.S. application Ser. No. 09/606,350 filed Jun. 29, 2000, now U.S. Pat. No. 7,133,837, issued Nov. 7, 2006, all of which are incorporated herein by reference in their entireties.

TECHNICAL FIELD

The present disclosure relates, generally, to the field of mobile communications and computer processing and more particularly, to a system, method, apparatus, and computer program product for providing location based services, mobile e-commerce, and other functions.

Mobile phones and personal digital assistants (PDA) include functionality that is typically limited to providing a telephone communication link, which can be also sometimes used as a data communication link, and a set of software programs such as a calendar, email client, mini-browser, word processor, and other similar user applications. Such devices therefore typically have limited functionality. Generally, very few of such devices include image input capabilities, voice recording capabilities, significant voice control capabilities, location determining or location based capabilities, or other capabilities described herein.

In addition, portable devices are often carried with users who travel through cities, shopping complexes, and other facilities and geographical areas. However, currently portable devices do not provide users with many services and functions that are related to, or based on, the user\'s location or changes in location. Similarly, while such devices often have capabilities for providing a telephone communication link, very few provide capabilities for providing wireless Local Area Network (LAN), wireless Personal Area Network (PAN), or any other wireless network communications. Furthermore, such devices typically do not include Web services capabilities or access thereto. As a result of these deficiencies and others, such devices fail to provide substantial mobile e-commerce services, location based functions, and functions or services available through the use of a wireless LAN.

Furthermore, to date, venders have not been able to take advantage of location information associated with customers and potential customers or obtain information about prospective customers. Typically, a vender only identifies the customer, if at all, when the person makes a purchase. Consequently, venders are typically not aware of the nearby or approaching presence of a past customer, potential customer, or person seeking a product that the vender offers. In addition, even if a vender had such information, venders have no mechanism in place for presenting advertisements to the person or otherwise enticing the user to visit the vender store location or make a purchase. Furthermore, even if such a mechanism was in place, the vender typically has no information about the person that can be used as a basis for selecting of an advertisement to be presented to the person or customizing the advertisement and the person has little incentive for viewing such an advertisement.

These and other deficiencies are overcome by various embodiments which provide a system, method, apparatus, and computer program product for providing location based services, location based mobile e-commerce, automated processing, wireless network communications, mobile telephone communications, and many other functions and services described herein.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated herein and form part of the specification, illustrate various embodiments and, together with the description, further serve to explain the principles of various embodiments and to enable a person skilled in the pertinent art to make and use various embodiments. In the drawings, like reference numbers indicate identical or functionally similar elements.

A more complete appreciation of various embodiments and many of the attendant advantages thereof will be readily obtained as the same becomes better understood by reference to the following detailed description when considered in connection with the accompanying drawings, wherein:

FIG. 1 is a functional block diagram of an example system, apparatus, and computer program product in accordance with one embodiment.

FIG. 2 is a schematical representation illustrating an example of an area, including a facility, for use with a method, system, apparatus, and computer program product according to one embodiment.

FIG. 3 is a schematical representation of an example vender facility for use with a method, system, apparatus, and computer program product according to one embodiment.

FIG. 4 is a data flow diagram of the method steps for implementing an example embodiment of a system, method, apparatus, and computer program product for determining the closest point of interest.

FIG. 5 is a data flow diagram of the method steps for implementing an example embodiment of a system, method, apparatus, and computer program product for determining a point of interest satisfying criteria.

FIG. 6 is a data flow diagram of the method steps for implementing an example embodiment of a system, method, apparatus, and computer program product for communication with a remote computer system.

FIG. 7 is a data flow diagram of the method steps for implementing an example embodiment of a system, method, apparatus, and computer program product for providing location based mobile advertising.

FIG. 8 is a data flow diagram of the method steps for implementing an example embodiment of a system, method, apparatus, and computer program product for providing mobile advertising.

FIG. 9 is a flow diagram of an example embodiment of the present invention.

DETAILED DESCRIPTION

According to one embodiment, a system, method, apparatus, and computer program product provide location services and mobile e-commerce.

According to another embodiment, a system, method, apparatus, and computer program product provide automated processing and mobile e-commerce.

According to still another embodiment, a system, method, apparatus, and computer program product provide mobile capabilities, and functions not available on existing mobile devices.

According to yet another embodiment, a system, method, apparatus, and computer program product facilitate localized e-commerce, such as in a localized auction, shopping complex, vender store location, or other facility or geographical area.

According to still another embodiment, a system, method, apparatus, and computer program product can facilitate commercial exchanges through the use of wireless communications.

According to yet another embodiment, a system, method, apparatus and computer program product for providing location based functions and mobile e-commerce comprises a central processing unit including a processor, a storage device, and programming stored in the storage device, a display device, an audio input device, an audio output device, a communications module, and a location module.

The programming controls the operation of the various embodiments to provide functions based on location data, to facilitate commercial exchanges by wirelessly exchanging payment and product information with venders, to identify services such as venders meeting selection criteria, to wirelessly exchange select information with other users and systems, to restrict and/or monitor the use of the device based on user provided parameters, selecting one of a plurality networks through which to communicate, triggering an action based on a change in location and sensed data, storing a voice annotation with computer data file, determining service providers and associated communication parameters, contemporaneously maintaining a wireless voice and data link, and many other functions and services that are described herein.

Further features and advantages of various embodiments, as well as the structure and operation of various embodiments and applications of the various embodiments, are described in detail below with reference to the accompanying drawings.

In the following description, for purposes of explanation and not limitation, specific details are set forth, such as particular networks, communication systems, computers, terminals, devices, components, techniques, data and network protocols, formats, software products and systems, enterprise applications, operating systems, enterprise technologies, middleware, interfaces, hardware, etc. in order to provide a thorough understanding of various embodiments.

However, it will be apparent to one skilled in the art that certain embodiments may be practiced in other embodiments that depart from these specific details. Detailed descriptions of well-known networks, communication systems, computers, terminals, devices, components, techniques, data and network protocols, formats, software products and systems, enterprise applications, operating systems, enterprise technologies, middleware, interfaces, and hardware are omitted so as not to obscure the description of the various embodiments.

References to a product is meant to mean any product, goods, service, or any other article of commerce including, but not limited to, such items as rentals, tickets (e.g., entertainment, travel, etc.), reservations (e.g., travel, hotel, restaurant, entertainment, etc.), real estate, information, food, and financial products among others.

In many of the applications of the embodiments, payment information is exchanged between the device and a computer system. The payment information may be related to any type of payment account and therefore may include, for example, credit card information, debit card information, bank account information, information for billing the product to the telephone or to an Internet Service Provider (IS) account used by the device, an email address (e.g., a Paypal® payment), brokerage account information, electronic fund transfer data, and/or any other data that may facilitate payment. The payment information will typically be different for each type of payment account. For example, the payment information for a credit card payment account may include a credit card number, expiration date, name of the card holder, billing address information, and possibly other information. However, the payment information for a bank account might include the bank name, bank account number, bank account owner\'s name, and a routing number.

Many of the embodiments described below include establishing a communication link or performing some other action upon occurrence of an event, such as when the user with a device according to one or more of the embodiments described herein is within a predetermined distance of a point of sale, a vender, a residence, a place for delivery of goods, a place for pick up of goods, or some other location. The communication link may be established by the device or the remote computer system depending on the design of the system and on which system senses the occurrence of the event as will be evident to those skilled in the art. The “predetermined distance” may be any suitable distance for implementation of an embodiment, is a design choice for the given application, may be different for different venders, different vender types (e.g., hotels versus restaurants), different embodiments and applications of the various embodiments, points of interest and/or different locations, and may be dependent or based on the strength of the communication signal. In addition, the predetermined distance may be the distance at which a communication link can be established or is established. Thus, the predetermined distance may be different for different user devices, external systems, times, locations, and need not be a fixed distance.

According to one embodiment, a multi-function communications device 101 is provided that includes conventional mobile phone and personal digital assistant (PDA) capabilities and preferably one or more of the functional modules shown in FIG. 1 such as a communications module 105, a location module 110, a recorder module 115, a data management module 120, an authentication module 125, an image module 130, a commerce module 135, and application modules 140 (e.g., computer programs), such as those described herein, all of which may make use of other modules. As will be discussed in more detail below, each module is comprised of a combination of hardware and software and may share (i.e., may be formed by) hardware and software of other modules as is well known in the art.

According to one embodiment, the multi-function communications device 101 comprises a portable device. The device 101 is preferably handheld, but may also be worn around the neck, on the hip, attached to the arm of the user, or carried in any convenient manner. According to one embodiment, the device 101 includes a central processing unit (CPU) 150, including a processor 155, a memory 160 (including volatile and nonvolatile), and communicates with various input and output devices described below. The software in one embodiment includes an operating system, and software for implementing the modules described above and in FIG. 1 and other functions described throughout. The software for implementing various embodiments is stored in memory such as Read Only Memory (ROM), EPROM (Erasable ROM), EEPROM (Electrically EPROM). In addition, the memory 160, some of which is preferably upgradeable, may be removably detachable memory to allow replacement if and when necessary (e.g., when becoming full). Thus, the memory 160 may also include one or more other types of storage devices such as a SmartMedia® card, a CompactFlash® card, a Memory Stick®, a MultiMediaCard®, a DataPlay Disc®, and/or a SecureDigital® card.

The device 101 includes a plurality of user input devices 165 such as a microphone, and actuators (e.g., a QWERTY keyboard). One means of supplying user input is through a voice command received by a microphone in a wireless single ear headset. However, other means of supplying the user input, such as manual input means via a touch pad, keyboard, buttons, touch screen, etc. may also be used.

The device 101 also includes a plurality of output devices such as an audio output device 170 (e.g., a speaker phone, stereo headset jack (and headset), earphone jack (and earphone), among others), one or more displays 175, LED(s), a vibrator mechanism, and a programmable ringer (e.g., which rings differently based on the source of a call, on the type of alarm (a page versus a phone call versus an alarm clock ring). The display 175 is preferably a high resolution color display and dynamic touch screen that allows the user to provide manual input for certain functions. The display is also capable of displaying a bar code that is capable of being read by a barcode reader.

The audio output devices, such as the earpiece and headset are preferably wirelessly connected to the device. The earpiece and ear portion of the headset are also preferably molded to the shape of the user\'s ear from rubber or other pliable material by means well-known in the art.

As discussed above, the device 101 includes the capability of providing conventional mobile telephone functions such as providing a wireless voice communication link, providing a wireless data communication link (for example, for connecting to the Internet, an email server, or other computer system), and includes applications sometimes found in a PDA such as one or more of an email client, a web browser (preferably Internet Explorer®), text messaging software, short message service (SMS) client or Unstructured Supplementary Services Data (USSD) client, an image viewer, an alarm clock, game software, paging software, a calendar, a word processor, a spreadsheet, a database, and a clock (with alarm capabilities). The device 101 also includes one or more of the functional modules (software and possibly hardware) of a voice recorder (preferably forming part of the recorder module 115), an audio media player, an audio/video player (which may also acts as the audio media player), facsimile software (for sending and receiving), an image editor, a terminal service client, a voice recognition module, and a virtual private network client. As will be discussed in more detail below, the specific functional modules and software applications are a design choice based on the external systems, desired functionality, costs, co-existing applications, and other factors. Likewise, depending on the modules and software applications included, various embodiments may take the form of a laptop or notebook computer, a radio frequency tag, a Smart Card, a PDA, a mobile phone, a computer integrated into another item such as a vehicle, or another suitable configuration.

Preferably the audio/video player is compatible with the open MPEG-4 (Moving Picture Experts Group) standard format and/or the other digital video compression standards (such as MPEG-2 and MPEG-1). More preferably, the player is RealPlayer Media Player® and can be used to play way, .avi, .mov, .mpeg, .mp3, .au, and .aiff files. While MPEG is preferred over competing formats, such as Video for Windows®, Indeo® and QuickTime®, one or more of these standards could be used instead of, or in addition to, software for processing video received in the one or more MPEG standards. Preferably, the audio player is an MP3 player.

The operating system according to various embodiments is Windows XP® or, alternately, PocketPC® (formally known as Windows CE®) or Palm OS®. The power supply for the device 101 is preferably a rechargeable battery unit such as lithium, nickel-cadmium or nickel-metal hydride battery.

As discussed above, the device 101 includes a communications module 105, which includes hardware and software to allow the CPU 150 to communicate with external devices and systems. The hardware and software used to implement the communications module 105 will be driven, at least in part, by the input/output devices with which the CPU interfaces as well as the external systems with which the device 101 communicates (receive data from and/or transmit data to). Preferably, all or part of the communications module 105 is implemented with one or more application specific integrated circuits (ASICs) and software stored in memory.

As discussed, the software used to implement the communications module 105 is determined, at least in part, by the systems with which the device 101 communicates. In the preferred embodiment, the device 101 is configured to receive and transmit (and store) conventional digital communications, which include mobile telephone communications, and other data communications including Internet data, mobile videophone communications, and to receive digital television signals, and digital radio signals (e.g., XM® radio signals). Preferably the device 101 is configured to operate with a conventional mobile telephone network or wireless wide area network (WWAN), and one or more other wireless local area networks (wireless LAN or WLAN), wireless Metropolitan Area Networks (MAN), and a wireless personal area networks (PAN) (e.g., a Bluetooth® network). According to one embodiment, the device 101 includes hardware and software for communicating with (or through) a mobile telephone network, a WLAN, and a wireless PAN. In addition, the device 101 includes hardware and software for communicating with another device 101 through a two way radio communication link.

In addition, the device 101 may also include software and hardware for receiving AM, FM and televisions signals. Such analog signals are preferably converted to digital signals at the source, or at an intermediate system, and transmitted to the device 101 as a digital signal through a wireless communication link. At reception, the signals are processed and presented to the user (e.g., via RealPlayer Media Player®) as is well known to those skilled in the art. Thus, the device 101 includes software for formatting, processing, and providing a representation of the signal to the display for presentation to the user. The device 101 may also optionally include an analog signal receiver (e.g., tuner, amplifier, etc.) for receiving and presenting analog radio signals directly.

The device 101 receives the digital signals from a remote receiver (e.g., through a wireless PAN from an automobile or in XM transmission), which provides the signal in digital form to the device 101, for immediate presentation or storage (e.g., as an MP3 file or an MPEG-4 formatted television broadcast). Furthermore, the remote receiver (e.g., in an automobile) may receive and store the data (e.g., in MP3 format) and transmit the stored data to the device 101 upon request by the user.

The following descriptions of various networks, standards, formats and protocols are well-known in the art, are provided as a matter convenience, and are not meant to be interpreted as a limitation on the communications capabilities of a device according to various embodiments. As discussed, technology for using any mobile phone network, WLAN, or PAN that is suitable for desired application(s) may be used. Communication with the wireless networks is accomplished through access points that receive and transmit wireless signals as is known in the art. Each access point is preferably individually addressable by a computer system (e.g., a client-server computer system)—which may be a vender computer system or facility computer system—with which it communicates data.

Preferably the device 101 includes a short range wireless LAN module (a PAN module) for communicating via a Bluetooth® network. The Bluetooth® wireless specification includes layer and application layer definitions and supports data, voice and content-centric applications. As is known in the art, devices that comply with the Bluetooth® wireless specification operate in the unlicensed, 2.4 GHz radio spectrum ensuring communication compatibility worldwide. The devices use a spread spectrum, frequency hopping, full-duplex signal at up to 1600 hops/sec. The signal hops among 79 frequencies at 1 MHz intervals to give a high degree of interference immunity and up to seven simultaneous connections can established and maintained.

The short range wireless LAN module (e.g., the Bluetooth® module) or PAN module allows the device 101 to wirelessly communicate with printers, wirelessly exchange payment information, communicate with automobile computer systems, building computers systems, facility computer systems, point of sale (POS) devices, vender computer systems, and with other devices employing the device 101. In addition, the PAN module can be used to communicate across a WLAN or WWAN.

Preferably, the device 101 complies with the Bluetooth® Hands-Free profile and imaging profile specifications. The Hands-Free profile enables hands-free use of mobile phones in automobiles and the imaging profile facilitates transmitting digital images over mobile devices. More specifically, the Hands-Free profile allows automatic establishment of a connection between the automobile\'s hands-free system and a mobile device the user brings into the automobile. The Imaging profile allows digital images to be shared among mobile devices. For example, a digital camera can share content with a mobile phone, personal computer or other handheld or be sent directly to a printer equipped with Bluetooth® wireless technology.

As is known in the art, Bluetooth® enabled devices include a link controller that identifies other Bluetooth® devices, coordinates a connection with such devices, and facilitates sending and receiving data from such devices. In establishing a connection with another Bluetooth® enabled device (e.g., a printer, computer, another device, etc.) the two devices first exchange a unique global identification code (global ID), which indicates the devices\' profiles and capabilities. If the device profiles match, a connection is made. If the device profiles do not match, the devices ignore each other. The profiles include sets of protocols and procedures that define device functionality and identity such as headset, printer, PDA, cell phone, pager, etc.

After two devices establish a connection, one is set as the master and the other becomes a slave. The connection of two or more Bluetooth enabled devices creates a PAN called a piconet in which all the devices in the same piconet are synchronized to the same hopping scheme determined by the master. As is known in the art, a Bluetooth® piconet can include up to 255 parked slaves (devices that are not actively receiving or sending data), which can be unparked by the master as needed. Devices in range of the piconet, but not connect to the piconet, are referred to as being in a stand by mode.

Bluetooth® compatible devices can be designed to have varying distances of communication capability. Consequently, Bluetooth® access points, which form part of a larger WLAN, a WAN, or other network can be strategically positioned so that communication is limited to devices within a predetermined and/or selected distance and/or direction. The Bluetooth® Specification v.1.1, including the Core Specification (Volume I) and Profile Definitions (Volume II), is hereby incorporated by reference.

As an alternate or in addition to Bluetooth technology, the device 101 may include hardware and software for communicating via the Echnonet standard.

The device 101 preferably also includes a WLAN module for communicating via a wireless local area network (WLAN), which are commonly used for corporate or Internet communications on campuses or enterprises. More preferably, the WLAN module is Wi-Fi (short for wireless fidelity) compatible, which means that is compliant with the IEEE 802.11b specification, which is DSSS—(direct sequence spread spectrum) compatible and has a communication range of approximately 1,000 feet in open areas and 250 to 400 feet in closed areas. Specifications for WLAN in Europe include HiperLAN2 (High Performance Radio LAN), which may alternately be used.

As discussed, the device 101 may also include a WWAN module. WWANs are commonly is used to link cities, states or large enterprises. One common protocol for this type of network is 802.11a. The IEEE (Institute for Electrical and Electronics Engineers) 802.11 standard (802.11, 802.11a, 802.11b, and 802.11b) is hereby incorporated by reference.

Preferably, the device 101 includes hardware and software for communicating with, or through, a third generation (3G) network, which is embodies some, or all, of the in IMT-2000 standard established by the International Telecommunications Union (ITU) or Universal Mobile Telecommunication System (UMTS). The preferred 3G network standard requires support for data packet networking (i.e., packet switched networking) and includes “always on” connection capabilities connection (or in other words an instant connection) and which allows the device 101 to receive incoming transmissions as they are sent. Networks employing at least some of the 3G standard include CDMA-2000 based services (e.g., CDMA 1XRTT, CDMA 2000 1XEV) (CDMA refers to Code-Division Multiple Access), FOMA (Freedom of Mobile Multimedia Access), and Wideband CDMA.

Alternately, or in addition, the device 101 is designed to communicate via a two and a half generation (2.5G) network, which is also a packet-switched network and an always on. Common 2.5G networks include General Packet Radio Service (GPRS) and Enhanced Data for GSM (Global System for Mobile Communications) Evolution (Edge), also referred to as Enhanced Data Rates for Global Evolution and Enhanced Data GSM Environment.

Alternately, or in addition, the device 101 is designed to communicate via a second generation (2G) network. Common 2G networks include CDMA, Time-Division Multiple Access (TDMA), and Global System for Mobile Communications (GSM). 2G networks are circuit switched networks and require logging on to the network (i.e., do not have always on capabilities).

Alternately, or in addition to the networks identified above, the device 101 is designed to communicate via an analog network often referred to first generation network or 1G network.

The device 101 also preferably includes Wireless Application Protocol (WAP) capability. Depending on the network or systems with which the device 101 is designed to operate, the following steps are performed to connect to the Internet, which are well-known in the art. First, the user opens a browser (e.g., a minibrowser). The device 101 transmits a query signal searching for service, and in response, a connection is made with the service provider. Next, the user requests a particular web page. The request is sent to a Gateway Server using WAP. The Gateway Server retrieves the information (e.g., the web page) via HTTP from the web server hosting the web page. The Gateway Server encodes the HTTP data as WML (Wireless Markup Language) and transmits the WML-encoded data to the device. The device 101 displays the wireless Internet version of the Web page requested.

As is known to those skilled in the art, WAP is designed to work on any of the existing wireless services, using standards such as Short Message Service (SMS), Circuit Switched Data (CSD), General Packet Radio Service (GPRS), and Unstructured Supplementary Services Data (USSD). Thus, the WAP protocols are designed to operate over a variety of different bearer services, including short message, circuit-switched data, and packet data although the bearers offer differing levels of quality of service with respect to throughput, error rate, and delays. However, the WAP protocols compensate for, or tolerate, these varying levels of service. Since the Wireless Datagram Protocol (WDP) layer provides the convergence between the bearer service and the rest of the WAP stack, the WDP specification lists the bearers that are supported and the techniques used to allow WAP protocols to run over each bearer and is hereby incorporated by reference. It is anticipated that the list of supported bearers will change over time with new bearers being added over time.

The device 101 may include multiple antennas, some of which may be removably attached. In addition and as discussed above, the device 101 may communicate with systems having their own antennas (e.g., via a LAN or PAN) in order to facilitate communications with the desired systems such as those that may be integrated into a vehicle. The communications module 105 of the device 101 also includes a port for wired connection to external devices, which is preferably a USB port. The protocols and other information necessary for communicating with the external systems (i.e., networks) are stored in memory. As discussed above, the device 101 also includes the capability of receiving processed and compressed video (e.g., MPEG-4) and therefore includes the software and hardware for receiving, decompressing, and processing the incoming compressed video for display.

In one embodiment, the communication module 105 allows the user to establish and maintain multiple communication links contemporaneously (wired and wireless) such as a wireless voice communication link (e.g., via a 3G network), multiple wireless data communication links (e.g., a wireless LAN and PAN link), and one or more wired links simultaneously. In addition, contemporaneous communication links (such as a voice and data link) with multiple external devices may be accomplished through a single network, such as through the 3G network, 2.5G network or WLAN.

Contemporaneous wireless communication links through the same network may be accomplished by multiplexing of packet data, which is well-known in the art. In addition, information about the incoming data packets sufficient to allow the communication module (or other software) of the device 101 to determine how the incoming data should be processed (e.g., to which module the data should be supplied or to determine how otherwise to process the incoming data) is also supplied to the device. This technique is well-known in the art and the details thereof are, therefore, not provided here. However, this information—the information that allows the communication module to determine how to utilize the data (collectively “utilization information”)—may be included in some or all of the packets (e.g., a sub-address), may be determined by the transmission format, data type, communication link, or transmission source, or determined in any suitable manner well-known in the art. In other words, the received data packets are routed by the communications module to the appropriate software and/or hardware such as memory, the headset, the display, an MP3 player, the location module, and/or another application or module based, at least in part, on the utilization information, which may be supplied in the packet (e.g., which may simply indicate the source of the data or identify the destination module for the data) or otherwise determined (e.g., from the communication link or format of the received data). Outgoing data is multiplexed and addressed to the respective addresses of the remote devices with which the device 101 is communicating.

Thus, the contemporaneous wireless communication links permit the user to participate in a conversation via a voice communication link (e.g., via a 3G, 2.5G, or 2G network) while simultaneously using a data communication link (e.g., via a WLAN, PAN, 3G, 2.5G, or 2G network) to receive or send emails, transmit and receive data via the Internet, download audio or video files, upload and download data, or otherwise transmit and/or receive data. Thus, the user can also receive and transmit live audio/visual data—such as live video transmissions (e.g., a video telephone call, receive a television transmission, transmit video camera data), and live audio transmissions (e.g., a telephone call, receive radio transmission, transmit voice data)—while also transmitting and receiving computer data such as emails, word processing files, spreadsheet files, application files, and data to remote computer systems (e.g., such as a web page from a web server) and non-live audio/visual data (previously stored audio data and video data). While the actual reception and transmission of the bits comprising the multiple transmissions may not occur “simultaneously” from a technical perspective, the data from the multiple transmissions is presented to the user and received from the user in the same time periods (or overlapping time periods), which is herein referred to as contemporaneous transmission and/or reception.

The transmission of “live” audio/visual is meant to mean the process of transmitting an audio or video signal immediately, or immediately after processing (which may include storing), after the signal is received at the device 101 (e.g., from a camera, microphone, or from other remote device). The presentation of “live” audio/visual is meant to mean the process of receiving an audio or video broadcast and immediately, or immediately after processing (e.g., after storing), presenting the audio and visual to the user on the audio output device and/or display device. The data that is received live may be transmitted as captured from live events from the source or may be transmitted from a previously stored audio/visual production and transmitted upon request by the user (e.g., a movie transmitted on demand).

The communication module and CPU also cooperate to allow multiple modules to work together. For example, if the user is listening to an audio program via the headset (such as a digital radio program or a MP3 production), the device 101 produces an audible alarm (such a beep) to inform the user that a telephone call is being received, or that another application is requesting the user\'s attention. Alternately or in addition thereto, and at the selection of the user, a vibratory alarm can be used to inform the user of an incoming telephone call, email, page, or other event.

The communication module may also route certain data to remote devices during live or non-live presentation to the user. For example, a video transmission or computer data (e.g., web pages) received by the device 101 may be routed (e.g., as requested by the user) to a remote display device (e.g., via a wireless PAN to a display in an automobile) that may be large or of better quality than the display of the device. Similarly, audio signals may be transmitted to a remote stereo system (e.g., in an automobile). The data may be processed, such as being compressed and stored for later retrieval, prior to being routed to a remote device.

As discussed, the device 101 may include means for communicating via two or more communication networks (e.g., wireless WAN, LAN, and PAN). Thus, when communications with the desired external system may be accomplished by more than one network, the device 101 determines the available network with which to establish the communication(s). The programmed rules for determining which available network with which to establish a communication (or communications) are stored in memory and based on information of the available networks with which the device 101 is designed to communicate and may also be based on user activity or anticipated user activity. The programmed rules may be designed to provide any desirable result such as increasing efficiency, reducing costs, and/or increasing throughput.

In this example, the determination of the available network with which to establish one more communications is based on one or more of the available bandwidth of each available network (i.e., the amount of data that can be communicated over a given time period), the anticipated bandwidth necessary, the available capacity or relative available capacity (e.g., how full to capacity a network is), the historical (or anticipated) availability of bandwidth (which may include, for example, use, volume, capacity, and/or speed data for days of the week or times of the day), the communication capabilities of the device, the amount of data to be transmitted, and the cost of using each network (e.g., connection time, per amount of data transmitted).

For example, if the available WLAN network has a maximum speed of 50K/sec, an available 3G network will likely have greater available bandwidth. If the user desires to download and watch a movie (which may determined by a user input in response to a prompt or by the user opening an audio/video player for external retrieval of the video file), relatively high bandwidth can be anticipated as being needed. Since the WLAN does not provide enough bandwidth to receive the communication (e.g., movie data file) in a desired manner without buffering, the higher speed network is selected. If both networks have enough available bandwidth, the network is preferably selected based on the costs of use. For example, many Wi-Fi networks are free, while 2G networks have a cost per minute of use. If these two example available networks have enough available bandwidth for the communication, the programming rules determine selection of the Wi-Fi network since it is less expensive to the user. Thus, in this example embodiment the programmed rules will be based on bandwidth availability (anticipated, current), which may be estimated or known (which may be stored as a result of a transmission), and cost.

Prior to communicating with the external system, the device 101 preferably transmits a request for communication via the various networks with which the device 101 is designed to communicate. In addition, communications with some networks (e.g., always on networks) may already be established. Thus, the determination of the available networks with which to establish the desired communication, and information relating to it (e.g., bandwidth data), can be established during the requested communication.

Moreover, the device 101 includes programming for switching communication networks. Thus, when network switching conditions arise, the device 101 establishes a communication with the external device via a second network and preferably terminates the communication established through the first network. Network switching conditions may include one or more of 1) changes in network conditions such as failure of a first network or the first network slowing down (due to high use such as multiple users and/or high levels of data being communicated), such as below a predetermined level (e.g., threshold speed), or increases in noise, 2) the user making a request, or attempting to make the request, to communicate data that is more suitable for communication through a second network (e.g., the user requesting a video file or movie), 3) the anticipated request of the user (e.g., based on the user starting a particular application such as a video player), 4) changes in network availability (e.g., a new network becoming available), 5) changes in conditions of the second network (e.g., more bandwidth or less noise), 6) the available capacity or relative available capacity (e.g., how full to capacity a network is), 7) the communication capabilities of the device, and 8) the historical (or anticipated) availability of bandwidth of network(s) (which may include, for example, use, volume, capacity, and/or speed data for days of the week or times of the day). The device 101 may determine any of the above information itself or receive the information in a transmission from remote computers, which monitor the networks.

In some situations, more than one network may be operated by the same computer system (e.g., of the same service provider). Thus, a multi-network computer system (MNCS) having information relating to more than one network may determine, or assist the device 101 in determining, which network should be used by the device 101 for communications. The MNCS determines the available network with which to the device 101 establishes the communication based on any of data described above, which may be determined itself (e.g., historical data) or received from the device 101 (e.g., based on a user request for a video file). Upon determining the available network with which the device 101 should establish the communication, the MNCS transmits information identifying the network, which is received and used by the device 101 as a basis for determining the network with which the device establishes the communication. Likewise, the MNCS determines whether network switching conditions (described above) arise and initiates the switch by transmitting data requesting a switch (or used by the device 101 determine whether a switch should be completed), which includes data identifying the second network.

As discussed, the programming that controls the operation of the communication module 105 and other modules of the device 101 is stored in the memory 160 of the device 101.

As discussed the communication module facilitates communications, as shown in FIG. 6, by performing the steps of receiving data for communications (not shown), determining communications parameters (e.g., format, protocol, communication network, destination) at step 401, formatting the data for the desired destination at step 405, transmitting the data at step 410. The data is transmitted according to the determined protocol and to the determined destination. The communication module 105 also receives transmissions, which may be responses to device 101 transmissions at step 415. The received data is decoded at step 420, which may include, but is not limited to, unformatting, deformating, transcoding, and/or interpreting (e.g., name value pairs) the received data. At step 425, the decoded data is processed by the communication module or other computer program (e.g., the commerce module, authentication module, or other application module).

In performing these steps and others, the device 101 may make use of Web services. As is well-known in the art, a Web services provides a standardized interface that permits software programs in the service provider to communicate with remote programs (e.g., in the device 101). More specifically, a Web service is a software module hosted by a service provider that can be run remotely. In order for it to be available to remote systems, a descriptor of the Web service is published to a service registry. Information about the Web service and how to use it is found in the descriptor. When a service requestor (which may be software executing on the device 101 or on behalf of the device) desires to run a Web service, it contacts the service registry. Based on data found in the descriptor, the requestor binds to the service provider and runs the Web service. The directory may also be used to search and identify providers of particular services.

As is well-known, XML is a mark-up language used to define standardized elements of web pages and business documents such as product name, product number, price, and other characteristics (e.g., color, size, etc.) thereby defining what kinds of information each element contains. In the preferred embodiment, the Web service core technologies include UDDI (Universal Description Discovery and Integration), SOAP (Simple Object Access Protocol), and WSDL (Web Services Description Language) and are in XML format. While these technologies and their functionality are known in the art, the following description is provided for convenience. However, other embodiments may employ other features available to these technologies not listed here.

As discussed, the service registry of the preferred embodiment is a UDDI implementation and is essentially a catalog of businesses and the web-accessible services they provide. The Web Service Registry provides a mechanism to advertise and find Web Services. The Registry contains categorized information about businesses and the services that they offer and associates those services with technical specifications of the Web service. As discussed, these technical specifications are defined using a descriptor, which in the preferred embodiment is a WSDL document.

WSDL documents describe Web Service function(s), how it communicates, and where it can be found (e.g., an address or destination for communication). In operation, a Web Service requestor (e.g., a device 101) queries the Registry to find the descriptor to determine how to use the Web Service. The UDDI is itself a Web service and the Registry specification defines an Application Program Interface (API) based on SOAP messages with a description of the registry service. Most registries also provide a browser-based human interface. The UDDI Project operates a global public registry called the UDDI Business Registry, which is available to at http://www.uddi.org. Organizations can also set up a private registry to support the requirements of an enterprise or a private community such as for a shopping complex. A private registry can impose additional security controls to protect the integrity of the registry data and to prevent access by unauthorized users. A private registry might contain only private information, it might contain a subset of the public registry information, or it might contain a combination of public and private information.

A UDDI implementation is made up of three different elements. Not all listings in UDDI registries, however, contain all of the elements. The first of the three elements is a “white pages,” which contains the basic contact information for each Web service listing. White pages generally includes basic information about the company, as well as how to make contact. Another element is a “yellow pages,” which has more details about the company, and includes descriptions of the kind of electronic capabilities the company can offer to users who desire to do business with the company. The yellow pages uses commonly accepted industrial categorization schemes, industry codes, product codes, business identification codes and the like to make it easier for requestors to search through the listings and find exactly what is desired. Third, a UDDI includes a “green pages,” which allows the requestor to bind to a Web service after it has been found. The green pages include the various interfaces, URL locations, discovery information and similar data required to find and run the Web service.

An “identifier” is a type of property or keyword used to uniquely identify a business or specification in the service registry. Identifiers can be applied to <businessEntity> and <tModel> structures. Identifiers, like categorizations, can be used as part of a search when doing a <find_business> or <find_tModel> request message. Identifiers and categorizations are implemented similarly. Identifiers are attached to <businessEntity> and <tModel> documents through an <identifierBag> structure. The <identifierBag> structure can have one or more <keyedReference> structures that provide the name, value, and <tModel> UUID reference for locating more information.

Preferably, two general-purpose identifier schemes have been incorporated into all operator nodes, but other schemes can be used as well. The identifier types that are a core part of an operator node include D-U-N-S (tModel name of dnb-com:D-U-N-S) and Thomas (tModel name of thomasregister-com:supplierID). The Dun & Bradstreet® (D-U-N-S) number is a unique nine-digit identification sequence. This sequence provides unique identifiers for single business entities, while linking corporate family structures. This information is available at http://www.d-u-n-s.com. The Thomas Registry® scheme (Thomas) provides identifiers for many thousands of manufacturing and e-commerce companies worldwide. Additional information is available at http://www.thomasregister.com.

tModel documents provide metadata information about a web service specification, categorization specification, or identifier specification. tModel documents are a core data structure in the UDDI specification and represent the most detailed information that a UDDI registry can provide about any specification.

SOAP (Simple Object Access Protocol) includes a communications protocol that facilitates use of the Web services of the preferred embodiment and used to send commands across a communication link (e.g., HTTP internet connection) and includes destination information, content information, and use information. SOAP is used to publish the descriptor into a service registry; to send a service request from a requestor to the registry; to send information from the registry to the requestor; and then to allow the requestor to bind to the service provider and run the Web service.

A message sent via SOAP is in XML format, and is made up of three parts—an envelope, a header and a body. The envelope encapsulates the message header and body, and contains a variety of information required for processing the message, including a description of the kind of data to be found inside the envelope, and information about how that data should be processed. It also contains information about the sender and recipient of the message.

SOAP does not require that a message contain a header, although as a practical matter, messages will include them when SOAP is used in Web services. Information found in headers can perform a variety of functions, such as providing authentication. The data found in headers is organized into header blocks and there can be one or more blocks in a header. The body of the message contains the message data. The data might be a request for information—for example, when a service requestor is searching a service registry for a Web service—or it might be a response to a request for information, such as when the registry sends back a descriptor. The data found in the body is organized into sub-elements and there can be one or more sub-elements in the body.

As discussed, a descriptor document (e.g., WSDL document) is a set of computerized instructions that provide information relating to the functionality of a Web services application and the protocols and formats it uses. WSDL is an XML-based language used to create documents that provide vital information about how the Web services can be located and executed (or run).

In order to run a Web service, a requestor first needs to locate the WSDL document that details how to run the services. Once the document is found, it is transmitted to the requestor. The descriptor (e.g. WSDL document) is then processed, and based on the information in the received descriptor, a SOAP request (or requests) is transmitted to the Web service provider. That service provider then sends the information requested using the SOAP protocol.

A requestor can get a WSDL document in a number of different ways. The document may be located in a searchable, public or private UDDI directory as described above. The WSDL document may also be retrieved from memory and can be transmitted from, requested from, and located in a variety of ways, including via HTTP requests, FTP, and email.

As discussed, a WSDL document describes Web service functionality, details where the service can be located, and then provides specific instructions on how that service can be bound to and run. To accomplish these objectives, a WSDL document includes a number of different important elements. Among the most important ones are “type” and “message” elements, which describe the information to be passed in the Web service. The “type” element is a container for data type definitions using some type system. The “message” element is an abstract, typed definition of the data being communicated and is in essence the information that is going to be exchanged or requested. The “binding” element details how information is going to be passed between the requestor and the Web service, and includes information such as the protocol and data format. Bindings may be HTTP, SMTP, MIME or other suitable binding. The “portType” describes the operations that will be supported by the Web service. The “service” details the location of the Web service. Finally, the “operation” element is a description of an action supported by the service. Web services and their use are described, in part, in WSDL 1.1, WC3 Note 15 dated March 2001 and I the Web Service Description Requirements W3C Working Draft dated Apr. 29, 2002, which are hereby incorporated by reference.

Finally, once information regarding a service provider is obtained, the device 101 preferably stores the information for repeat use (either locally or on a remote storage device for retrieval as needed by the device). Specifically, the device 101 stores the list of service providers and their associated data, including the information retrieved from the registry such as the descriptor document (WSDL document), which includes the format and protocol used by the service provider.

As is known in the art, communication devices include numerous layers that cooperate to facilitate the communication with each layer performing a different function. For example, the physical layer, which is layer 1 of the Open Systems Interconnection (OSI) networking model relates to the mechanical, electrical and functional aspects of connections in a communications medium. Other layers include the data link layer, the network layer, the transport layer, the session layer, the presentation layer, and the application layer. Control and data is passed from one layer to the next. As is known in the art, a communication may begin with the application layer on one end (for example, a user opening an application and typing a request). However, according to various embodiments, the programming may initiate the communications as will be evident by the description of the application program below. Thus, the programming, which, for example, receives user inputs and transmits data to remote devices, takes actions based on location and/or triggering events, and performs other functions may be designed to execute largely in the application layer as will be evident to those skilled in the art.

Preferably, the communication module 105 allows for dynamic adjustment of bit rate, protocol, and format to accommodate communications with different types devices and changing network conditions. In the preferred embodiment, an encryption module is included to encrypt and decrypt data before transmission and after reception for systems employing encrypted transmissions and/or when the application being serviced does not provide encryption. The device 101 supports data protection and user authentication using the Extensible Authentication Protocol-Tunneled Transport Layer Security (EAP-TTLS) protocol, which only requires a password from the end user for authentication, for communicating with external systems supporting the protocol.

The location module includes hardware and software to determine the location of the device. Depending on the implementation of an embodiment, the location module may determine the absolute and/or relative location of the device. The absolute location may be determined by using a global position satellite (GPS) receiver that is integrated into the device, which can be used to determine the approximate longitude and latitude of the device. Another method of determining the absolute location is through the use of a network-based position-location system, which may use, for example, triangulation from cell towers to locate the device. Network-based location systems are manufactured by TruePosition Inc. in King of Prussia, Pa., or Forest, Va.—based Grayson Wireless, a division of Allen Telecom Inc. in Beechwood, Ohio. Thus, the location data may be transmitted to the device 101 from an external system (e.g., a network-based position location system) capable of determining its location.

Absolute location data may also be transmitted from a nearby device (e.g., an airplane, a bus, an automobile, a ship, etc.), which itself has a means for determining its absolute location or transmitted from a nearby device that is fixed in location and that has absolute location data pre-stored therein (e.g., via WLAN from an access point in a billboard, a road side sign, a vender, etc.). In addition, data in periodic transmissions or in a single transmission from a fixed device could be used with velocity data supplied by a vehicle to determine an accurate and substantially continuous (up to date) absolute location of a device carried in the moving vehicle.

The location data may be used with map data stored in memory of the device 101, or stored in a computer system with which the device 101 communicates (such as in a vehicle computer system or remote computer) to provide a real world location (e.g., a street, intersection, address, complex, or business) as is well-known in the art.

The relative location refers to the location of the device 101 relative to another point of interest such as the distance (or in some applications the time) from a particular point of interest. For example, in some embodiments, in may be necessary to find the closest vender of a given product. In doing so, the relative location of the device 101 from each vender is compared to find the closest vender. The relative location to a point of interest may be determined from the absolute locations of the device 101 and the point of interest. In addition, in some applications the cumulative distance of the thoroughfares (streets, roads, highways, etc.) between the device 101 and the point of interest may be determined and used to determine the relative location of the device 101 with respect to the point of interest. In other embodiments, a communication link with a particular access point (or a plurality of access points) may provide relative location data (e.g., that the device 101 is in a room, facility, parking lot, vender store location, or other area) to the device 101 or an external computer system.

The relative location may also be determined from data transmitted from nearby devices (e.g., via WLAN from an access point in a billboard, a road side sign, a vender, etc.) that includes information of the relative location of the nearby device. For example, the nearby device (e.g., a billboard with a wireless transceiver therein) may transmit information to the device to indicate that the device is at, or within, a predetermined distance of a particular point of interest (e.g., a vender). Alternately, the nearby device may transmit the distances from the nearby device to a plurality of points of interests when the communication link with the device 101 is established. In addition, data in periodic or a single transmission from a fixed device could be used with velocity data supplied by a vehicle to determine an accurate and up to date relative location.

Preferably, the location module includes a GPS receiver with mapping software. In addition, relative location data is determined from the device\'s 101 communications with access points that form part of a WLAN. However, any suitable means of determining an absolute or relative location that is suitable for the embodiment or an application may be used.

The authentication module 125 authenticates the user (or in some instances the user\'s device) through the use of authenticating data. Authentication may be used to confirm the identity of the person carrying the device, to prevent the unauthorized use of the device, and to authenticate the creation, use, transmission, or storage of data at the device 101 or at a remote device. The authenticating data may include, but is not limited to, a password, pin number, voice data, face data, iris data, and/or finger print data that may be stored in the device 101 and/or at a remote computer system used to authenticate the user.

The determination as to whether authenticating data is necessary to perform a given action is determined by the remote system with which the action is to be performed (e.g., a purchase made, data stored, information provided) and/or by the programming in the device 101 when predetermined actions are requested (e.g., to make a purchase). For example, authentication may only be necessary when purchases are sufficiently large or other security measures warrant it.

Authentication may be performed in numerous manners, is largely a design choice and its implementation will vary depending on the application, available data, available hardware, the external systems, and costs. For example, in one embodiment, no authentication is necessary when making a small purchase. When making a purchase above a predetermined price threshold (e.g., $500), a first level of authentication may be required such as entering a pin number or password into the device 101 (much like a debit card), which may be transmitted to a third party computer network for validation thereby providing authenticating data to the external system. In addition, the device 101 may request authenticating information from the user in certain circumstance and include programming that does not permit certain activities (e.g., commercial transactions) unless the user enters a valid password (either at power up or upon requesting a commercial transaction). In addition, confirmation that the user has entered a password to facilitate the commercial transaction (i.e., provided authenticating data to the device) may optionally be transmitted to a vender computer system or other remote computer system during the transaction to give the vender additional confidence of the user\'s authority to use the device 101 and its payment means.

Other means of authentication may include recognizing the user\'s voice (which is compared to a stored voice), receiving a finger print input at the image module which is compared to stored finger print data, and receiving data of an image of the face or iris of the user at a video input, which is compared to stored data of the same.

Alternately, the user may have an rf tag in the form of an integrated circuit implanted under the skin (or otherwise attached to the person), which contains user identifying information, such as, or similar to, the Verichip® manufactured by Applied Digital Solutions of Palm Beach, Fla. This rf tag can be pinged (transmit an rf signal to) to determine the identity of the user by the device 101 or by a remote system within range of the user. The identification information is transmitted from the rf tag, received by pinging device (or other device), compared with the information associated with the user (which may be supplied to a remote computer system by the device 101 or already present in memory of the remote computer system) to confirm the user\'s identity or to determine his or her identity.

Input of authentication data may be required at power up or at the request by the user to enter into a commercial transaction or to otherwise use the device 101 in a fashion that has been determined to require an authentication input.

In addition, the authentication data may be stored in memory and retrieved for transmission to a remote computer that determines whether the user\'s voice, face, iris, finger print, or other input matches the data stored in memory. In addition, transmission of the authentication data of the user\'s voice, face, iris, fingerprint retrieved from memory may require input of a password or pin number. Upon receipt of the authentication data, validation data is transmitted to the vender, the financial institution issuing payment at the request of the user, or other computer system from the remote computer system performing the validation. Thus, a thief or unauthorized user would have to store new authenticating data (their own data) in memory in order to operate the device. Preferably the new data can only be stored, however, if the necessary authentication input (i.e., voice, iris, face, finger print, or other input) is inputted to permit overwriting the old data or the addition of new data for a new user. In addition, some applications may require that the user transmit a live authenticating image or video data (as opposed to being transmitted from stored data). Live data is transmitted along with data sufficient to confirm that the data is not a transmission of a recording, such as information of the time of day and/or date, data supplied by an external system, location data, and/or other data.

In applications where greater security is needed, a third party computer system (or the computer system of the vender) can store the authentication data (voice, iris, face, finger print, or other data) and compare the data from the user received from a vender input device (e.g., a scanner) with the stored data to authenticate the user. When a valid comparison is made, the third party computer system transmits validation data indicating the authority of the user to perform the requested action (e.g., confirming the user\'s identity) or information indicating that the person is not authorized to perform the desired action.

In addition or alternately, an image of the user can be stored in the device 101 and displayed on the display of the device 101 to the vender or entry control personnel who can then compare the stored picture with the face of the user. The picture (or other data such as voice, iris, or finger print data) stored in the device 101 can also be compared to a picture (or other data such as voice, iris, or finger print data) stored by the vender (or by the entry-control computer system) and/or compared to an identification document (e.g., a passport or driver\'s license) carried by the user.

In addition, the authentication module includes programming for authenticating a data file at its creation, receipt, modification, transmission, and/or some other operation on the data file. Prior to use, the user supplies authenticating data to the device 101 (e.g., logging in with a password). After (or during) the operation on the data file, the programming embeds, or otherwise attaches or associates, information based on the authenticated data in the data file. For example, prior to creating a text file, modifying a file, upon receiving a file, taking a digital picture, transmitting a file or performing some other action on a file, the user inputs a username and/or password (or supplies other authenticating information as described above) to the device 101 that confirms, or is used to determine, the identity of the user. When the user creates a text file, modifies a file, receives the file, takes a digital picture, (all of which require storing the new version of the file), transmits a file or performs some other operation on a file, the program embeds (or otherwise associates or attaches) information sufficient to identify the user performing the operation when storing the file.

An authorized user may select which data files to include authenticating data and can program the device 101 to include it for all, or select, operations performed by users who are not the authorized user (e.g., a child or employee). In addition, the device 101 can embed (or otherwise associate or attach) information sufficient to identify the device. In addition, other information such as the time and/or location data (e.g., received from the location module or otherwise supplied) may be embedded in (or otherwise associated with or attached to) the data file at creation, modification, receipt, transmission or some other operation on the file when the file is saved.

Thus, this feature can allow a person such as a police officer to take a digital photograph of a crime or accident scene, embed (or otherwise associate or attach) information of the location, time, and/or identity of the person taking the photograph in the digital file, wirelessly transmit the file to a remote computer system for storage and use as evidence. The methods of embedding, associating, and attaching a subset of data in, with, and to a data file are well known in the art. Those skilled in the art will recognize that the method, protocol or format for embedding, associating, and attaching the information sufficient to identify the user, device, location, and/or time may be any method which permits the data to used, extracted, read, or otherwise interpreted at a subsequent point in time and that limits the ability of users to alter the embedded or otherwise attached data.

The recorder module 115 of the device 101 also includes the features normally associated with a conventional voice recorder such as voice recording and voice playback. The recorder module 115 may also be used to record data being received or transmitted through the communications module 105, produced by an output device such as the display 175 or audio output device 170, and received from any input device 165. Thus, the recorder module 115 can also record data being received for and/or produced at the audio output device and can be used to record both sides a telephone call conversation and to record music that is being received and/or played live (for example, digital radio). In addition, the recorder module 115 may also be used to store video data received and/or transmitted such as a video telephone communications and digital television transmissions. For video telephone communications, the device 101 can record either or both sides of the conversation (both the incoming and outgoing transmissions).

In the preferred embodiment, all data supplied to the audio output device, input device, and display, is stored in volatile memory (e.g., RAM). If the user has elected to record the data, the software implementing the recorder module simply does not overwrite the stored data in volatile memory until the data is moved to nonvolatile memory (e.g., EEPROM). The data can then later be retrieved for audible and/or visual reproduction, converted to text using well-known voice recognition software (in the case of stored voice data), or transmitted to a remote computer for processing (such as being converted to text, indexing) and storage.

The recorder module 115 may be used to store voice annotations for computer data such as a computer file. For example, the user may wish to store a voice annotation for a scanned document such as the spoken words, “Vehicle Registration,” which are received at the device\'s 101 microphone. The voice annotation and document are stored in manner that allows the user to retrieve the annotation alone, with the document, or the document without the annotation. For example, a header of the computer data file may include information identifying all of the voice annotations for the computer data. Thus, when the user retrieves the computer data file, the voice annotations are automatically identified to the user who may select the annotations for audible production. Alternately, they may be automatically produced to the user at retrieval of the computer file or upon some other action. Any suitable scheme for storing the computer data and associated voice annotations may be used. As another example, a file directory may include a list of each computer data file, each voice annotation, and information for identifying the association of each computer data file with its voice annotation(s).

One or more voice annotations may be stored for each page of data in a computer data file. The voice annotation may be attached to any portion or portions of a computer data file such as an image file, an audio file, a video file, a word processing file, a spreadsheet file, address book entry or file, an image within a composite file, or other application data file.

Finally, the recorded voice data can be processed for use as file storage data. For example, the voice data may be converted to text and used as the file name of the computer data file for storage of the computer data. Thus, after the user creates a file, for example by taking a digital photograph, a digital video, or recording an audio file, the user can input voice data that is used as the filename for storing the created file and also used to determine the destination for storing the data file.

The image module 130 includes the hardware and software used to receive and process image data, which may include digital photographs, bar codes, text, and other image data. The image module 130 preferably includes a digital camera that functions to capture still photographs and video data (i.e., motion video). The image module 130 also includes software for converting received image data (e.g., received as an image when the digital camera acts as a copier by photographing text) to text, which is preferably conventional optical character recognition (OCR) software. The image module 130 may optionally also include a conventional scanner and/or bar code reader, which are well known in the art. Other image input devices may be included instead of, or in addition to, the above image input devices such as an infrared transmitter and/or receiver as is deemed appropriate for the embodiment. Finally, the image module 130 may also optionally include hardware and software for receiving and processing fingerprint, iris, or face data used for authenticating the user (e.g., a fingerprint scanner).

The hardware portion of the image module 130 may be detachable or, in some embodiments, may be disposed remotely such as in an automobile and in communication with the handheld portion of the device.

As discussed, the image module 130 allows the user to scan text, bar codes, or other markings or indicia for storage in the device. The data can then be processed according to instructions or other information found in the scanned image or according to a user input. For example, the user could scan a web address and say “connect” to provide a voice command that instructs the device 101 to provide a data communication link to the scanned web site. Alternately, the user can scan a product name or number and input a command (by saying “purchase”) to purchase the product. In response, the device 101 retrieves payment information, user information and an address (e.g., web address) of a vender for such products from memory, service registry or other source and transmits the product information, user information, and payment information to the vender to purchase the product.

When the image input device is used to capture the image of text (e.g., a document), the data may be wireless transmitted to a printing device thereby effectively acting as a wireless copying system. Thus, the user need not carry each document to a copier for copying but can simply retrieve the copied pages. Multiple devices may transmit the data to the printing device, which, after processing (e.g., normalizing), queues the data for printing like a conventional printer or fax printer. Instead of a handheld device, another embodiment implementing this application may be a desktop device that captures the image and transmits it wirelessly (or via wire) to a remote printing device.

The captured images may also be transmitted to a remote computer system for processing such as converting the images to text via OCR software, and subsequently printing the data. As discussed above, the user may also annotate the image data with a voice annotation.

The commerce module 135 facilitates commercial transactions and in particular, performs the steps of exchanging payment information, receiving acknowledgement of satisfactory completion of the transaction, providing an indication of the satisfactory or unsatisfactory completion of the transaction to the user, and processing and storing information resulting from the transaction (e.g., a hotel room number, a ticket number, etc.).

In performing the above steps, the commerce module 135 manages the means for making payment. The commerce module 135 stores data payment information supplied by the user or received from an external source in memory 160 in different categories. In particular, the commerce module 135 stores various categories of information for making a purchase such as credit card data, bank account data, debit card data, telephone account data, email account data, ISP account data, brokerage account data, and/or other data. Each category includes numerous payment account records. For example, data stored in memory 160 for one category includes the credit card number, expiration date, billing address, and credit card holder\'s name for four different credit cards (a gas card, a MasterCard®, and a Visa® card, and an American Express® card). Likewise, the memory may additionally hold data for two bank accounts (a second category) and two ISP accounts (a third category).

In many of the applications of various embodiments, a request to purchase a product is transmitted to a remote computer system. The product request data transmitted is electronically formatted in a manner suitable for the system receiving the request. The format of the request data may be received from the vender near the beginning of the transaction, may be retrieved from memory (which was received and stored during a previous transaction with the vender), may be retrieved from memory after being selected by the user, may be selected as a format that is likely to be acceptable for that type of vender, may be supplied by the user, and/or may be retrieved from a database (which may or may not be in the device) such as a service registry or directory that includes formats for the particular vender, the particular type of vender (e.g., a restaurant), the particular product (e.g., an airline ticket from a particular airline), the particular type of product (e.g., food), and/or the location of the vender (e.g., the country).

As discussed, the commerce module 135 exchanges payment data to facilitate payment of the product. In doing so, the commerce module selects a payment account that is acceptable to the vender. Data indicating the types of payment accounts that are acceptable to the vender may be received from the vender near the beginning of the transaction, may be retrieved from memory (which was received and stored during a previous transaction with the vender), may be retrieved from memory after being selected by the user, may be selected as a payment account that is likely to be acceptable for that type of vender, may be supplied by the user, and/or may be retrieved from a database, a service registry, or other source that includes data of acceptable payment accounts for the particular vender, the particular type of vender (e.g., a restaurant), the particular product (e.g., an airline ticket from a particular airline), the particular type of product (e.g., food), and/or the location of the vender (e.g., the country).

In addition, the commerce module 135 preferably selects the payment account in an intelligent manner and that is the most financially advantageous selection for the user such as, for example, selecting the credit card with the lowest interest rate. In addition, the commerce module 135 preferably selects the payment account based on 1) whether the purchase is for business or personal purposes (which may be determined by user input or based on the identity of the vender); 2) whether the assets or credit is available to make the purchase; and/or 3) according to predetermined user preferences supplied by the user.

The commerce module 135 also formats the payment information data in a manner that is appropriate for the receiving computer system. For example, when communicating with an Internet site, credit card data may be included as the values in the variable value pairs for the credit card number, expiration date, name, etc. Other systems may require the data be received in a different format. The format of the payment data is preferably retrieved from memory, (which was received and stored during a previous transaction with the vender), may be provided to the device 101 during the transaction, and/or may be retrieved from a database (e.g., which may or may not be in the device) that includes format data for the particular vender, the particular type of vender (e.g., an interne web site), the particular product (e.g., an airline ticket from a particular airline), the particular type of product (e.g., food), and/or the location of the vender (e.g., the country), and/or may be supplied through the use of Web services. As discussed above, the descriptor found in a service registry may be requested and received to provide the format and protocol data and services data for a particular service provider.

Next, the payment information is transmitted to the desired destination. If requested or necessary for the system, an acknowledgement, confirmation, or other data may be transmitted by the remote system and received by the device 101 according to the protocol of the external system. The device 101 receives the acknowledgement or confirmation of satisfactory completion of the transaction and provides the user with a visual and/or audible indication of the success of the transaction. For example, upon completion of the satisfactory exchange of payment information with a hotel vender, the device 101 audibly produces and displays the words “Check in to hotel complete. Entry code for room 1524 is 123456.” Alternately or in addition, the device 101 transmits the indication to the automobile in which the user is riding for display on the vehicle\'s heads up display. Information indicating the success or failure of the transaction, as well as information resulting from the transaction (e.g., an entry code, an e-book, information for boarding transportation) is also stored in the memory of the device 101 for later retrieval and use.

In one example embodiment, when the commerce module 135 executes a commercial transaction, payment information is transmitted to a remote computer system (e.g., the vender\'s computer system). The remote computer system transmits this information as part of a transaction request to the user\'s account institution card (e.g., the user\'s bank) or an acquirer (e.g., in the case of a credit card). As is known in the art, an acquirer is an organization that collects credit-authentication requests from merchants and provides the merchants with a payment guarantee. If the request is to a bank account (or similar account), the remote computer system receives an approval code, which authorizes the transaction, and an electronic fund transfer is performed to a designated account (e.g., a vender\'s account or the user\'s account in the case of a cash withdrawal). Alternately, if approved for a purchase (e.g., in the case of a credit card transaction), the remote computer system receives an approval code and an ACH (automated clearing house) transfer of funds is performed to the vender\'s bank account, typically on the next business day.

The data management module 120 performs various administrative tasks including memory management, perform memory back-ups, and defragment memory. Because the device 101 is portable, and preferably carried on the user\'s body, it is preferable to keep the size of the device 101 relatively small. As a result, there is limited space for components including memory. The data management module manages the data to make optimal use of the available memory and to reduce the likelihood that other modules and applications do not run out of memory. For example, the storage of video is a relatively memory intensive task and will, therefore, use up large amounts memory and use memory more quickly that other tasks (such as, for example, storing a typical text file).

To ensure that memory is available to modules and applications, the data management module transmits data stored in the device 101—or being stored in the device 101—to a remote storage device. The remote storage device might be a third party remote computer, the user\'s home computer, a storage device in the user\'s automobile, the automobile of another person the user is riding, a mass transmit vehicle (airplane, bus, etc.), and/or a separate storage device carried by the user.

The data management module is preferably implemented to begin storing data remotely when the remaining available (unused) memory reaches a minimum threshold, such as when, for example, only twenty percent of the memory or one gigabyte remains available. When the minimum threshold is available, the device 101 selects the data to be stored remotely. The selection may be based on a number of factors including the size of the data file. Transmitting larger data files reduces the number of files that need be transmitted. In addition, the activity of the data is another factor. For example, it may be undesirable to remotely store a file that the user accesses often or has recently accessed (e.g., a text file) or that an application or module accesses often or has recently accessed (e.g., an address book data file). Thus, the length of time since the data has been used is another factor for determining whether it should be stored remotely. In addition, the data management will also transmit data for remote storage according to predetermined data storage criteria. For example, the user and/or manufacturer of the device 101 may store data storage rules that are based on the type of the data. One example of a data storage rule is to always remotely store video data not accessed within the past seven days before any other type of data. When no such video data is present in memory, these example rules then dictate that the data management module remotely store audio data not accessed with the past seven days before any other type of remaining data. In addition, the user or manufacture can designate select data for storage locally. In summary, what data is stored is dependent on data storage rules that may be user or manufactured stored rules and based on data type, the source of the data, the location of the user, the time of day, the day of the week, the purpose of the data, the activity of the data, and/or other factors. The rules may also be received and stored from a third party or remote source.

The data management module 120 also manages where the data is to be remotely stored. For example, some data (e.g., word processing files) might be stored at the user\'s work computer system, while MP3 files are stored on the user\'s home entertainment system, or the user\'s automobile computer system. Thus, where the data management module 120 stores the data is also dependent on data storage rules that may include user or manufactured stored rules based on data type, the location of the user, the direction the user is going, anticipation that the user will be at location at a later time (e.g., that the user will be out of transmission range a few minutes hence), recent activities of the user, an external event (e.g., turning off the automobile engine), the intended destination of the user, the source of the data, the time of day, the day of the week, the purpose of the data, and/or other factors.

Preferably, the data management module 120 works transparently to ensure memory is available. However, if data storage rules are not present or are ambiguous to the data type or situation, or in other circumstances, the data management module 120 may prompt the user to provide an input indicating whether (or what) data should be remotely stored and/or where the data should be stored. The data is stored and retrieved in a conventional manner, such as a manner used by a server or other storage device for use by multiple users, and the mechanics of the data storage and retrieval are therefore not repeated here.

If the user elects to retrieve the remotely stored data, the device 101 will automatically establish a communication link by means determined by the data management module 120 (if necessary), and transmit a request to the remote storage device that identifies the file as is well known in the art.

The data management module 120 may establish a first type of communication link to store data and a second type of communication link to retrieve data. For example, when the user is in the automobile and the data management module 120 determines that remote storage is necessary, the data management module 120 can establish a wireless PAN link to store data in the automobile (e.g., of the bus the user is riding, or in the user\'s automobile) and stores information for communicating with the automobile (e.g., a network address or telephone number) locally. Later, when the user wishes to retrieve the data, the data management module 120 retrieves information for communicating with the automobile from memory, establishes a wireless data link (e.g., by calling the telephone number of the computer system of the automobile or bus), and retrieves the data.

It also intended that the remote computer system receiving the data have a data management module of its own to manage memory, perform back ups, defragment memory, and perform other management tasks.

There may also be circumstances in which the device 101 cannot establish a communication link with a primary remote storage system because the device 101 is physically located out of transmission range, due to interference, a component failure, transmission restrictions, or other reason. Such circumstances may occur, for example, when the user is on an airplane, a subway, or at sea. If the device 101 cannot establish a communication link with a primary remote storage device, the device 101 identifies a secondary storage device. Identification may be accomplished by retrieving the necessary information from a database, by transmitting a request for an acknowledgement from any available storage devices, by entering an area serviced by the storage device (e.g., which transmits its storage device information upon entering the area or intercepting transmission from the device), by transmitting a request to a network server or master, or any other suitable means.

Once the secondary storage device is identified and a communication link established, the device 101 remotely stores data in the secondary remote storage device according to the techniques previously described. In addition, the device 101 may transmit data (which might include a telephone number, an internet address, a network address and ID, and/or other data) that is sufficient to allow the secondary storage device to transmit the stored data to another remote storage device, which is preferably the primary storage device. The data transmitted to the secondary storage device may also include data of instructions to transmit the stored data to the primary storage device immediately, after a time delay, or after occurrence of an event (e.g., when the secondary remote storage device is able to establish a communication with the primary remote storage device). Alternately, the secondary storage device includes preprogrammed instructions relating to when and how the data should be transmitted to the primary storage device. In addition, the device 101 transmits user (or device) information (e.g., a telephone number) that is stored by the secondary storage device and associated with the stored data. The user or (device information) is used by the secondary storage device to identify and retrieve the data if, and when, the user transmits a request to retrieve the data and/or to store the data on the primary remote storage device.

The data management module also participates in the synchronization of multiple remote storage devices and the device. For example, periodically, or upon request by the user, the memory of the user\'s home computer system, home entertainment system (e.g., storing video and audio files), work computer system, automobile(s) computer system, and/or device may be synchronized so that they all the devices, or some subset of the devices, include all the same data files or include all of a subset of the data files (e.g., word processing file, video files, calendar data, address book data, audio files, etc.). The subset may be selected by the user in response to a prompt or retrieved from memory (e.g., according to the user\'s selections stored in the user profile).

In addition to the above tasks, the data management module also manages the memory 160 locally determining where data should be stored. In addition to the conventional memory management processes, the data management module also stores data locally according stored storage criteria that, for example, is based on data types and the types of memory available locally. For example, certain types of memory such as a SmartMedia® card, a CompactFlash® card, a Memory Stick®, a MultiMediaCard®, a DataPlay Disc®, or a SecureDigital® card, is designated by the storage criteria for storage of video data. Preferably, any type of removable memory is designated for storage of video data or another particular data type (or vice versa) and the data management module prompts the user to replace the removable memory when the existing removable memory is full or nearing full capacity. In response to the prompt, the user replaces the removable memory. In addition, prior to a prompt, or in response thereto, the user may indicate that the device 101 should download the data in the removable memory device to a particular remote storage device (e.g., when full or nearing full capacity).

As discussed, the device 101 may include numerous applications. However, the decision to include or not include a particular application module is a design choice. Likewise, the following example embodiments, and their functionality, is not intended to limit the scope of the described embodiments, which will operate with numerous other application modules. Furthermore, the applications, the functions that are intended to be provided, and the systems with which the device 101 is intended to operate/communicate are some of the factors that will determine the composition of the hardware and software for a given embodiment. Thus, various embodiments may include different hardware and software configurations depending on costs, the functions provided, and the systems with which the device 101 is intended to operate/communicate as will be evident to one skilled in the art. Finally, steps disclosed in a given example may be used with other applications illustrated by other example applications in which the steps are not specifically disclosed as will be evident to those skilled in the art.

The modules and other applications described herein often require communicating with external computer systems. One method of communicating with the external system is shown in FIG. 6 and includes the steps of determining the format, protocol, medium for communicating and/or other communication parameters for communicating with external computer system at step 401. Next, the data, which may be a request, a command, an informational transmission, or other transmission, is then formatted for the external system according to the communication parameters at step 405. At step 410, the formatted transmission is transmitted over the transmission medium, and according to the protocol and other communication parameters for the external system. In many instances, the device 101 may receive the initial communication transmission or receive a response from the external system as shown at step 415. At step 420, the incoming transmission is stored and decoded. The decoding includes any processing that is used to convert or change the received data to a form that is usable by, or to provide data for, another application. For example, the decoding may include parsing and storing name value pairs, decompressing the incoming data, decrypting the incoming data, transcoding the incoming data, removing headers and trailers, decimating the incoming data, extrapolating the incoming data, parsing the incoming data, storing data in data structure(s), and/or any other processing that prepares the incoming data for use by another application. Finally, at step 425 the decoded data is provided to another application for processing such as audibly and/or visual production, sorting, removing duplicate data, performing location related processing (e.g., determining the closest), identifying a vender with which to engage in a commercial transaction or transmit a request to, and/or other processing by commercially available software applications or applications described herein.

The device 101, according to one embodiment, allows the user to find a point of interest based on its location and, if desired, other characteristics. One example application employing this capability is for determining the point of interest within an area that is closest and which, if desired, also meets other selection criteria.

Steps for performing this example application are shown in FIG. 4 and include determining a target point of interest (PI) at step 301, determining the available PIs at step 305, determining the closest PI at step 310. In this example, the application also optionally includes the steps of receiving a user input at step 315, communicating with the PI (e.g., based on the user input) at step 320, and informing the user of the results of the communication at step 325.

In addition, after determining the point of interest (in any of the applications), the device 101 can optionally enter into a commercial exchange on behalf of the user, for example, to purchase a product (e.g., step 320).

The device 101 determines the closest point of interest in response to a user request, at a particular time, day, and/or date, in response to a user action (e.g., purchasing a product), in response to the occurrence of an event (e.g., a flat tire, entering a particular area such as a city or hotel lobby, or fuel levels reaching a predetermined depletion threshold) that may or may not be sensed by the device, data stored in memory, at predetermined time intervals, and/or according or based on other parameters or events.

The criteria for the point of interest can include any desirable, and/or exclude any undesirable, characteristic. For example, the point of interest could be a vender for a particular product (e.g., a vender for tires); type of vender (e.g., a gas station or restaurant), subcategory of a vender (e.g., a fast food restaurant); vender with a particular product in stock or available (e.g., automobile part vender with a particular part available,), a restaurant with no wait for a table, or a particular vender (e.g., McDonalds®). In addition, the determination of the point of interest in some instances may include minimal selection criteria. For example, the point of interest could simply be determining the closest a public place (e.g., a restroom or park), identifying all the shopping complexes in the given area, or any other place of interest. The “area” may be any area such as a city, county, state, or facility.

In addition, the device 101 can also determine the closest point of interest to another location (e.g., the user\'s destination) or set of locations (which, for example, includes the user\'s intended travel route. Thus, for example, the device 101 can determine the closest shopping complex and the closest McDonalds® restaurant to the shopping complex.

Data presented to the user (e.g., via the display) as a result of the determination may include simply the determined point of interest, a list of determined points of interest, a list with distances to each, a list with travel times to each or other data, and/or any other desirable data.

At step 301, the data of the target point of interest is determined and may be supplied by the user or retrieved from memory based on the circumstances (e.g., location or triggering activity), a product, data present in the user profile, and/or other input. For example, upon sensing that fuel levels have reached a predetermined depletion level, the device 101 determines the closest gas station, which is a type of vender retrieved from memory. Alternately, if the user has entered his or her desire to purchase fuel only from select fuel venders such as Mobil® and Shell® (information of which is stored in the user profile), the device 101 determines the closest of these venders. Likewise, upon receiving a user input of a request (or at a particular time of the day), the device 101 determines the nearest restaurant (type of vender), fast food restaurant (sub-category of vender), or McDonalds® (particular vender) according to the user\'s preferences (i.e., a user input or user profile).

Determining the closest point of interest in the preferred embodiment is accomplished by retrieving data of the available points of interest in the given area from a database at step 305. The database may be stored locally (in the device) or remotely (e.g., in an automobile, a web server, at the user\'s home, etc.) and may, for example be a service registry, a business listing (e.g., an electronic Yellow Pages), a Web site, or other database. The initial determination is preferably limited to a predetermined area or smaller space and may be a search for points of interest having an address that includes a country, state, country, city, zip code, and/or street.

In another embodiment, determining the closest point of interest includes broadcasting a request for a response to points of interest that meet the selection criteria and receiving responses that include points of interest satisfying the selection criteria at step 305. The responses preferably also include location data (which may be the address, a longitude and latitude, or the address), which is used to determine the closest point of interest as is well known in the art at step 310.

After the available points of interests meeting the criteria are determined, the closest point of interest meeting the selection criteria is determined at step 310. This step preferably includes determining the distance (e.g., by traveling the streets and thoroughfares) to the available points of interests meeting the criteria and selecting the available point of interest meeting the criteria with the smallest distance. Alternately, step 310 may include computing the time to travel to the various available points of interests meeting the criteria—which may factor in traffic delays—and selecting the available point of interests meeting the selection criteria to which the user has the shortest travel time.

In addition, the device 101 can find the closest point of interest that meets the first the criteria and then determine whether that point of interest meets second criteria. For example, the software might determine the closest auto parts vender and then query the vender computer system or a third party computer system to determine whether that particular vender offers a particular product and/or has a particular part in stock. Thus, this process includes the steps of determining a first target point of interest satisfying a first criteria, determining whether the first target point of interest satisfies a second criteria, if said first target point of interest does not satisfy said second criteria determining a second target point of interest satisfying the first criteria, determining whether the second target point of interest satisfies the second criteria, and subsequently performing the other steps described herein such as steps 320 and 325.

After determining the closest point of interest meeting the criteria at step 310, the device 101 may optionally (at the selection of the user) provide directions thereto and may request purchase of a product (e.g., placing an order for food) and pay for the product at step 320 (skipping step 315 in this example embodiment). The request may be transmitted as a fax, as an electronic transmission (e.g., to the point of sale) such as an email, an instant message, an HTML transmission (e.g., a Post command with associated variable/value pairs), a voice transmission (e.g., synthesized voice), or any format and protocol suitable to the vender. Preferably, the format, protocol, and services are determined through the use of Web services by retrieving the descriptor document from a service registry and transmitted via a SOAP transmission.

As an example, the user, riding in an automobile, enters a voice command which is received by the device 101 at step 301, and in response, the device 101 determines the closest fast food restaurant performing steps 305 and 310 as described above. The device 101 produces an output (either visually or audibly) identifying the closest fast food restaurant, its location, and estimated driving. The user may then elect to travel to the identified restaurant and provides a voice command indicating that he or she wishes to do so and/or whether he or she needs directions.

In response, the device 101 provides driving instructions to the user, which are displayed on the device 101 or optionally on a heads up display that is projected onto the inside of the windshield of the automobile. As the user approaches an intersection, an arrow is projected onto the windshield by the heads up display to indicate to the driver that the driver should turn left or right. The arrow blinks faster as the driver approaches the intersection and/or changes colors to indicate the closeness of the location at which the driver should turn. In addition or alternately, the device 101 may provide audible directions as are well-known in the art.

In this application, when the device 101 is within a predetermined distance of the place of commerce exchange such as a point of sale, a vender location, a place for delivery of goods, or a place for pick up of goods, the device 101 communicates with a computer system (such as that of the vender computer system) through a wireless link to facilitate the transaction, which includes exchanging the payment information. In addition or instead, the device 101 may enter into the commercial exchange based on input from the user at step 315 such as when the user makes a request to purchase (and which may be irrespective of the distance from the place of commerce exchange).

The type of wireless link may be any link that is suitable for the particular vender and may be retrieved from memory and/or determined or based on information in a service registry. Thus, if the vender accepts fax orders, a telephone communication link for faxing the order may be established. If the vender accepts email, an email transmission is sent. If the vender computer system offers Web services a SOAP transmission is employed to place the order for the product (e.g., the food).

As a result of the communication at step 320 of this example, the user receives the product, the device 101 receives information as the product, and/or the device 101 receives information sufficient to use the product (e.g., an entry code or order number). In addition, as a result of the communication the vender preferably prepares the product for delivery to the user as instructed in the request from the device 101.

For example, in the above scenario, when the user selects a point of interest from those presented, the user then supplies an input to the device 101 as a request to place food order. The food order may be a list of items previously stored in memory that are routinely ordered, which may form part of the user\'s profile, and that is selected from a number of lists associated with that user and that restaurant. In addition, the entire restaurant menu, or a subset thereof, may be stored in memory and retrieved (for example, at the time the user selects the restaurant and prior to being within the predetermined distance) to allow the user to place his or her food order. The lists or menu may be displayed to the user on an automobile display (e.g., on the heads or a in dash flat panel display) and selected by voice commands from the user at step 315.

Items stored in memory may be entered manually (such as predetermined food order lists or the entire menu), may be received and stored each time the user purchases a different combination of items (in the case of a list food items), may be periodically transmitted (in the case of the entire menu) such as when the menu changes, may be downloaded, or any received through other suitable means.

When the device 101 is within a predetermined distance of the restaurant (or when the user supplies information of the request), a communication link between the device 101 and the vender is established (preferably by the device 101) to request purchase of the desired food (the food order) at step 320. As discussed, in addition to placing the food order, the device 101 (employing the commerce module as discussed above) and the vender exchange payment information, which is also retrieved from memory of the device 101. The results of the transaction, which preferably indicate the success of the transaction, are then presented to the user visually or audibly at step 325.

Therefore, instead of entering the restaurant to place the food order or entering a drive through to place a food order—both of which typically result in waiting to pay and waiting for preparation of the food—the food is already prepared and paid for when the user arrives.

In addition, the device 101 may optionally transmit location information to the point of interest during the communication with the point of interest at step 320. This information, or other data, can be used to estimate the arrival time of the user by the vender or device 101 (in which case the data is transmitted to the vender). As a result, the vender can prepare the food (or other product(s)) for the customers so that the product is fresh and in the order in which the customers are likely to arrive instead of the order in which the customers place the food orders, or some combination thereof.

Another example application of an embodiment of the device 101 retrieves and processes data from a plurality of service providers (e.g., venders). Software on the device 101 processes the data received from the plurality of venders, which may include, for example determining whether a product is available, comparing the price of the product offered by the plurality of venders, and other processing of data. The results of the processing may be supplied to the user and/or used as a basis for taking additional action such as purchasing the product from the vender with the lowest price or making a request (e.g., for additional information).

As shown in FIG. 5, this example application of the device 101 includes a computer program and hardware for determining the PI criteria at step 350, determining the available PIs at step 355, determining the available PI that satisfy the criteria at step 360, processing data from the PI at step 365, receiving user input of the processed data at step 370, communicating with a PI at step 375, informing the user of the results of the communication at step 380.

For example, a user may wish to purchase a product for the lowest price. To find the lowest price, the device 101 determines the venders offering the product (or who might offer the product), obtains price information, determines the vender with the lowest price (and has the product available), and transmits a request to purchase the product. In this example the identification of the venders is limited to those venders in a given area (e.g., a city, zip code, street, county, state, or country).

At step 350, the device 101 is provided with product identifying information and processing instructions. For example, the user provides the product identifying information and instructions through a voice input. This includes, for example, the user stating the processing instruction such as “find lowest price” followed by product identifying information such as manufacturer Calloway®, Big Bertha® driver. Other product identifying information may also be supplied such as product numbers, model numbers and other characteristics such as, for example, size(s), color(s), quantity, etc. In addition, other vender criteria may be supplied such as limiting the search to venders in a particular geographical area such as a county, city, shopping complex, state, and/or other area.

In addition or alternately, the product identifying information or other inputs to the device 101 may be received from another source such as image data from a scanner that has scanned a barcode, text, or other image or data from a radio frequency tag. While the data preferably includes product identifying data, it may also include vender identifying data (e.g., interne address, phone number, network address, etc.) as well as data for communicating with the vender (e.g., data that might be found in a descriptor document such as data relating to the format, protocol, and other like data). The image data might instead include the Dunn & Bradstreet or Thomas Registry vender identifying information and a service registry for retrieving data for communicating with the vender.

After the product identifying data and processing instructions are provided to the device 101, the device 101 determines the available venders that can provide the product (in accordance with any other vender criteria supplied) at step 355. In doing so, the program may retrieve data of venders from local memory, a remote computer system, and/or transmit a request for such venders to a public, private, or local (e.g., shopping complex) service registry (e.g., a UDDI implementation).

Determining whether a point of interest satisfies the criteria at step 360 may take one or more steps depending on the criteria, where the necessary information can be obtained, and other factors. For example, if the necessary information is in memory of the device 101, no communication with the PI is necessary. Likewise, if the necessary information is in a service registry, it can be retrieved from the service registry instead of contacting the PI. In some instances, some combination of the memory, a service registry, and information requested from the PI may be required to determine whether the PI satisfies the criteria. In this example, a communication with the PI to obtain some of the information necessary for determining whether the PI satisfies the criteria is performed.

Once the available points of interest (e.g., venders who offer, or who may offer the product and meet other criteria such as location) are determined, the device 101 determines a destination for transmitting a request for the required information (addressing information) and for the format and protocol for communicating with the identified vender computer systems (communication parameters). This information may be transmitted from the service registry computer system in the form of the descriptor document (e.g., a WSDL document). Alternately, all of some of the data may be retrieved from local memory or a remote computer system at which the data was stored during a previous transaction.

Once the addressing and protocol information is determined, the device 101 generates a vender request for the desired action that is based on the product identifying information, the processing instructions, and the vender\'s communication parameters. In other words, the device 101 generates a vender request (which may be different for each vender) by formatting and configuring at least a portion of the processing instructions and/or product identifying information in a format and configuration that the vender\'s computer system can read (e.g., receive, interpret, and/or respond to). In this example, the instruction is to generate a request for a price and the product identifying information is the manufacturer and product model information and, in particular, data representing “manufacturer Calloway®, Big Bertha® driver.”

Each formatted vender request is transmitted to the respective vender computer system according to the vender computer system\'s previously determined addressing, format and protocol information. In addition, the communication link and protocol may be different for each vender computer systems so that some links are via a 3G network and others are through a WLAN. (Note: the protocol information may dictate that a communication link first be established, which might include handshaking and other well-known communication protocol that does not form part of the request.)

The vender computer systems (VCSs) receive and process their respective requests, which in this example includes interpreting the request and searching a database for the price of the identified product. After the price is retrieved or otherwise determined, the price is transmitted to the device, preferably in XML format, to determine whether the vender satisfies the selection criteria at step 365. Other data may also be transmitted such as availability, location data for the vender, taxes on purchase of the product, delivery charges for the product, available times for delivery or receipt (e.g., pick up) of the product, etc.

Some VCSs may not respond. Other VCSs may indicate that they do not have the desired product. Still other VCSs may transmit information indicating they are out of stock of the desired product. Thus, only those VCSs that respond with price of the product and indicating availability of the product (which may simply be indicated by the transmission of the price) are determined to be a PI fully satisfying the criteria at step 360. Other applications of the device 101 may employ other PI criteria (e.g., which may not include availability or price) such as located within a five mile radius, with certain store hours, certain vender, vender type, manufacturer products, with sales, the date, the time, any commercial characteristic(s), and/or any other determinable criteria.

Vender requests may be transmitted sequentially, after which the device 101 waits for a response before sending the next vender request or contemporaneously (vender requests are transmitted to each vender without waiting for responses from the first vender).

The device 101 receives and stores the response from each VCS and processes the data according to the processing instructions. In this example, the device 101 sorts the responses from the venders according to price and displays the data in order of ascending price. The displayed data preferably includes the price, vender identifying information and location information. Additional information may also be displayed such as availability (if the vender was not screened out based on availability), distance information, taxes on purchase of the product, delivery charges for the product, available times for receipt (e.g., pick up) of the product, and other data.

Upon viewing the presented data of one or more responses from the VCSs, the user supplies an input to the device 101 at step 370 that in this example is a command to transmit a request to purchase the product from a particular vender. In response, the device 101 communicates with vender at step 375 using the determined communication parameters and transmits a request to purchase the desired product. Thus, the device 101 transmits product identifying information, which may include a product number, name, model, quantity, size, color, duration (e.g., in the event of a rental), dates (in the case of travel tickets or reservations), and/or other product information. In addition, after receiving a request from the VCS, or at some other point in time (as determined by the protocol and format for the VCS) the device 101 exchanges payment information as described above. At the end of the transaction, the device 101 informs the user of the success of the transaction at step 380, which may take the form of, or additionally include, information of the total amount of the transaction, a delivery/pickup location, a delivery/pickup time, and/or other data.

Alternately, when supplying the initial user input at step 350, the user can input instructions to the device 101 to purchase the product from the vender who returns the lowest price, the lowest total price, lowest price and availability of product, or based on other data received from the vender(s). Given this instruction, the device 101 informs the user of the success of the transaction, but not display the results steps 365 thereby eliminating step 370.

Another similar use of the above-described application is for hotel commerce. For example, the user—who is riding in an automobile or other vehicle—may wish to find the closest hotel meeting a given criteria (e.g., with availability and below a selected price). In response to the user request, the device 101 determines and presents a selection of the closest (e.g., the closest three) hotels that meet the criteria by means described above. The user then selects one of the hotels from which to request further information or to purchase a room rental.

Alternately, the user may already have a reservation with a hotel in which case the user preferably has previously input the destination to the device 101 and when the user (and device 101) is within the predetermined distance of the destination hotel, the device 101 automatically (or after prompting the user for permission to check in) checks the user into the hotel as described below.

To rent a room or accomplish check-in, a communication link between the device 101 and hotel computer system (or a computer system acting on behalf of the hotel) is established by any means described herein. The type of wireless link may be any link that is suitable for the particular hotel and may be retrieved from memory, based on information in a service registry or other source. Thus, if the hotel accepts fax orders, a telephone communication link for faxing the order may be established. If the hotel vender accepts email, an email transmission is sent. If the hotel computer system offers Web services a SOAP transmission is employed to place the order for the product (e.g., the room).

If a reservation was previously made, after the communication link is established, the device 101 transmits user identifying information which includes the user\'s name, a confirmation number (in the case of a reservation), a telephone number, an account number, and/or any other information necessary for check in.

If a reservation was not previously made, room availability is determined and, if there is availability, a request to rent a room is transmitted (which may be transmitted in response to a user input). This request (or the request for availability) includes information about the length of the stay, number of guests, and the type of room requested (e.g., smoking versus non-smoking, the view, etc.).

After the request to rent a room is granted, the payment information is exchanged between the device 101 and the hotel computer system. If a reservation was previously made, the hotel computer system may simply use the payment information (e.g., credit card information) that was supplied when the reservation was made to obtain payment.

After payment information sufficient for check in is supplied to the hotel computer system, the hotel computer system transmits check in information to the device, which includes a room number and entry code. The entry code may be a number manually entered into the door by the user that unlocks the door or may be a multi-digit code that is wirelessly transmitted (preferably along with user or device authenticating data) from the device 101 to unlock the door via a wireless PAN.

In addition to receiving data permitting entry into the room, the hotel computer system transmits information sufficient to allow the device 101 to present options to the user allowing the user to purchase additional products. For example, a room service menu may be transmitted to the device 101 from which the user may place a food order. Other information allows the user, for example, to purchase tickets to shows or other entertainment, order movies, establish credit for gambling, and receive data for obtaining discounts for products or services.

When the user elects to check out, a link is established between the device 101 and the hotel computer system and the device 101 requests check out data, and receives and visually presents the bill to the user for review and approval. After receiving an input indicating approval from the user (e.g., receiving the final total amount of the bill), the device 101 finalizes payment by exchanging payment information (or indicating that previously supplied payment information should be used) and stores the information in memory. Thus, according to one embodiment, the need to stand in line during check in or check out is eliminated.

It will be evident to one skilled in the art that this embodiment, with minor modifications, has numerous other applications including, but not limited to, the reservation and purchase of airline, train, bus, and watercraft tickets; the purchase of tickets to movies and other entertainment (such as sporting events, live plays, concerts, movies), paying tolls, golf tee times and green fees, purchasing fuel, and many other applications.

In addition to the above, the device 101 may also be used to facilitate entry to a facility, event, or area, preorder products for entry; and supply facility or other information to the user at entry; and supply user information to the event computer system.

For example, after purchase of a ticket to a concert, sporting event, or other event, and typically well in advance of the day of the event, the ticket information, including the seat information (if necessary) and a unique entry code is stored in memory of the device. In addition, directions to the event, as well as directions to the user\'s seat may also be received and stored in memory the day of the event, at the time of the purchase, or some other time prior to the event.

When the user is within a predetermined distance of the event, a communication link is established between the device 101 and the event\'s entry-control computer system (ECCS). The device 101 transmits the entry code to the ECCS, which then provides an acknowledgement that the user\'s entry code is valid as well as instructions for the best (or only) entrance the user should enter. To enter the facility, the user must have an entry code and provide an indication to the ECCS that the user has a valid entry code. To provide the indication, the device 101 may simply display the valid entry code along with other authenticating information at the entrance of the facility. The displayed information may be a barcode that is displayed on the device\'s display and which is read with a barcode code reader as the user passes through the entrance.

Alternately, the device 101 simply transmits information of the user, such as the user\'s name, and the user simply shows his or her identification (e.g., driver\'s license) to personnel, or to an image input device connected to the ECCS, as the user enters. In another alternative, the device 101 transmits the entry code along with data that is consistent with data in a barcode on a fixed medium such as a barcode that is on the user\'s identification (e.g., driver\'s license) which is scanned or read by a barcode reader as the user passes through the entryway. In the preferred embodiment, the device 101 transmits the entry code along with user authenticating information such as data of the user\'s fingerprint, iris, voice, face, or other substantially unique physical data. As the user enters, the transmitted user authenticating data is compared with the authenticating data of the person entering the facility (user\'s fingerprint, iris, voice, face, or other substantially unique physical data) to ensure that the person entering the facility is the user authorized to do so (i.e., there is a match of the transmitted data with the data received (scanned) as the person enters).

As another alternate to the preferred embodiment, the user authenticating information may be supplied to the ECCS at the time of the purchase of the tickets so that that there is no need for a communication between the device 101 and the ECCS at the time of entry to facilitate entry (i.e., the person entering need only supply the authenticating data when entering the facility such as, for example, permitting scanning of his or her fingerprint). In still another alternate means, the user\'s authenticating data (e.g., fingerprint data) and name is stored at a third party authenticating computer system which receives the fingerprint data (and user\'s name) from the ECCS and compares it with the stored data to confirm the identity of the user for whom the ticket was purchased.

The user may preorder food or drinks, as described above, and the ECCS determines the location of a food preparation center (e.g., a concession) that is reasonably close to the user\'s seat and, optionally, that can most easily prepare the food by the estimated arrival time (or closest thereto). The identity of the food preparation center and/or its location is then transmitted along with a food menu to the device 101. In response to a food order, the ECCS transmits a time the user should arrive to pick up the food. Thus, such a system can reduce or eliminate waiting to enter the facility, waiting time to receive food, and counterfeit tickets.

In addition, the ECCS transmits a request and, in response, receives user information from devices carried by persons entering the facility, area, or event. The requested and supplied user information may include demographical data or any other desirable information. Similarly, any of the embodiments and applications disclosed herein (such as the fast food and hotel applications) may additionally include transmitting such data about the user from the device 101 to the remote computer system.

Through the use of the communications module, the device 101 may be programmed to communicate information with other person\'s using a device 101 or another remote computer system. For example, upon receiving a user input indicating the user\'s desire to do so, the device 101 is programmed to query all other devices within communication of the device 101 for data, via the PAN transceiver (e.g., Bluetooth® network), via the WLAN transceiver, or within a predetermined distance. The query may be for any desirable data. For example, upon entering a business conference the user may “turn on” the feature and request the device 101 query all other devices for user information such as the information that would be present on a business card. The user may also make the request a selective query so that only data from users or devices meeting a certain criteria is requested and, if received, stored. For example, a user who is a sales representative may desire data from people who work for companies that are more likely to be potential customers and may not want data from other people or people who are already customers or competitors. In response to a request, the other user\'s device 101 transmits the requested data, a portion of the requested data, transmits a response that the request is denied, or does not respond.

Likewise, the user may input response instructions for responding to requests for data (queries) from other user devices 101. For example, the user may not wish to transmit the requested data to devices 101 of users who are employed by companies who sell certain products or who are competitors. In doing so, the device 101 may be programmed to filter out certain requests (e.g., not respond) or respond with a communication indicating that the data request is denied. In addition, the user may elect to transmit only certain data (e.g., an email address but not a phone number), request only certain data, and only to respond if the requesting device 101 supplies certain data.

The communication criteria, which determines whether or not data is desired from the second user by the first user, may be any criteria and may include, for example; 1) user information of the other (second) user (e.g., company name, sex, age, birth date, address, job position, height, weight, ethnicity, income, and other demographical information.); 2) device information of the other user\'s device (e.g., manufacturer or model), whether the other user has a service; 3) product data such as whether the user has any product or a particular product for sale, whether the other user wishes to buy any product or a particular product; 4) user activity data such as interests and hobbies of the other, frequent activities of the other user (e.g., skiing), past activities of the other user (e.g., where they have been), anticipated activities, and/or 5) other characteristics or desires of the other user—hereinafter collectively referred to as communication criteria data.

Communication criteria data (CCD) is entered into the device 101 by users in categories such as user information, user activities, products data, and other data, some of which may form part of the user profile. In addition, communication criteria data includes user activity data stored from the previous activities of the user such as the locations or venders visited and stored (e.g., stored by the location module) and/or information of products (e.g., transportation data) purchased (e.g., stored by the commerce module).

Querying of other user\'s devices may be performed periodically or upon entry to a geographical location (e.g., a room, building, vender, street, etc.), which is indicated by a transmission from an access point at, or within, the geographical location.

Communication may be accomplished with any suitable protocol such as HTTP/IP with predetermined name value pairs used for each category and a standard format for each value in each category. For example, Bdate may be a variable (name) representing the user\'s birthdate, which is paired with data representing the user\'s birthdate in the format of mm/dd/yyyy (e.g., bdate=Feb. 15, 1983). Queries to other devices 101 are preferably transmitted using the same format and submitted and converted to a SQL database by the receiving device 101. A successful query (a search that returns a valid result greater than zero) indicates that the other user has communication criteria data that matches the desired communication criteria data. In addition to the query, the transmission may include information relating to one more actions requested by the user upon a successful query. Alternately, a successful query may simply result in a transmission from the queried device 101 indicating that the query was successful and include information indicating what portion (or which query) was successful. For example, the query might transmit a query for CCD data that the user is over forty years of age and a male or over thirty years of age and a female. In the response, the queried device 101 transmits data indicating that the user is a male over forty years of age (an affirmative response) and may also, at the election of the user, transmit the user\'s age, which in this example is fifty-five. In addition, additional information is sufficient to establish a communication link (e.g., a network address for the successfully queried device) may also be provided. After receiving the communication indicating the query was successful, the requesting device 101 then transmits a request to the queried device. In response, the queried device 101 may transmit the requested or other information, prompt the user to take an action, prompt the user for information, prompt the user for permission to transmit information and/or otherwise respond.

The user of the device 101 can program the device 101 with response instructions (for example in the user profile) that determine how and whether the device 101 responds to queries and different types of requests.

Thus, the first device 101 (or other computer) transmits a request that includes a query for CCD to a second device 101. The request itself may include certain CCD stored in the device 101 or the requested device 101 may respond with a request for CCD of the first device 101. Upon determining that device 101 includes satisfying CCD data, any action may be requested (or requested in a subsequent transmission) (by either device 101) such as requesting data from the user\'s device, transmitting data to the user\'s device, requesting information from the user, and/or requesting a service of the user. For example, at the request of the user, in an emergency a device 101 may transmit a query (and request) to other devices within communication range of the device 101 (e.g., via the WLAN) for a doctor, nurse, or police officer. Thus, only users who are a doctor, nurse, or police officer would be informed of the request by their device, which is preferably identified as an emergency request. The request, in this example, is a request to render assistance and may also include information relating to the location at which assistance is needed. Users of the device 101 can program their devices to respond differently to different requests (and at different times). Thus, the doctor or nurse may elect to program their device 101 to only accept requests that are emergency requests.

Some or all the communication criteria data may also be stored in a correlating computer system when the user enters a geographical area or travels within communication distance of the Area Computer System. The Area Computer System (ACS) may operate and/or communicate via a network associated with a facility (e.g., a shopping mall, a stadium, an entertainment arena) or geographical area (e.g., a MAN, an auction site, etc.)

The ACS receives and stores the communication criteria data, queries, and response instructions for each user device 101. The ACS determines the user devices that have communication criteria data matching each user device query and transmits the data responsive to the queries of each device 101 and in accordance with the response instructions, which may optionally inform the user of the match. Thus, the ACS may retain and provide the communication criteria data to users after the user of the device 101 to which the communication criteria data has left the geographical location or requests the data. The ACS, thus, may also be used to transmit messages (e.g., emails) to all devices (or select devices having certain communication criteria data) that come within transmission range of the ACS.

As an example, as each user enters the area or facility, the user\'s CCD, queries, and response instructions are requested by and transmitted to the ACS. Internally to the ACS, the ACS then compares the CCD with all the previously stored queries of all the earlier arrived users. For each query to which the user\'s CCD satisfies, the ACS processes the user\'s response instructions to determine whether the user wishes to supply the requested data. For those queries to which the user wishes to respond, the ACS stores the requested CCD data in a data file corresponding to each requesting query. Next, the ACS compares the CCD of each earlier arrived user with the user\'s queries to determine the users\' CCD to satisfy the user\'s query. After identifying each match, the ACS processes the response instructions associated with each set of CCD to determine whether the requested data should be supplied. For the requested data that is to be supplied, the ACS stores the CCD data in a data file corresponding to each query for the user. When the user leaves or requests the data file, the data file is transmitted to the device 101.

In addition to exchanging data, the device 101 can take immediate actions based on the data received. For example, based on a first set of CCD meeting a CCD requirement set, the device 101 transmits (if programmed by the user to do so) a request for an appointment (e.g., for a telephone call, a lunch, a meeting, etc.) that may include the time periods that are available to the requesting device\'s user and the length of the desired appointment. In response, the requested device 101 determines whether its user has supplied permission to schedule such appointments and if not, transmits a response denying the request (or does not respond at all). If the device\'s user has provided an input (that is stored in memory) permitting the scheduling of such appointments, and the requesting device\'s information (e.g., its CCD data) satisfies the activity requirement criteria for the activity (i.e., scheduling the appointment), the device 101 selects an appointment time (e.g., such as the earliest) from the available time periods transmitted by the requestor or, if not transmitted, transmits time periods that are available for the requested device\'s user. The requesting device 101 then transmits a confirmation of the appointment if the requested device 101 transmits a time period selected from the time periods transmitted by the requesting device. If the requested device 101 transmits its available time periods, the requesting device 101 selects a time period and transmits information of the selected time period to the requested device 101, which responds with a confirmation of receipt. In addition, the device 101 informs the user that a request has been made and may prompt the user for permission to make any appointment or an appointment for a particular time. Information of the available time periods is preferably determined from data that is stored in memory and used, for example, by a calendar applications program. In addition, it is preferable that the requesting device 101 issues requests to interface software (e.g., in the communications module) that determines availability or other information as opposed to the requesting device 101 being given access to the data itself.

In addition to the above, the communication criteria data stored in the user\'s device 101 and the location of the user may also be used by remote computer systems, for example, to target advertising and provide the user with location relevant information.

One example of such a system employs an ACS designed to coordinate the delivery of advertising and content for the shopping complex. Referring to FIG. 7, the ACS establishes user location information at step 450, determines transmission selection criteria (temporal data, CCD, targeting criteria, etc.) at step 455, and selects and transmits an advertisement at step 460. In addition, in some instances the ACS will receive information relating to the user\'s response (receipt, viewing, presentation, or action in response) to the transmission at step 465 and perform an incentive transaction at step 470.

For example, upon entering a shopping complex (e.g., a mall), the ACS determines location data of the user carrying the device 101. The ACS preferably determines the location (e.g., relative location) of the device 101 by determining which WLAN (or wireless PAN if the PAN includes addressable access points) access point through which the device 101 is communicating. FIG. 2 is schematical representation of a facility 217 such as a shopping complex that includes a plurality of access points 230 that facilitate wireless communication between device 101 and the ACS 301. The connections between the ACS and the access points 230 are not shown and may be wireless or wired (e.g., Ethernet). The dashed lines 235 surrounding each access point 230 represent the communication range of the associated access point 230. In FIG. 2, the five access points with the largest communication ranges 235 are positioned in the parking area adjacent the facility.

The facility 217 includes a plurality of vender store locations 220, each having an entrance 221. In addition, the facility 217 includes a plurality of entrances 222 connected by one or more thoroughfares 223 that the visitors walk through to gain access to the vender store locations 220.

Each access point (AP) 230 of this example has a separate network address so that data received from the user device 101 and provided to the ACS is determined by the ACS to have come from a particular AP 230. Thus, knowing the AP 230 with which the device 101 is communicating, and the range of the AP 230 (if desired or necessary), the ACS can determine the approximate location of the user in the parking area, in a thoroughfare 223, and/or in a vender store location 220. In addition, as the device 101 communicates through a sequence of APs 230, the ACS can determine a plurality of locations for the user and, therefore, determine anticipated location data for the user carrying the device. Anticipated location data may also be determined by determining intended activity (e.g., from CCD), receiving product purchase data from a VCS (indicating the user will be traveling to the vender), and/or receiving past GPS data. Thus, the selection of an advertisement based on location data may be a selection based on the current location data or anticipated location data.

The number, placement, and communication range of the APs 230 are design choices. If more accurate location data is desired, more access points 230, perhaps with smaller communication ranges, may be used. While in this example embodiment, the location data is determined through an access point location method, alternate embodiments may simply request that the device 101 transmit location data that is determined by the device\'s GPS receiver or through other means. In addition, depending on the network and other design factors, the access points may or may not have overlapping communication ranges.

Preferably the ACS bases the selection of the advertisement on location data of the user such as, for example, the current location of the user or the anticipated location of the user, which may relate to what door the user will likely enter, what vender the user will likely travel near or is near.

In addition, the device 101 preferably transmits select CCD to the ACS in response to a request from the ACS. Upon receiving the transmitted CCD from the device 101, the ACS determines a selection of transmission(s), such as advertisement(s), for transmission to the device 101, which may or may not also be selected based on location data. The selection of the advertisement may be based on any category or specific CCD data such as the user information (e.g., the user\'s employer, gender, age, birth date, address, job position, height, weight, ethnicity, income, and/or other demographical information.); device information of the user\'s device 101 (e.g., manufacturer or model); product data (e.g., whether the user has any product or a particular product for sale, the identity of any product the user wishes to sell, whether the user wishes to buy any product or a particular product, the identity of any product the user wishes to buy); user activity data (e.g., whether the user has a particular interest or hobby, frequent activities of the user, past activities of the user (e.g., where they have been), anticipated activities); and/or other characteristics or desires of the other user.

In addition to or instead of being based on the CCD and/or location data, the advertisement may also be selected based on temporal data such as the time (e.g., morning versus afternoon), day (e.g., weekend versus weekday), or date (e.g., a holiday, birthday of the user\'s wife). The temporal data may be received from the device 101 (in response to a request), determined by the ACS, or some combination thereof.

Thus, the ACS selects the advertisements based on location data, temporal data, and/or the CCD, from a plurality of advertisements for numerous venders stored in memory. Each advertisement stored in the ACS preferably includes targeting criteria used for selecting users to which the advertisement or all advertisements for a vender are transmitted. The targeting criteria may include any subset of location data, CCD and/or temporal data, but may also include other data (for example, data that is not available for a particular shopping complex).