Title of Invention: Methods for purchasing of goods and services Abstract: A method for conducting a purchasing agreement for goods and services between a consumer and a merchant through a trusted a third party and using a wireless network includes generating, by the consumer, a first view of the agreement and transmitting the first view of the agreement to the third party, generating, independently by the merchant, a second view of the agreement and transmitting the second view of the agreement to the third party, and receiving, by the third party the consumer view of the agreement and the merchant view of the agreement, verifying identities of the merchant and the consumer and that the details of the independently generated views of the agreements are consistent and taking action to execute the purchasing agreement if the conditions are satisfied. The third party includes a Secure Transaction Server. Detailed Description: Part general_description_paragraphs: Part CROSS-REFERENCE TO RELATED APPLICATIONS: This application is related to, and claims the benefit of priority to, Provisional Application U.S. Ser. No. 60/401,807, entitled METHODS AND APPARATUSES FOR SECURE MULTI-PARTY FINANCIAL TRANSACTIONS (A UNIVERSAL PERVASIVE TRANSACTION FRAMEWORK), by Yannis Labrou, Lusheng Ji, and Jonathan Agre, filed Aug. 8, 2002 in the U.S. Patent and Trademark Office, the contents of which are incorporated herein by reference. This application is related to U.S. Ser. No. 10/458,205, entitled SECURITY FRAMEWORK AND PROTOCOL FOR UNIVERSAL PERVASIVE TRANSACTIONS, by Yannis Labrou, Lusheng Ji, and Jonathan Agre, filed Jun. 11, 2003 in the U.S. Patent and Trademark Office, the contents of which are incorporated herein by reference. This application is related to U.S. patent application Ser. No. 10/628,569, entitled APPARATUSES FOR PURCHASING OF GOODS AND SERVICES, by Yannis Labrou, Lusheng Ji, and Jonathan Agre, filed Jul. 29, 2003 in the U.S. Patent and Trademark Office, the contents of which are incorporated herein by reference. This application is related to U.S. patent application Ser. No. 10/628,583, entitled FRAMEWORK AND SYSTEM FOR PURCHASING OF GOODS AND SERVICES, by Yannis Labrou, Lusheng Ji, and Jonathan Agre, filed Jul. 29, 2003 in the U.S. Patent and Trademark Office, the contents of which are incorporated herein by reference. Part BACKGROUND OF THE INVENTION: 1. Field of the Invention The present invention relates generally to the fields of financial transactions, security and methods for purchasing goods and services, and a framework thereof. More particularly, the present invention relates to a computer-implemented system, methods and processes, and a framework enabling consumers to purchase goods and services, primarily at the locations where the goods and services are offered, more securely, faster and more efficiently than current methods. 2. Description of the Related Art To date, E-commerce (electronic commerce) for consumers (or business-to-consumer, B2C, transactions) is essentially a personal computer-mediated process. The typical consumer that wants to purchase a good or service though an e-commerce transaction (“buying on the web”) has to go through the following steps: Buy or own a personal computer (PC); Be physically present at the computer; Have network access; Turn on the computer; Log on to the computer and/or to the network; Open a web browser; Identify, find and visit the particular website that offers the good or service of interest; Find the correct item or service on that website and then add it to a “shopping cart”; Provide the identity information, which might include signing up or creating an account for doing transactions in the particular website; Enter payment and shipping information (typically a credit card); Receive a proof of purchase for her records; and Wait for the goods to be physically shipped. Assuming the existence of a PC and a network connection, the remainder of the process typically requires 15-20 minutes for an experienced user. The current means and methods for consumer e-commerce transactions are expensive in terms of both money and time, complex, require proximity to a computer terminal, and are only available to a small percentage of consumers with the appropriate levels of experience and technological comfort. Further, consumer e-commerce is basically a mail order system that replicates the “bricks and mortar” presence of a business in the virtual world and does not take advantage of merchants' “bricks and mortar” infrastructure and investment. The current system is particularly vulnerable to fraud since the vast majority of purchases on the web are CNP (Card Not Present) transactions meaning that there is no identity confirmation for these transactions, resulting in fraud costs that are primarily incurred by the merchants. Participating in e-commerce requires a computer-literate end-user and substantial hardware. PC penetration is still very low, especially beyond the “first world” and it is unlikely that a computer-literate user and the “a PC at every household in the world” vision will happen in the next few years. A PC is a general purpose device that can be used for many different tasks, including the task of conducting e-commerce transactions. On the software side, a web browser, the universal client for electronic commerce, is not special purpose software but a client for accessing all kinds of web-based services. Although mobile phones and PDA's can be also used for e-commerce, both follow the same paradigm, essentially bringing the browsing experience to a different device. But the essential elements of the paradigm remain, namely e-commerce is one of the multitudes of functions that can be accessed through a web browser (a universal user interface to the web) and a certain degree of computer literacy is still required, along with a considerable personal financial investment for such a client device. In addition, various other devices including cell phones and personal digital assistants (PDAs) provide e-commerce capabilities. Cell phones are intended for voice communication and despite the enormous success of data messaging (e.g., SMS messaging) attempts to broaden their usage by promoting them as web-browsing clients have failed. Additionally, the slow deployment and adoption of 2.5 G and 3 G equipment and services creates an uncertainty about the future of diversifying the usage of a mobile phone. Still, the penetration rate of mobile phones is very high. PDA's on the other hand, have a low penetration rate and are relatively complex for use by the average person; they remain pretty much the domain of technically savvy users who carry a variety of similar gadgets. Also, their primary function is that of a personal organizer. Even though they have evolved to become very small factor personal computers, the limitations of keyboard and screen size make them georgelewis@example.net. Special protocols such as WAP have been developed to overcome some of these types of limitations, but it has not been widely adopted, and this is not the appropriate delivery mechanism for many consumer services. Another pager/e-mail client device of interest is the BLACKBERRY RIM device and devices similar to it. The evolution of BLACKBERRY device is from a pager/e-mail client device towards a full blown PDA. A BLACKBERRY device is much like a PDA with anywhere wireless connectivity, as opposed to connectivity to location-specific service spots. Smartcards are being deployed as a replacement for traditional credit cards. The deployment includes new smartcard readers that will replace the traditional credit card transaction terminals. Each bank that issues a credit card will issue it's own smartcard, so there is going to be a one to one replacement for existing credit cards. New smartcards will provide all the functions of existing credit cards but will also be used as identity cards so that for example one could log into a corporate network through a machine that is equipped with a smartcard reader. Also, smartcards are intended to be used as digital wallets so a user could “load” digital money (Mondex (mondex.com)) into the smartcard. Smartcards have complex mechanisms that are used to improve security and protect the operations concerning digital money. But, it is unclear how smartcards are more secure than current credit cards. Of course they will be more resistant to counterfeiting but if stolen they can be used by another person; since most of the time a PIN is not required for using the card (e.g., for shopping at a store) and, if a PIN is required, knowledge of the PIN would suffice to use the card. Because a user carries many cards and it would be impractical to remember the PIN for each of them, a PIN is not required when using the card for purchases. A smartcard can store other data, so for example one could use a more advanced identification method in conjunction with a smartcard reader attached to a terminal, e.g., insertion of the smartcard to a terminal invokes a biometric-based authentication application that runs on the terminal (not on the device). Related art includes devices for financial transactions (e.g., credit cards, smartcards, etc.), wireless devices that can be used for financial transactions (e.g., mobile phones, PDA's etc.), methods for the transactions, security frameworks and protocols, purchasing methods and workflows and Point of Sale systems. The following discusses related art involving wireless devices and purchasing. Wireless POS (Point of Sale) Extensions These are systems that effectively extend the cash register (POS). A store employee operates a small terminal that can transmit wirelessly to a base station at a store; the wireless terminal is a credit card reader, so that a consumer can check out (pay) at any location in a store, where the store employee happens to be. These systems have been criticized for being vulnerable to the security problems of the WEP protocol, which is used to provide a secure network connection between the wireless terminal and the base station terminal or POS. Wireless Payment Processing The systems essentially replace the merchant's regular phone line with a wireless link for the purpose of connecting to the financial institution that implements the transaction processing. Systems of this category are regular POS terminals that accepts credit cards (for swiping), like any other POS, but instead of using a regular land-line to connect to the processor of the merchant for authorizing the transaction, the use a wireless mobile phone connection for that purpose. Although this category by itself is not of such great interest, it is often combined with systems and innovations of some of the other discussed types, in order to provide a new kind of POS which is more portable and adaptable. B2C (Business to Consumer) Transactions Using a Mobile Device These are solutions that differ from desktop-based web browsing and shopping (B2C commerce) only in that the hardware client used is a mobile device. A PDA or a mobile phone that has wireless web access is used as a personal computer (similarly to any wired, or wireless, networked desktop or laptop with web access. Such solutions do not substantially differ from conducting e-commerce through a web-browser that accesses the general internet. What is important to note about these systems, is that when they are used for shopping the whole consumer experience and the associated steps and workflows do not differ from desktop-based shopping, Moreover, at the technical level, these systems use the same technologies used for desktop and laptops (for the purposes or shopping), or they rely on the stack of WAP-related protocols. The consumer has to enter payment information as she would in order to pay for something at any other e-commerce site on the web. Systems of this type are differentiated from systems that use mobile phones (described next) but require different workflows and infrastructure, even though the latter often use the WAP-related stack of protocols, because they attempt to speed-up and facilitate the submission of payment information by the user. Mobile Phone-Based Shopping A variety of systems use mobile phones for conducting purchases at physical POS (merchants) and virtual POS (on the web). These systems use the mobile carrier's network to carry the transaction. Single Chip Mobile Phone The customer uses a WAP-enabled mobile phone to make purchases from a participating merchant. The user experience is similar to browsing. Technically, the solution relies on the WAP (Wireless Application Protocol) stack of protocols, including WTLS (Wireless Transport Layer Security), which is similar to SSL (Secure Socket Layer) in intent. Such solutions employ a server-side wallet, which is typically provided by a participating banking institution. When accessing the merchant's virtual store, the user connects to the hosted virtual store (even though she might by physically in the physical store) and interacts with the virtual store in order to accomplish the purchase. This disconnect between physical and virtual store, requires some additional steps in the transaction workflow for making payment or for identifying the store to the user's device for the purposes of browsing (on the device) to the right place (URL and webpage). One of the goals of this approach is to involve all three major principals in the implemented system. The mobile phone manufacturer provides the WAP-enabled phone, the mobile carrier provided the value-add service to the user of using the mobile phone for purchases (also providing the hosted infrastructure and the server-side wallet) and the banking institution is the physical owner and processor of the server-side wallet related transactions. It is important to note that even if the merchant's server (the implementation of the merchant's virtual store) is located at (and perhaps operated by) the merchant's physical location, the transaction is carried by the mobile network. Dual-Chip Mobile Phone This category describes systems similar to the previous one but these mobile phones include a second chip (alongside the SIM card), the WIM (Wireless Identity Module) which can read a plug-in WIM chip. The WIM module (with the inserted WIM chip) is essentially a wallet embedded on the client device (the mobile phone) and provides a single banking account associated with the mobile phone. This approach does not require a server-side wallet, but the remainder of the user transaction and interactions are the same as with single chip mobile phone systems. Dual-chip mobile phones are associated with the technological choice of separating SIM and WIM chip cards and the resulting business model of bank/carrier collaboration, i.e., keeping separate the payment function (via the WIM card controlled by the bank) and the network function (via the SIM card controlled by the network operator). Dual-Slot Mobile Phone Such a system requires a phone that is equipped with a chip and slot for reading a smartcard (or even magnetic strip) based bankcard. The user inserts the card on the phone to authorize transactions using the PIN of the specific card. Such systems use protocols and technologies of mobile phones. The user of course needs to carry the actual credit cards. These systems do not require a server-side wallet in the typical sense. The server-side wallet serves as a temporary repository of the transaction data, prior to execution, but no permanent store of user's account data (or registration of accounts) is required. Mobile Phone as Consumer Identifier In these systems, the mobile phone may not be essential to the transaction. When used for virtual POS transactions (B2C purchasing on the internet) the mobile phone is “reduced” to the mobile's number which is in turn used to uniquely identify the consumer at the participating merchant's site. The remaining part of the transaction might continue without involving the mobile phone, or a callback to the user's mobile phone might be required, followed by the user entering some form of confirmation, such as PIN. Mobile Phone for Physical POS The mobile phone is used partially as a consumer identifier but is essential to the execution of the transaction at a physical POS. Although implementations differ in their workflows, the mobile phone's owner will receive a transaction (some times sent as a SMS) for a physical POS transaction initiated by the merchant, which the consumer will have to authorize by entering a PIN that authorizes processing of the payment at a server-side wallet account. Confirmations (in the form of SMS messages) are sent to both mobile phone and merchant. In these systems, the initialization of the transaction is not automated but it requires the physical exchange of some account identification (e.g., phone number or some other unique ID) between merchant and consumer and keying this ID into the POS or mobile phone, along with other transaction-related information. This category can also be thought of as a sub-class of single chip mobile phone systems. Mobile-Phone Shopping with Direct Merchant-Mobile Phone Interaction Systems discussed above rely on the mobile phone to carry the transaction between customer and merchant, coupled with a physical interaction (at physical POS) between merchant and consumer that exchanges an identifier (and/or associated data) that initialize the transaction. Both the merchant and the consumer use the mobile network to submit (separately) the transaction data to the carrier-operated back-end system that confirms the transaction but there is no direct electronic interaction between POS and consumer. Systems of this category on the other hand, utilize a short-range radio transport, usually wireless, so that the mobile phone can also direct connect to the merchant when the user is at the merchant's location. Such systems usually use a mobile phone equipped with Bluetooth. The transaction itself is still carried by the mobile phone network, but the Bluetooth link is used to transmit the merchant's identification code to the mobile phone, or for the mobile phone to transmit the payment receipt to the merchant. There is another type of system that uses Bluetooth to directly interact with the POS. This is the work of the Mobile Electronic Transactions (mobiletransaction.org) consortium, whose primary members are mobile phone manufacturers. These are dual chip mobile phones with a SIM and a WIM. The WIM can be implemented in software instead of being a separate chip (e.g. a smartcard). The WIM is the (tamper-proof) certificate store and the module that is responsible for the security/transaction-related functions of the mobile phone. Bluetooth is used for a direct link with the physical POS. The phone can also be used over the GSM network for transactions on any web-accessible site. Bluetooth is used for discovery (of the POS) and for the wireless link. The WAP stack of protocols is used (WAP, WTLS, etc.) for the interaction between client (mobile) and server. Beyond that point all the workflows, security and transactions rely on using certificates. A certificate (assuming the existence of a Public Key Infrastructure, or PKI) is associated with a particular/specific banking account owned by the user; a user can have multiple certificates, each associated with a different account. Every time that the user accepts a payment, essentially she uses the certificate as a digital signature for signing the “payment contract” sent by the merchant from the physical POS that she connect to in the store. The Merchant sends that message to the acquirer, who will decrypt (with the help of the certificate authority) and then approve the payment (if all is well) and notify the merchant. The user can receive wirelessly new certificates for new accounts and at the end the user is responsible for managing the (on-the-mobile) database of certificates and the associated certification authorities. In turn the user has to understand and manage these certificates, a PKI has to be in place (including revocation of certificates for defunct accounts) and the user might need separate passwords or PIN's to unlock the certificates and or sign payment contracts with them. The present invention overcomes the above-mentioned, and other, problems associated with the related art. Part SUMMARY OF THE INVENTION: The present invention is directed to a method for conducting a purchasing agreement for goods and services between a consumer and a merchant through a trusted a third party and using a wireless network includes generating, by the consumer, a first view of the agreement and transmitting the first view of the agreement to the third party, generating, independently by the merchant, a second view of the agreement and transmitting the second view of the agreement to the third party, and receiving, by the third party the consumer view of the agreement and the merchant view of the agreement, verifying identities of the merchant and the consumer and that the details of the independently generated views of the agreements are consistent and taking action to execute the purchasing agreement if the conditions are satisfied. The third party includes a Secure Transaction Server. Devices and methods for wireless purchasing of goods and services by consumers are disclosed. The overall system (hereafter referred to as Universal Pervasive Transaction Framework, or UPTF) includes: (a) a variety of consumer or customer devices 102, called Universal Pervasive Transaction Devices 102 (UPTD 102) that are enabled by, and can be deployed within, the UPTF framework, for initiating requests for financial transactions relating to the purchasing of goods and services by consumers (b) a merchant device 104 for making goods and services available to consumers that own and operate the consumer devices 102 at the merchant's location, (c) a security framework and associated protocols for initiating transaction requests from the consumer 102 and merchant devices 104 and deciding the validity of the requests, (d) a system architecture for processing the partial transaction requests and initiating transaction execution with financial institutions, and (e) methods for purchasing various kinds of goods and services with the devices 102, using the transactions, security framework and protocols. Examples of goods and services include physical goods, such as grocery items, clothing, books, gasoline, etc., and services such as purchasing admission to a theater, paying for a toll, paying a fine, etc. Benefits of the present invention over existing methods include: (a) a more secure payment method over existing and currently deployed methods, such as credit cards and smartcards, thus reducing credit card fraud and minimizing merchant's risk of fraudulent transaction, (b) a faster transaction cycle thanks to minimizing the customer's interaction with physical entities of existing Point of Sale systems (POS), i.e., cashier operators and swiping devices, and transaction parallelization, (c) enhanced customer convenience thanks to the ability to use any of multiple payment methods (bank cards, credit cards, etc.) while carrying a single device 102, memorizing a single PIN, and eliminating the signature process, and (d) increased ability to process multiple customer transactions concurrently for merchants. Business models and methods for creating revenue from the deployment of such a system of the present invention are also presented, advocating a fee-per-transaction revenue stream. Additional potential revenue streams include the manufacturing and distribution of the handheld device 102, licensing of the technology and design of the handheld device 102, manufacturing and distribution of the merchant-owned device 104, licensing of the technology and design of the merchant device 104, and providing integration services for Point of Sale systems. These together with other aspects and advantages which will be subsequently apparent, reside in the details of construction and operation as more fully hereinafter described and claimed, reference being had to the accompanying drawings forming a part hereof, wherein like numerals refer to like parts throughout. Part DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS: The present invention is directed to methods for purchasing of goods and services. There are many aspects of the methods for purchasing of goods and services described herein. The present invention presents methods for performing purchasing transactions in pervasive service environments, such as ordering and paying, in physical stores (physical Points Of Sale) by a consumer that uses a mobile device. The invention includes methods for purchasing, involving a consumer operating a universal Pervasive Transaction Device 102 (UPTD 102), a merchant operating a merchant device 104, and third party that verifies purchasing transactions. System Architecture The system architecture of the UPTF of the present invention is shown in FIGS. 1-6, reference to which is made after an overview of the present invention. The present invention includes Universal Pervasive Transaction Devices 102 (UPTD 102s, or UPTD 102 clients), Service Spots, a Secure Transaction Server, and an online payment service (OPS). The Service Spots include one or more Access Points (AP) that provide wireless connectivity to UPTD 102 clients, one or more Merchant Server (MS) or Merchant Transaction Server (MTS 104), and other networking servers, such as a DHCP server, 802.1x authentication server, etc. The Merchant Server is the merchant representative and includes UPTF Purchasing application software that handles the transaction workflow and security protocols, Merchant Retail Application software, which implements the application logic of the merchant's retail applications, and the presentation server, such as a world wide web (WWW) server, which serves the merchant content to the UPTD 102 and allows the consumer (through the UPTD 102) to interact with the Merchant Retail Application for the purposes of selecting what to order and/or purchase. The Secure Transaction Server (STS 106) is responsible for deciding which transaction requests are legitimate and passes them to the payment service of a financial institution (preferably an Online Payment Service, or OPS, but which could also be a bank, a credit card processor, etc.) for further processing. The Online Payment Service, which is an online account service that is run by a financial institution which is an organization that can process financial transaction requests. The following explanation is provide assuming that the financial institution is an online payment account organization such as PAYPAL, but the financial institution could be a bank, financial clearinghouse, or any institution that intermediates access to the banking system. The final function of the STS 106 included in the UPTF of the present invention is to ensure that a transaction request is securely passed to the financial institution for fulfillment. The architecture of the UPTF of the present invention is now explained with reference to FIGS. 1-6. FIG. 1 shows the architecture of a UPTF computer system 100 of the present invention. One consumer device 102 (UPTD, or universal pervasive transaction device, 102), one merchant transaction server (MTS (merchant transaction server) 104, or simply merchant server, MS) 104, a Secure Transaction server 106 and one financial institution 108 are shown in FIG. 1. The mentioned MTS 104 components represent software functionality that is delivered by corresponding software modules. The software modules included in the MTS 104 can be located in different physical locations and computer systems. As shown in FIG. 1, the UPTD 102 communicates directly with the MTS 104. The MTS 104 is coupled to the STS 106 through a network such as the Internet 110. The STS 106 then communicates with the financial institution 108 over a computer network. Referring again to FIG. 1, the MTS 104 includes access points 114, coupled to a network 116 in communication with Router/NAT 118. The MTS 104 also optionally includes a location determination server 120 and optionally includes an authentication server 802.1x 122. Also included in the MTS 104 are Lite HTTP Server 124, DHCP Server 126, UPTF Purchasing Application 128, and Retail Application 130. In the MTS 104, Router/NAT 118, location determination server 120, and authentication server 802.1x 122 are optional components of the MTS 104. FIG. 2 shows a Merchant Transaction Server 104 with all of its components in the same computing device 104 (optional components are omitted for brevity); the computing device 104 is located in the physical store 132. FIG. 3 shows a MTS 104 with only the Access Points and the DHCP server in the same computing device 104 (a local Merchant Transaction Server 105), in the store's physical store 132 location and the remaining MTS 104 components located in another computing device 104 (a remote Merchant Transaction Server 136), located in another physical location 138 which is accessible by the MTS 104 (local) 105 over the internet 110. FIG. 4 shows the MTS 104 as a remote MTS 136 located in a computing device different than that of the MTS 104 as a local MTS 105 but both are physically located in the same physical store location 132 and coupled to each other through pathway. FIG. 5 shows multiple MTS 104 devices connected to the STS 106 and FIG. 6 shows multiple MTS 104 devices deployed in the same physical area (referred to as a hotspot) that covers a large retail area (where stores are available). The merchant devices share Access Points that provide wireless access to the merchant devices, which themselves might be located in the retail area or hosted elsewhere in the network. The device that is hosting the merchant stores also provides a directory 107 of the stores that are accessible via the aforementioned Access Points. Service Spot A more detailed explanation of a Service Spot is now presented. A merchant essentially sets up a service spot in order to provide wireless transaction service access for the Merchant Server (MS) and connectivity to a Secure Transaction Server (STS 106). Specifically, the service spot performs at least the following functions: Operated by an approved merchant Provides a list of services that can be accessed through this service spot Optionally, provides a minimum set of default services that every service spot should provide, such as user account status and balance, execution of transactions that a user conducted off-line, etc. A service spot includes a connection (perhaps even an intermittent one) to the Internet and a wireless extension to it (WLAN, Bluetooth, IR, Zigbee, UWB, etc.). Although IEEE 802.11b WLAN (also known as WiFi) is presented as a wireless connection, any other wireless mechanism supporting similar function could be included n a similar fashion with any other wireless mechanism or for a device 102 that operates by physically connecting into wired networks. The UPTD 102 Next, a description of the UPTD 102 (the device 102) is presented. The UPTD 102 includes the following features and capabilities: 2-way wireless communication capability (preferably IEEE 802.11b (WiFi) or 802.11a); Processor and RAM memory; FLASH memory for storage that is tamper-proof and protected from unauthorized reads; a User Interface; an LCD, such as a touch LCD); buttons; a Microphone; a biometric device 102 such as fingerprint sensor; power provided by a battery, such as a Li-ion battery, or a small solar panel or a combination of both; a credit card size form factor; a small footprint operating system (OS), such as LINUX; and device 102, or software, capable of generating timestamped random number sequences. Secure Storage These characteristics define a feature set of a UPTD 102, and each UPTD 102 is not required to include all of the foregoing features. Such a feature set can be implemented either as a special purpose device 102 (such as the one discussed later in the embodiment), or in a personal digital assistant (PDA), or a mobile phone equipped with some form of local wireless communication (infrared, Bluetooth, WLAN, RF-ID, visual displays, etc.) capabilities. The UPTD 102 performs at least the following functions: Optionally, once turned on, the device 102 requests user authentication, either by the user entering a PIN and/or through a biometric method; another authentication should be requested before authorizing any transaction; Upon authorization the device 102 scans the airwaves for available service spots; The device connects to a service spot the device 102 displays to the user available services (merchants and services that the merchant offers) and the user navigates through the offered services and selects which one to interact with; the device 102 optionally presents to the user only “authenticated” services, that is services offered by an approved and authorized merchant that have been themselves been approved and authenticated; On-board storage for records of the last n transactions; and In a disconnected mode, the ability to cache transactions for completion when a live connection is accessible (service spot acts as a point of access to the network). FIG. 7 shows the general workflow 200 of a consumer's interaction with the merchant 104, through the consumer's UPTD 102. Referring now to FIG. 7, upon initializing the UPTD 102 in the pre-purchasing phase 210, the UPTD 102 performs merchant discover 212 and upon the selection of the user, the UPTD 102 connects to a particular merchant 214. Depending on the type of purchase scenario, the consumer might or might not perform the “Select what to purchase” phase (optional) 216 and proceeds with either a physical goods purchase 218 or a service purchase 220. Each of these phases 218, 220 is subsequently described. Generally, the “select what to purchase” phase 216 is applicable in situations where the consumer has to place some order (such as when ordering at a restaurant, or buying tickets at a movie theater) and is not applicable in a payment at a cash register situations (such as when paying for one's groceries) at a supermarket. FIG. 8 shows the general workflow for a physical goods purchase 218 (such as a Point of Sale, or POS, purchase, or paying the bill at a restaurant). As shown in FIG. 8, after the start 300 of the physical goods purchase 218, merchant verification 302 or merchant verification 306 occurs either prior to or after, respectively, purchase order acquisition 304. Merchant verification 302, 306 could be completely omitted. As shown in FIG. 8, merchant verification 302, 306 is optional in the workflow 218. Merchant Verification may appear either before 302 or after 306 the Purchase Order Acquisition 304, or might be completely omitted. Every path from Start 300 to End 314 is a valid physical goods purchase workflow 218. Each function 300, 302, 304, 306, 308, 310, 312, and 314 in FIG. 8 represents a function in the workflow 218 that is explained in subsequent figures. Each such function may be included in multiple pathways and multiple functions for some of them (e.g., Purchase Order Acquisition 304) are included. FIG. 9 shows the general workflow for a service purchase 220 (such as buying a ticket at a movie theater and using it for admission). The term “service purchase” refers to both the purchase of a “ticket”, or similar item that represents the right to access or use a service and the subsequent surrendering of the ticket for the purpose of service usage. The merchant verification functions 324, 328 are optional in the workflow 220. Merchant Verification may appear either before 324 or after 328 the Purchase Order Acquisition 326, but not appear both before and after, or might be completely omitted. Every path from Start 322 to End 344 is a valid service goods purchase workflow. Each function in FIG. 9 represents a function in the workflow 220 that is explained in further detail in subsequent figures. Each such function may be included in multiple pathways and multiple functions for some of them (e.g., Purchase Order Acquisition 304) are included. Transaction Flows The transaction flows associated with the purchase of virtual goods and physical goods are now discussed in detail. Detailed accounts of the transaction flows can be found in FIGS. 10-28, and refer to FIG. 8 for physical goods and FIG. 9 for virtual goods (or services), respectively. Before a detailed description of FIGS. 10-28 is presented, an overview of transactions for virtual goods and for physical goods is presented. Transaction Flow for Virtual Goods This workflow describes the processing involved when the service being purchased can be represented by a service token (or “virtual” goods). Typical examples of this type of transactions include purchasing a movie ticket, a bus ticket, or paying for parking or a highway toll. The transaction occurs in phases as described in FIGS. 7 and 9 (in more detail). During the pre-purchasing phase, the customer discovers the available merchant in his vicinity browses and identifies the service she wishes to purchase. The details of the latter part of this phase are highly dependent on the type of service/goods to be purchased, the vendor's catalog system implementation, and the capacity of both the service spot type and client device 102. After the customer decides what to purchase, she indicates her intention to the merchant using the merchant specific interface delivered through the MTS 104. After receiving the purchase request, the merchant's MTS 104 invokes the purchasing application that runs on the UPTD (described in detail herein below) and enters the purchasing phase. The MTS 104 communicates with the UPTD 102 by generating a transaction proposal for this new transaction, which is in the form of a formatted purchase order, and sending the proposal back to the UPTD 102. Upon receiving the transaction proposal, the UPTD 102 generates its own view of the transaction as described herein below. This view of the transaction is sent back to the MTS 104. The MTS 104 also computes its own view of the transaction. Both views are sent in the same secure communication session to the STS 106 for verification and authentication. The STS 106 verifies the transaction using the matching rules specified herein below. After local verification that both parties are in good standing and of the legitimacy of the transaction, the STS 106 generates responses for both parties. If any error occurred during the verification and authentication process, an error response is generated for both parties indicating a transaction authorization failure and the corresponding reasons. If the STS approved and eventually executed the transaction, i.e., the transfer of funds from payer (consumer) to payee (merchant), through means described herein below, the consumer's UPTD will also receive data that can be used to gain access to the service purchased or to consume such service. FIGS. 50 to 56, described in detail herein below, elaborate on the consumer's experience during such a service purchase and the execution of the associated workflow by his UPTD. Transaction Flows for Physical Goods The processing functions for transactions involving physical goods exchange are similar to those involving “virtual” goods. The most typical examples are paying for grocery, paying for appliances, etc, situations that generally describe payment at a cashier. The transaction occurs in phases as described in FIGS. 7 and 8 (in more detail). A difference between transactions with physical goods and those without is the association between the goods and the consumer device 102. The problem does not appear in the case of a transaction to purchase a service, because the consumer can select the service to be purchased from his device. In the familiar example of paying for groceries using a charge card, checkout starts when a cashier opens a new virtual shopping cart on his cash register system for the new customer, then adding items to this shopping cart by scanning the items this customer wishes to purchase. Scanned physical goods are then packaged for customer pickup. After the creation of this virtual shopping cart, the cart needs to be associated with the customer's charge account. Such association is created when the customer swipes his/her credit debit membership card. The association can be created at any time after the virtual shopping cart is created. After the cashier finishes scanning all goods, and only after the association is created, the cashier will proceed with checkout payment by presenting the transaction to the customer charge card issuer for authorization. The procedure is similar for using the UPTD 102. However, since the UPTD 102 communicates with the merchant MTS 104 via wireless link instead of a card swiping reader for charge card, there is a possibility of goods not being associated with the right UPTD 102. All the UPTD 102's in the range of the check-out point may be identified and potentially associated with the goods being scanned. Additional mechanisms are provided to prevent the MTS 104 from associating goods with devices 102 other than the customer's. The following is a discussion about a number of methods for creating such an association correctly. The first option is to provide a transaction identification number to the consumer and the merchant devices. At some point prior to the handing over of physical goods, the merchant asks the consumer to present the transaction identification number and if they match, then the goods are handed over. A second option is to include a barcode or a barcode display on the client's UPTD device 102. Barcode is the simplest form of digitally readable identifier and it is almost universally available. Chances are that if a store sells physical goods, it has a barcode system installed for inventory and price check. Given the wide availability of barcode reading system and the maturity of the technology, adding a barcode to the UPTD 102 is the cheapest method to create the association because it does not require any additional hardware installation and maintenance. Also it is among the most reliable methods as well. Using this method, during the checkout process, the cashier may scan the UPTD 102 in order to receive the device 102 ID of the UPTD 102 and create the association between the goods being scanned and the customer's universal pervasive transaction account. Although the client would need to offer the UPTD 102 for scanning, the added action will increase client involvement of the checkout process and reduce the “disconnected-ness” or “not knowing what is going on” feelings of the customer. In addition, scanning of a customer's membership card is a common and well accepted practice in membership-ed retail stores so the level of added inconvenience is georgelewis@example.net. In addition, adding a barcode reader adds security to the UPTD 102. Even though the device 102 ID of the UPTD is public and is “faked”, the transaction will not succeed because of the encryption mechanism used by the STP. The barcode may be generated and displayed on the consumer device. Other methods focus on the “physical proximity” between the client device 102 and the cashier. These methods include using technologies such as Infra Red (IR) or RF ID. In the first case, an IR transmitter is installed on each UPTD 102 and an IR reader is installed at each checkout lane. During checkout, the client needs to line up the IR transmitter with IR reader so the MTS 104 can receive the device 102 ID of the UPTD 102 over the IR communication link. In the second case, an RF ID is installed on each UPTD 102. If the ID is passive, an RF ID reader that uses an RF energy beam to activate the RF ID is required at each checkout lane. Because typically an RF ID has a very small transmission range, it is unlikely that the RF ID reader will pickup an RF ID of a device 102 in neighboring lanes or a different device 102 in the current checkout lane. Other location determination technologies may also be employed for detecting the closest client device 102 from a cashier. Many of these techniques can use the WLAN communication on the devices 102 to perform location determination of the correct client. For example, special checkout lane antennas which can only receive wireless network signals of the client device 102 physically at the checkout counter may be installed to achieve the same level of proximity detection. The proximity of the client's device 102 can also be used as a form of security effectively preventing remote users from easily pretending to be present at a checkout station. The UPTD 102 permits unmanned self-checkout stations, where the customer can, for example drop the items in a basket-like apparatus, so that the items can be immediately identified (perhaps using RF ID's attached to the item) and immediately generate a virtual shopping cart associated with the customer's UPTD 102 for transaction completion. No matter what method is used to create the association, balance is struck between the probability of erroneous associations, the cost of installing and maintaining additional equipments and the convenience and ease of using UPTD 102 for checkout. At the beginning of the next phase, the transaction proposal by the merchant will include a list of items and their prices. Thus before hitting the “pay” button on his device 102, the client still has a chance to conduct a final inspection on the goods he/she is paying for. The pre-authorization phase is identical to the transactions for virtual goods so the details are omitted here. The last “payment” phase is even simpler than that of a virtual good transaction because no token and token certificate is generated. Finally, the association between the shopping cart and the UPTD 102 can occur before or after the items are entered into the cart. In another approach to the problem discussed, the consumer can use their device to “browse” to the virtual location of the cashier station that he is using to check out. This way he will see on his device the total amount of his purchase once the cashier has completed the “virtual” shopping cart and select to pay for it with their device. Although some other consumer might be able to do that too, one would not want to pay for someone else's groceries, so barring impatient consumers waiting in line, each consumer will end up paying for the items he is purchasing. At a high level, the payment phase for a physical goods purchase does not differ from that of a service purchase, although in the case of a physical goods purchase the consumer does not need to present additional data in order to take possession of the purchased goods. Returns, Cancelled Orders and Aborted Transactions The fund transfer does not occur until the STS 106 receives acknowledgements from both client and merchant. Before this occurs, both the client and the merchant can cancel or abort the transaction at any point. Following the acknowledgement, returns are treated as a new transaction. The return transaction can also be realized in this framework, but details are omitted as it should be possible to implement such a system given the following discussion. Details of Transaction Flows FIGS. 10-28 are detailed descriptions of the functions shown in the purchase workflows 218, 220 of FIG. 8 and FIG. 9 respectively. FIGS. 10-28 show the actions of each of the Consumer (using UPTD 102), Merchant (using the Merchant Transaction Server 104) and Secure Transaction Server (STS) 106, and their respective communication (messages and other information exchanged between the involved parties) during the performance of the described workflow (or element). “Consumer” stands for either the consumer's device 102 (consumer UPTF client device 102, or UPTD 102), or the combination of the UPTD 102 and its registered owner's (consumer, the person) interaction with it. The functionality of the UPTD 102 can be included in a standalone device or as part of a mobile phone or personal digital assistant (PDA). Similarly, “Merchant” stands for either the merchant's device 104 (merchant UPTF device 104, or MTS 104), or the combination of the MTS 104 and its registered owner's (merchant, the person, or its representatives) interaction with it. All messages from the consumer to the STS and the STS's responses to the consumer, even if such messages are forwarded to the STS by the merchant (or to the consumer, by the merchant) are encrypted according to the Security Agreement Submission (SAS) protocol, which is also referred to as the Secure Transaction Protocol (STP) or Secure Pervasive Transaction Protocol (SPTP) described) herein after. The SAS protocol is described in U.S. patent application Ser. No. 10/458,205, the contents of which are incorporated herein by reference, and, as related to the present invention, is discussed herein below with reference to FIGS. 57-63. The STP refers to the SAS adapted for purchase transactions as described in this invention. Similarly, all messages from the merchant to the STS and the STS's responses to the merchant are encrypted according to the Secure Transaction Protocol (STP described) herein after. According to the STP, messages from either the consumer or the merchant to the STS include an encrypted part that can only be decrypted by the STS, which has access to all the necessary information for deciding the key that was used by the consumer (or the message) in order to encrypt the encrypted part of the message. As a result, even if the consumer's message to the STS is delivered by the merchant to the STS, the merchant is unable to read the encrypted part of the consumer's message to the STS, or to alter it in such a way that the STS will still believe that the message originated from the consumer. Similarly, when the STS sends a response to the consumer, that message to the consumer contains and encrypted part, that is encrypted with a key that is unique to that consumer. Only that consumer has all the information needed to reproduce that key and use it to decrypt the encrypted part of that message. Even if the STS's message to the consumer is delivered through the merchant the merchant will be unable to read or alter the encrypted part of the message in such a way that the consumer can be deceived about the response of the STS. The following discussion with respect to FIGS. 10-28 applies to both a physical goods purchase 218 shown in FIG. 8 and a service purchase 220 shown in FIG. 9. That is, in FIGS. 10-28, merchant verification refers to merchant verification 302, 306, 324, and 328; purchase order acquisition refers to purchase order acquisition 304 and 326; REQuest and AUTHorization refers to REQuest and AUTHorization 308 and 330; REQuest refers to REQuest 310 and 332; and AUTHorization refers to AUTHorization 312 and 334. FIG. 10 shows a method 350 for Purchase Order Acquisition, referred to as Direct Purchase Order Exchange. “Purchase Order Acquisition” is
{'bibliographic_information': "{'country': 'US', 'doc-number': '10628584', 'kind': 'B2', 'date': '20030729', 'extension': '519', 'invention_title': 'Methods for purchasing of goods and services'}", 'source_file': './grant/2008/ipg080325.xml', 'source_data': 'USPTO-Grant'}