METHOD FOR A SHIPPER-BASED ELECTRONIC/PHYSICAL MAIL ADDRESS DATABASE ARCHITECTURE

Abstract: A method is provided for shipping goods (400). First, an electronic mail address is retrieved from a parcel (402). Such electronic mail address is capable of being used to transmit information over a network (402). Next, a database is queried using the retrieved electronic mail address (404). The database includes a plurality of electronic mail addresses and associated physical mail addresses (404). Thereafter, the physical mail address associated with the received electronic mail address is retrieved from the database in response to the query (406). The parcel is then shipped to the physical mail address (408).

Description: METHOD FOR A SHIPPER-BASED ELECTRONIC/PHYSICAL MAIL ADDRESS DATABASE ARCHITECTURE FIELD OF THE INVENTION The present invention relates to shipping parcels, and more particularly to shipping parcels purchased in an e-Commerce environment. BACKGROUND OF THE INVENTION The concept of shipping parcels from one person to another has spawned a plethora of common carriers and parcel delivery companies that will pickup a package from one address and, for a fee, deliver it to a second address. These service-oriented companies are often referred to as "couriers". As one might expect, various couriers around the world offer a wide array of shipping services at varying prices. The shipment of parcels has experienced a large amount of growth due to the large amounts of activity on the Internet. E-Commerce has supported this growth by providing access to many goods and services from the privacy of the buyer's home. Such network environment, however, is coupled with privacy and security issues. These concerns are shared by sellers and buyers alike. For example, buyer are often wary of providing personal information over the Internet. Further, retailers are wary of the information provided by the buyers. There is thus a need for a system that addresses these concerns and affords a new system of shipping parcels. SUMMARY OF THE INVENTION A method is provided for shipping goods. First, an electronic mail address is retrieved from a parcel. Such electronic mail address is capable of being used to transmit information over a network. Next, a database is queried using the retrieved electronic mail address. The database includes a plurality of electronic mail addresses and associated physical mail addresses. Thereafter, the physical mail address associated with the received electronic mail address is received from the database in response to the query. The parcel may then be marked with the physical mail address and shipped thereto. In one embodiment, the network is the Internet, and the electronic mail address includes a user name, a first level domain name, and a second level domain name. Further, the electronic mail address may be type written on the parcel, and may be scanned from the parcel. In another embodiment, the database may be formed by the registration of a plurality of users. Further, the electronic mail address may be hosted by an entity which ships the parcel. As an option, the database may be queried via the network. BRIEF DESCRIPTION OF THE DRAWINGS The invention will be better understood when consideration is given to the following detailed description thereof. Such description makes reference to the annexed drawings wherein: Figure 1 is a schematic diagram of a network implementation of one embodiment of the present invention; Figure 2 is a schematic diagram of a hardware implementation of one embodiment of the present invention; Figure 3 is a flow diagram illustrating a method of registering users in a database in accordance with one embodiment of the present invention; Figure 4 is a flow diagram a shipper-based electronic/physical mail address database architecture in accordance with one embodiment of the present invention; Figure 5 is a flow diagram illustrating a method of handling a change of address in a database in accordance with one embodiment of the present invention; Figure 6 is a cut away view of the scanner pen showing the working parts at a first point during a scan of a text set; Figure 7 is the same cut away view of the scanner pen showing the scan at a later part of the scan of text characters; Figure 8 is a cut away view of the scanner pen form a view taken at approximately 90 degrees from that shown in Figure 6 and Figure 7; Figure 9 shows an alternate manner of coupling a leading (trailing) text element to the first element of the scan array or to a separate single detector element; Figure 10 shows yet another method of bringing the scanned text and the leading text element to a single discrete detector or to the first element of the scanning array; Figure 11 is a flow diagram illustrating a retail-based transaction using a database in accordance with one embodiment of the present invention; Figure 12 is a flow diagram illustrating a buyer-based transaction using a database in accordance with one embodiment of the present invention; Figure 13 is a schematic diagram of a system of enabling secure electronic payments over an unsecured network according to a preferred embodiment of the invention; Figure 14 is a flow diagram illustrating method of verifying an age of a buyer during an e- Commerce transaction using a database in accordance with one embodiment of the present invention; Figure 15 is a flow diagram illustrating an electronic mail address validation scheme during an e- Commerce transaction using a database in accordance with one embodiment of the present invention; Figure 16 is a flow diagram for an electronic delivery confirmation using a database in accordance with one embodiment of the present invention; Figure 17 is a flow diagram for an escrow function using a database in accordance with one embodiment of the present invention; ' Figure 18 is a block diagram schematically showing the structure of an electronic mail system according to an embodiment of the invention; Figure 19 is a diagram showing the arcangement of data in a mail; Figure 20 is a flowchart schematically showing processing performed by an electronic mail terminal utility; Figure 21 is a flowchart schematically showing processing performed by an electronic mail terminal utility; Figure 22 is a flowchart showing the details of the attachment file register processing of Figure 20; Figure 23 is a flowchart showing the details of the attachment file analysis processing of Figure 21; Figure 24 is a diagram showing one example of the contents of a folder table; Figure 25 is a flowchart showing the details of the condition defining processing of Figure 21; and Figure 26 is a flowchart illustrating a method for selective advertising using the mailing system of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Figure 1 is a schematic diagram of a network implementation of one embodiment of the present invention. As shown, a database 100 is established which has a plurality of a physical mail addresses each of which has an associated electronic mail address. The physical mail addresses may include a name, street address, city and zip code. Further, the electronic mail address includes a user name, first level domain name, and second level domain, i.e. johndoe@usps.gov, etc. Connected to the database 100 is a plurality of postal service centers, or shippers, 102 each of which is capable of accessing the database 100. Such connection may be established using a network, i.e. LAN, WAN, wireless, the Internet, etc. It should be noted that the shippers may include any business or government entity which is capable of shipping parcels, goods, etc. to physical mail addresses. In operation, the electronic mail addresses maybe written, stamped, typed, encoded, or otherwise applied to parcels, and the shippers 102 are capable of accessing the database 100 to enter the electronic mail addresses for the purpose of retrieving the associated physical mail addresses. By this design, the shippers 102 are adapted to ship parcels without requiring the physical mail address to be situated on the parcel. This provides privacy, security, and enables numerous services which will be set forth hereinafter in greater detail. In one embodiment, access to the database 100 may also be gained via the Internet 104 which is connected thereto. As an option, a server 103 may act as an interface to the database, as shown in Figure 1. This allows retailers 106 and buyers 108 to access services rendered by the server 103. For example, the server may provide electronic mailing, or various other services during business transactions over the Intemet including, but not limited to e-mail shopping, e-mail shipping, and age verification. Email shopping may be facilitated by providing the ability to purchase goods over the internet with only an email address as one's identification. The email address may provide consumer protection in that physical mail addresses does not have to be provided over the internet. A digital wallet may be used for payment, thus eliminating the need to provide credit card information or personal address information over the internet. A much higher level of consumer protection is thus afforded. In particular, the consumeήpurchaser may provide their registered email address with a valid digital certificate to an on-line retailer or party with which they wish to do business. The retailer could request validation of the consumer's digital certificate in order to authenticate the certificate. The consumer would then select their items for purchase and the consumer would initiate the purchase transaction. Payment can be made by providing the retailer either with or without specific personal payment information. In the case of providing personal payment information, the consumer may provide a credit card, checking account or other personal or business account information. In the other methods the consumer may provide the retailer with an alias account number, digital wallet account, smart card, reference number or any other initiation method that is independent of the consumer's personal financial account information. Upon the retailer receiving validation that the consumer is credit worthy, the transaction may be completed. The retailer or retailer's agent may apply an email shipping address to the outbound ■ parcel. The shipper delivers the parcel to the buyer's physical mail address location. On a website that deals with auctioning where the buyer and/or seller may not be reputable, there may be an escrow function where the payment is not released until the buyer has received the merchandise through a delivery confirmation process. It should be noted that the retailer can be any party that sells or bills for goods or services over the internet. The consumer may be anyone that purchases goods over the internet. Email shipping involves the ability to ship a parcel or letter with an email address and translate the email address to a physical mail address for residential or commercial delivery. In operation, parcelsMetters are taken to a consolidator point(s) where a shipper may look up the email address and associate it with physical mail address location. At that point, print a label that is applied to the parcelMetter that permits the letter carrierVparcel delivery person to deliver to a physical mail address. The key to making this happen is that there is a database or relationship between a physical mail address and an email address that permits the translation of a email address to a physical mail address. The other component that is important is that the email address is from a registered email users that will permit the validation as to the accuracy of the email address. As an optional feature, the capability to send an email as part of the delivery confirmation process could be accomplished since there is an email address attached to a physical mail address. When the translation from an email address to a physical mail address occurs, the email address could be assigned to the delivery confirmation number. From that point forward, every time the confirmation of a parcel is scanned an email address could be sent to the shipper notifying the shipper of the movement of the parcel. Age verification on the internet is accomplished by associating a name and age to a digital certificate. To get a registered email address an individual may show one or two forms of valid identification and be assigned a Certificate Authority based on whether they are 18, 19, 20 or 21 and older. They can then purchase items over the internet that are age restricted. When a site requires an age check of the individual, it may check the digital certificate authority. When applying for an email address, the person requesting the email address may show a proof of age and would be assigned an email address with the age or birth date associated with the certificate authority. A birth date or age may then be associated with a digital certificate authority or in a database with a digital certificate authority. In use, when a person goes to a site to purchase or view items that require an age check, the vendor of that site may access that person' s Digital Certificate Authority for proof of age. After the age has been verified the individual may be able to then access age sensitive information on the site. Perhaps more important that permitting the purchase of items is the fact that it would not allow minors to view this type of information. The present technique maybe used during access to adult sites, R rated movie trailers, Tobacco, Alcohol, Firearms, Financial transactions where age is important In order for the retailers 106, buyers 108, and postal centers 102 of Figure 1 to access the foregoing services that may be rendered by the information stored in database, computers may be employed such as an IBM compatible personal computer, Apple Macintosh computer or UNIX based workstation. A representative computer is depicted in Figure 2, which illustrates a typical hardware configuration of a workstation in accordance with a preferred embodiment having a central processing unit 210, such as a microprocessor, and a number of other units interconnected via a system bus 212. The workstation shown in Figure 2 includes a Random Access Memory (RAM) 214, Read Only Memory (ROM) 216, an I/O adapter 218 for connecting peripheral devices such as disk storage units 220 to the bus 212, a user interface adapter 222 for connecting a keyboard 224, a mouse 226, a speaker 228, a microphone 232, and/or other user interface devices such as a touch screen (not shown) to the bus 112, communication adapter 234 for connecting the workstation to a communication network (e.g., a data processing network) and a display adapter 236 for connecting the bus 212 to a display device 238. The workstation typically has resident thereon an operating system such as the Microsoft Windows NT or Windows/95 Operating System (OS), the IBM OS/2 operating system, the MAC OS, or UNIX operating system. Those skilled in the art will appreciate that the present invention may also be implemented on platforms and operating systems other than those mentioned. The software for implementing the functionality set forth herein may be written using JAVA, C, and the C++ language and utilizes object oriented programming methodology. Object oriented programming (OOP) has become increasingly used to develop complex applications. As OOP moves toward the mainstream of software design and development, various software solutions require adaptation to make use of the benefits of OOP. A need exists for these principles of OOP to be applied to a messaging interface of an electronic messaging system such that a set of OOP classes and objects for the messaging interface can be provided. OOP is a process of developing computer software using objects, including the steps of analyzing the problem, designing the system, and constructing the program. An object is a software package that contains both data and a collection of related structures and procedures. Since it contains both data and a collection of structures and procedures, it can be visualized as a self-sufficient component that does not require other additional structures, procedures or data to perform its specific task. OOP, therefore, views a computer program as a collection of largely autonomous components, called objects, each of which is responsible for a specific task. This concept of packaging data, structures, and procedures together in one component or module is called encapsulation. In general, OOP components are reusable software modules which present an interface that conforms to an object model and which are accessed at run-time through a component integration architecture. A component integration architecture is a set of architecture mechanisms which allow software modules in different process spaces to utilize each others capabilities or functions. This is generally done by assuming a common component object model on which to build the architecture. It is worthwhile to differentiate between an object and a class of objects at this point. An object is a single instance of the class of objects, which is often just called a class. A class of objects can be viewed as a blueprint, from which many objects can be formed. OOP allows the programmer to create an object that is a part of another object. For example, the object representing a piston engine is said to have a composition-relationship with the object representing a piston, hi reality, a piston engine comprises a piston, valves and many other components; the fact that a piston is an element of a piston engine can be logically and semantically represented in OOP by two objects. OOP also allows creation of an object that "depends from" another object. If there are two objects, one representing a piston engine and the other representing a piston engine wherein the piston is made of ceramic, then the relationship between the two objects is not that of composition. A ceramic piston engine does not make up a piston engine. Rather it is merely one kind of piston engine that has one more limitation than the piston engine; its piston is made of ceramic. In this case, the object representing the ceramic piston engine is called a derived object, and it inherits all of the aspects of the object representing the piston engine and adds further limitation or detail to it. The object representing the ceramic piston engine "depends from" the object representing the piston engine. The relationship between these objects is called inheritance. When the object or class representing the ceramic piston engine inherits all of the aspects of the objects representing the piston engine, it inherits the thermal characteristics of a standard piston defined in the piston engine class. However, the ceramic piston engine object overrides these ceramic specific thermal characteristics, which are typically different from those associated with a metal piston. It skips over the original and uses new functions related to ceramic pistons. Different kinds of piston engines have different characteristics, but may have the same underlying functions associated with it (e.g., how many pistons in the engine, ignition sequences, lubrication, etc.). To access each of these functions in any piston engine object, a programmer would call the same functions with the same names, but each type of piston engine may have different/overriding implementations of functions behind the same name. This ability to hide different implementations of a function behind the same name is called polymorphism and it greatly simplifies communication among objects. With the concepts of composition-relationship, encapsulation, inheritance and polymorphism, an object can represent just about anything in the real world. In fact, one's logical perception of the reality is the only limit on determining the kinds of things that can become objects in object- oriented software. Some typical categories are as follows: • Objects can represent physical objects, such as automobiles in a traffic-flow simulation, electrical components in a circuit-design program, countries in an economics model, or aircraft in an air-traffic-control system. • Objects can represent elements of the computer-user environment such as windows, menus or graphics objects. • An object can represent an inventory, such as a personnel file or a table of the latitudes and longitudes of cities. • An object can represent user-defined data types such as time, angles, and complex numbers, or points on the plane. With this enoπnous capability of an object to represent just about any logically separable matters, OOP allows the software developer to design and implement a computer program that is a model of some aspects of reality, whether that reality is a physical entity, a process, a system, or a composition of matter. Since the object can represent anything, the software developer can create an object which can be used as a component in a larger software project in the future. If 90% of a new OOP software program consists of proven, existing components made from preexisting reusable objects, then only the remaining 10% of the new software project has to be written and tested from scratch. Since 90% already came from an inventory of extensively tested reusable objects, the potential domain from which an error could originate is 10% of the program. As a result, OOP enables software developers to build objects out of other, previously built objects. This process closely resembles complex machinery being built out of assemblies and sub- assemblies. OOP technology, therefore, makes software engineering more like hardware engineering in that software is built from existing components, which are available to the developer as objects. All this adds up to an improved quality of the software as well as an increased speed of its development. Programming languages are beginning to fully support the OOP principles, such as encapsulation, inheritance, polymorphism, and composition-relationship. With the advent of the C++ language, many commercial software developers have embraced OOP. C++ is an OOP language that offers a fast, machine-executable code. Furthemiore, C++ is suitable for both commercial-application and systems-programming projects. For now, C++ appears to be the most popular choice among many OOP programmers, but there is a host of other OOP languages, such as Smalltalk, Common Lisp Object System (CLOS), and Eiffel. Additionally, OOP capabilities are being added to more traditional popular computer programming languages such as Pascal. The benefits of object classes can be summarized, as follows: • Objects and their corresponding classes break down complex programming problems into many smaller, simpler problems. • Encapsulation enforces data abstraction through the organization of data into small, independent objects that can communicate with each other. Encapsulation protects the data in an object from accidental damage, but allows other objects to interact with that ■ data by calling the object's member functions and structures. • Subclassing and inheritance make it possible to extend and modify objects through deriving new kinds of objects from the standard classes available in the system. Thus, new capabilities are created without having to start from scratch. • Polymorphism and multiple inheritance make it possible for different programmers to mix and match characteristics of many different classes and create specialized objects that can still work with related objects in predictable ways. • Class hierarchies and containment hierarchies provide a flexible mechanism for modeling real-world objects and the relationships among them. • Libraries of reusable classes are useful in many situations, but they also have some limitations. For example: • Complexity. In a complex system, the class hierarchies for related classes can become extremely confusing, with many dozens or even hundreds of classes. • Flow of control. A program written with the aid of class libraries is still responsible for the flow of control (i.e., it must control the interactions among all the objects created from a particular library). The programmer has to decide which functions to call at what times for which kinds of objects. • Duplication of effort. Although class libraries allow programmers to use and reuse many small pieces of code, each programmer puts those pieces together in a different way. Two different programmers can use the same set of class libraries to write two programs that do exactly the same thing but whose internal structure (i.e., design) may be quite different, depending on hundreds of small decisions each programmer makes along the way. Inevitably, similar pieces of code end up doing similar things in slightly different ways and do not work as well together as they should. Class libraries are very flexible. As programs grow more complex, more programmers are forced to reinvent basic solutions to basic problems over and over again. A relatively new extension of the class library concept is to have a framework of class libraries. This framework is more complex and consists of significant collections of collaborating classes that capture both the small scale patterns and major mechanisms that implement the common requirements and design in a specific application domain. They were first developed to free application programmers from the chores involved in displaying menus, windows, dialog boxes, and other standard user interface elements for personal computers. Frameworks also represent a change in the way programmers think about the interaction between the code they write and code written by others. In the early days of procedural programming, the programmer called libraries provided by the operating system to perform certain tasks, but basically the program executed down the page from start to finish, and the programmer was solely responsible for the flow of control. This was appropriate for printing out paychecks, calculating a mathematical table, or solving other problems with a program that executed in just one way. The development of graphical user interfaces began to turn this procedural programming arrangement inside out. These interfaces allow the user, rather than program logic, to drive the program and decide when certain actions should be performed. Today, most personal computer software accomplishes this by means of an event loop which monitors the mouse, keyboard, and other sources of external events and calls the appropriate parts of the programmer's code according to actions that the user performs. The programmer no longer determines the order in which events occur. Instead, a program is divided into separate pieces that are called at unpredictable times and in an unpredictable order. By relinquishing control in this way to users, the developer creates a program that is much easier to use. Nevertheless, individual pieces of the program written by the developer still call libraries provided by the operating system to accomplish certain tasks, and the programmer must still determine the flow of control within each piece after it's called by the event loop. Application code still "sits on top of the system. Even event loop programs require programmers to write a lot of code that should not need to be written separately for every application. The concept of an application framework carries the event loop concept further. Instead of dealing with all the nuts and bolts of constructing basic menus, windows, and dialog boxes and then making these things all work together, programmers using application frameworks start with working application code and basic user interface elements in place. Subsequently, they build from there by replacing some of the generic capabilities of the framework with the specific capabilities of the intended application. Application frameworks reduce the total amount of code that a programmer has to write from scratch. However, because the framework is really a generic application that displays windows, supports copy and paste, and so on, the programmer can also relinquish control to a greater degree than event loop programs permit. The framework code takes care of almost all event handling and flow of control, and the programmer's code is called only when the framework needs it (e.g., to create or manipulate a proprietary data structure). A programmer writing a framework program not only relinquishes control to the user (as is also true for event loop programs), but also relinquishes the detailed flow of control within the program to the framework. This approach allows the creation of more complex systems that work together in interesting ways, as opposed to isolated programs, having custom code, being created over and over again for similar problems. Thus, as is explained above, a framework basically is a collection of cooperating classes that make up a reusable design solution for a given problem domain. It typically includes objects that provide default behavior (e.g., for menus and windows), and programmers use it by inheriting some of that default behavior and overriding other behavior so that the framework calls application code at the appropriate times. There are three main differences between frameworks and class libraries: • Behavior versus protocol. Class libraries are essentially collections of behaviors that you can call when you want those individual behaviors in your program. A framework, on the other hand, provides not only behavior but also the protocol or set of rules that govern the ways in which behaviors can be combined, including rules for what a programmer is supposed to provide versus what the framework provides. • Call versus override. With a class library, the code the programmer instantiates objects and calls their member functions. It's possible to instantiate and call objects in the same way with a framework (i.e., to treat the framework as a class library), but to take full advantage of a framework's reusable design, a programmer typically writes code that overrides and is called by the framework. The framework manages the flow of control among its objects. Writing a program involves dividing responsibilities among the various pieces of software that are called by the framework rather than specifying how the different pieces should work together. • Implementation versus design. With class libraries, programmers reuse only implementations, whereas with frameworks, they reuse design. A framework embodies the way a family of related programs or pieces of software work. It represents a generic design solution that can be adapted to a variety of specific problems in a given domain. For example, a single framework can embody the way a user interface works, even though two different user interfaces created with the same framework might solve quite ., different interface problems. Thus, through the development of frameworks for solutions to various problems and programming tasks, significant reductions in the design and development effort for software can be achieved. A preferred embodiment of the invention utilizes HyperText Markup Language (HTML) to implement documents on the Internet together with a general-purpose secure communication protocol for a transport medium between the client and the Newco. HTTP or other protocols could be readily substituted for HTML without undue experimentation. Information on these products is available in T. Berners-Lee, D. Connoly, "RFC 1866: Hypertext Markup Language - 2.0" (Nov. 1995); and R. Fielding, H, Frystyk, T. Bemers-Lee, J. Gettys and J.C. Mogul, "Hypertext Transfer Protocol ~ HTTP/1.1: HTTP Working Group Internet Draft" (May 2, 1996). HTML is a simple data format used to create hypertext documents that are portable from one platform to another. HTML documents are SGML documents with generic semantics that are appropriate for representing information from a wide range of domains. HTML has been in use by the World-Wide Web global information initiative since 1990. HTML is an application of ISO Standard 8879; 1986 Information Processing Text and Office Systems; Standard Generalized Markup Language (SGML). To date, Web development tools have been limited in their ability to create dynamic Web applications which span from client to server and interoperate with existing computing resources. Until recently, HTML has been the dominant technology used in development of Web-based solutions. However, HTML has proven to be inadequate in the following areas: • Poor performance; • Restricted user interface capabilities; • Can only produce static Web pages; • Lack of interoperability with existing applications and data; and • Inability to scale. Sun Microsystem's Java language solves many of the client-side problems by: • Improving performance on the client side; • Enabling the creation of dynamic, real-time Web applications; and • Providing the ability to create a wide variety of user interface components. With Java, developers can create robust User Interface (UI) components. Custom "widgets" (e.g., real-time stock tickers, animated icons, etc.) can be created, and client-side performance is improved. Unlike HTML, Java supports the notion of client-side validation, offloading appropriate processing onto the client for improved performance. Dynamic, real-time Web pages can be created. Using the above-mentioned custom UI components, dynamic Web pages can also be created. Sun's Java language has emerged as an industry-recognized language for "programming the Internet." Sun defines Java as: "a simple, object-oriented, distributed, interpreted, robust, secure, architecture-neutral, portable, high-performance, multithreaded, dynamic, buzzword- compliant, general-purpose programming language. Java supports programming for the Internet in the form of platform-independent Java applets." Java applets are small, specialized applications that comply with Sun's Java Application Programming Interface (API) allowing developers to add "interactive content" to Web documents (e.g., simple animations, page adornments, basic games, etc.). Applets execute within a Java-compatible browser (e.g., Netscape Navigator) by copying code from the server to client. From a language standpoint, Java's core feature set is based on C++. Sun's Java literature states that Java is basically, "C++ with extensions from Objective C for more dynamic method resolution." Another technology that provides similar function to JAVA is provided by Microsoft and ActiveX Technologies, to give developers and Web designers wherewithal to build dynamic content for the Internet and personal computers. ActiveX includes tools for developing animation, 3-D virtual reality, video and other multimedia content. The tools use Internet standards, work on multiple platforms, and are being supported by over 100 companies. The group's building blocks are called ActiveX Controls, small, fast components that enable developers to embed parts of software in hypertext markup language (HTML) pages. ActiveX Controls work with a variety of programming languages including Microsoft Visual C++, Borland Delphi, Microsoft Visual Basic programming system and, in the future, Microsoft's development tool for Java, code named "Jakarta." ActiveX Technologies also includes ActiveX Server Framework, allowing developers to create server applications. One of ordinary skill in the art readily recognizes that ActiveX could be substituted for JAVA without undue experimentation to practice the invention. Electronic/Physical Mail Address Database Figure 3 is a flow diagram illustrating a method 300 of registering users in the database 100 of Figure 1. Such registration procedure is required to establish the information database with the highest integrity. As shown in Figure 3, an identity of a user is authenticated in operation 302, and a physical mail address of the user is received 304. Thereafter, in operation 306, an electronic mail address is assigned to the user, and the user is provided with a digital certificate for effecting payment during transactions utilizing a network. Note operation 308. To complete registration, the physical mail address, the digital certificate, and the electronic mail address are entered in a database, as indicated in operation 310. In use, the database allows for retrieving a physical mail address in response to the receipt of the electronic mail address as set forth hereinabove. Such physical mail address may thus be used to ship goods purchased during the transactions utilizing the network. In one embodiment, the identity of the user is authenticated by checking valid evidence of the identity of the user, i.e. a driver's license, birth certificate, military identification card, etc. Ideally, the authentication is carried out in a government agency by a trusted official. In the alternative, any other trusted third parties such as notaries, banks, lawyers, etc. may be employed. Such identity of the user may include an age of the user for reasons that will be set forth hereinafter. Further, payment may be received from the user for the registration. As an option, the assigned electronic mail address is selected by the user. Figure 4 is a flow diagram a shipper-based electronic/physical mail address database process 400. Once the database is established, an electronic mail address is retrieved from a parcel by the postal service centers 102 of Figure 1. Note operation 402. As an option, the electronic mail address may be written or coded on the parcel, and may be scanned from the parcel. Such electronic mail address is the type capable of being used to transmit information over a network. Next, in operation 404, the database is queried using the retrieved electronic mail address. The database includes a plurality of electronic mail addresses and associated physical mail addresses, as set forth earlier. As an option, the database may be queried from afar using one of the networks mentioned earlier. Thereafter, the physical mail address associated with the received electronic mail address is received from the database in response to the query, as indicated in operation 406. At that point, the physical mail address may be physically applied to the parcel. The parcel is then shipped to the physical mail address in operation 408 by conventional methods, land, air, sea-based cargo vehicles. Figure 5 is a flow diagram illustrating a method 500 of handling a change of address in a database in accordance with one embodiment of the present invention. As mentioned hereinabove, the database includes a plurality of physical mail addresses and associated electronic mail addresses. Initially, in operation 502, electronic mail addresses are retrieved from associated parcels. Next, physical mail addresses are identified based on the retrieved electronic mail addresses using a database. Note operation 504. During the course of use, an updated physical mail address may be received from a user as part of a request to update the database in operation 506. This request may be received by way of a network such as the Internet, or in person. Thereafter, an identity of the user is authenticated in operation 508. After the authentication of the identity, the physical mail address associated with the electronic mail address is replaced without modifying the associated electronic mail address. See operation 510. As such, retrieval of the electronic mail address subsequent the replacement results in the identification of the updated physical mail address. In one embodiment, the identity of the user is authenticated by checking a piece of evidence verifying the identity. As an option, other means of authentication may be employed such as the use of a digital certificate that is issued during the registration process of Figure 3. As mentioned earlier during reference to Figure 4, the electronic mail address may be written or encoded on the parcel, and may be scanned from the parcel. In order to accomplish this a handheld scanner may be employed. A compact hand-held and hand-guided device will now be described which employs a one dimensional linear scanning array as the main scanning element. This array provides a series of vertical "slices" or samples of the text being scanned. A secondary single detector element, which may or may not be an element of the main scanning array, simultaneously samples the text at a predetermined vertical and horizontal position relative to the main scanner detector array. This action provides a means of establishing the appropriate spatial accurate representation of the scanned character, via specialized computer algorithms which have been developed, so that the application of optical character recognition (OCR) software can provide a precise interpretation of the scanner output. The present device provides a simple, light, compact, and inexpensive hand-held scanner for note taking, excerpting text, reference citing, etc. The scanner can take the shape of a pen or of a palm controlled device similar to a computer mouse. The information to be scanned can be acquired from printed sources such as books, magazines, newspapers, etc. All or a portion of lines of text of arbitrary (within reason) lengths can be scanned. Following the scanning action, a computer algorithm (to be described) corrects the baseline variations of the scanned text and then conects for distortions due to uneven scanning speed. The processed text is then subjected to a standard optical character recognition (OCR) analytical program and the scanned text is thus converted from a bitmapped image to ASCII character codes, thereby providing a vast savings in computer memory for a given amount of text. As indicated in Figure 6, the scanner 610 is stroked along a line of text so that each character is in turn is partially in the field of view of the linear scanning anay 620. In this manner the fully scanned image provides a succession of vertical slices of each character of the text. Each slice of the text character is stored as a lxN record (in our case a 1x128 record). After the raw scanned image is stored, a computer algorithm corrects for uneven or skewed baseline and for uneven and/or incorrect scan speed across the page. Then an OCR program converts the corrected scanned image into ASCII text codes for final storage and utilization. Referring now to Figure 6, a scan pen 610 of the present invention is represented in a cut away view. The scan pen is stroked is a direction 612 along a set of text characters 614. The text characters on the printed page are illuminated by a set of light emitting diodes (LEDs) 616 or some other bright light source such as incandescent or fluorescent lamps or laser diodes, etc. If necessary and/or appropriate, the illumination produced by these light sources can be enhanced and made uniform by the presence of a metallic reflecting insert surface (polished aluminum) 618 placed inside the scan pen nose piece. An image of the text 622 is formed in the plane of the linear scanning detector element 620 by lens 624. Dotted lines 633, 634, 635 and 636 indicate the extent of the optical path that forms the image on the detector face. A beam splitter 626 is placed at an intermediate position between lens 624 and the linear detector 620. This causes a secondary image 628 of the text to be formed (in the illustrated case) at a right angle to the primary image 622 which is itself focused onto linear detector anay 620. A single discrete detector element 630 is positioned in this image plane so that it detects a position in the scanned text which is advanced (or retarded if appropriate) relative to the primary image position on detector array 620. Dotted lines 664 and 666 indicate the extent of the optical path that forms the image onto detector 630. This advanced position is predetermined by fabrication of the scan pen, and in the example cited in the summary it is set at 0.125 inches although obviously any appropriate value may be selected. As illustrated in Figure 6, the detector array 620 is shown as scanning a slice of the character "a" while the discrete detector 630 is shown as detecting a position in the character "b" which is yet to be imaged onto the detector array 620. Electronic package 632 performs the function of clocking the array scanning and conditioning the output for presentation to a computer. One alternative to this approach would be to replace the single element detector 630 with a second linear array, similar to the main detector array 620, which is oriented at the position of detector 630 so as to provide a horizontal slice of the text being scanned. This arrangement would permit additional flexibility in the leading detector element positioning aspect of the scanner. Figure 7 shows the same view as Figure 6, but now with the scan of text having been advanced. In this case the primary image is positioned with the letter "b" focused onto array 620 while the letter "c" has advanced into position on discrete detector element 630. Therefore the detection of the position of letter "b" is produced onto detector 630 earlier in the scan than is the detection of "b" by the primary linear array 620. For the case cited, this detection at the discrete detector 630 occurs precisely 0.125 inches in front of the conesponding image position on detector array 620. Since the detector array 620 is scanned at a constant rate, in the case of our working device at 15,635 complete scans per second, it is possible to determine the exact number of scans of array 620 that occurred between the detection of the leading edge of character "b" by the discrete detector 630 and the corresponding leading edge of the character "b" by the particular array element of detector array 620 that is in horizontal resolution with the discrete detector 630. In the scan pen that we assembled we found that the appropriate corresponding anay element of anay 620 was element number 658 out of the set of 128. Since the array dimensions dictated that 64 scans were required to form a exact image of the text being scanned for the scan pen that has been fabricated and tested, the comparison of the experimentally encountered number of scans to the required 64 scans, permits the development of a computer algorithm which will eliminate scans on a distributed basis so that the exact spatial representation of the scanned text can be produced. Thus the advanced/retarded single detector element, together with appropriate processing by a computer fulfills the equivalent role of the earlier described rotating and tracking "tachometer", "synchronizer", or "encoder" wheels or balls. I shall designate the function of this detector/computer algorithm as the "virtual encoder" or "VE". Figure 8 shows another cut away view of the scan pen, taken in the direction orthogonal to those of Figure 6 and Figure 7. It further clarifies the relationship between the "advanced detector" element 630 and the conesponding element of the main scanning array 620. Figure 9 shows another methodology for providing the VE function. In this embodiment, a flat bundle of optical fibers 640 provides an object plane 642 at its upper surface which is in turn imaged onto the linear detector anay 620. This upper surface if formed into a linear anay of fibers, each of which has a diameter of about 50 micrometers (0.002" or about 500 elements per linear inch). Thus 128 of them provide a linear anay of some 0.25" in length, which dimension is an excellent match to the linear detector array cunently being employed as the scanning detector. If appropriate, a larger or smaller fiber bundle could be fabricated in order to contact a longer or shorter scanning anay. If it were possible to bring the upper face 642 of bundle 640 into direct and intimate contact with array 620 then such imaging lens 624 would be unnecessary. However, commercially available arrays posses an encapsulating window of thickness such that such direct contact of a fiber bundle to this window cannot produce an image on the anay of adequate resolution. In the future, arrays could be fabricated that either permit direct contact by such fiber linear bundles or said anays could be fabricated with sufficiently thin protective windows that direct contact would provide for the necessary spatial resolution on the anay. It is possible, however, that a very sophisticated computer analysis of the resultant scanned image might derive useful information. One major key point of this embodiment lies in the fact that the lower face 644 of the fiber bundle has been modified so that a few (one to four) of the fibers 646 from one edge of the bundle 640 have been rerouted so that it (they) are positioned in the object plane next to the text 614 being scanned in a position precisely located a known distance in front of the main body of the bundle 640. This then provides a VE element which is registered with a particular element of the main array 620 and positioned a known and predetermined distance before (after) the main array fiber system 640. Also, the VE output is registered onto the edge element(s) of the main anay and thus automatically shares the gain parameters of the anay as well as eliminating some circuitry and programming necessitated by the existence of an independent single element detector to provide the VE function. As indicated, the leading aspect of this set of few fibers effectively produces an advanced image 638 of the text being scanned upon the conesponding few detector elements at one end of the main scanning a ay. An additional embodiment of the scanning device is presented in Figure 10. This embodiment derives in part from that of Figure 9 which is discussed above, hi this embodiment, a linearly registered fiber anay 640 is now positioned so that its input face 644 is positioned remotely from the surface being scanned. Now, text 614 is imaged onto the input (lower) face of the fiber bundle 640 which is again configured such that the lower or input face 644 possesses the advanced VE configuration described above relative to Figure 9. An additional lens 650 positioned at an intermediate position between text element 614 and fiber bundle input face 644 images said text onto the plane of the fiber bundle input face. This embodiment thus places the bundle input face at a remote position from the substrate surface being scanned and thus precludes any possible pick up of surface debris which might contaminate scanned images for the case of elements which might contact the scanned surface. Dotted lines 654, 655, 656, and 657 indicate the extent of the optical path that forms the image onto the fiber bundle input face. At this point the data set derived from the scan pen consists of a set of scan slices of the text, each slice being 128 individual "pixel" elements, plus a single detector output from the advanced element 630. The complete data set is comprised of an indeterminate number of such scans, but for purposes of estimation, if the scans occur on an average of 1000 scans per linear inch of text and the line of text is 6 inches overall, then the record will be some 6000 sets of the (128+1) detector outputs. In order to make the data files more manageable it was decided to replace the output of scan anay detector element #1 with the output of the discrete detector, the virtual encoder, 630. Thus the file is reduced to a 128xN anay. The first part of the data processing is to replace a 128 byte single scan file by a 16 byte file in which each pixel of the scanning array is represented by a single pixel in a byte; i.e. a byte now represents the output of 8 elements of the anay. This is possible since the only useful information contained per element in the output of the anay is either a "0" which represents the presence of light reflected from the text or a "1" which represents the absence of light. Thus a "0" represents white on the paper while "1 " represents black. Since the plotting to the screen is a bitmap function (as is the OCR processing), this method of data representation is both effective and efficient in memory usage. Following this straightforward conversion of the data, the next problem to be addressed is the baseline conection. Conection must be made for skewness of the scanned image which is evidenced by a continual slanting of the baseline as a function of distance into the scan. Conection for the non-linearity of scan must also be made. A curved or wavy baseline must be accounted for and all text characters displayed relative to a single horizontal baseline. The baseline conection algorithm employed here is given below in nanative format. It is clear that numerous other algorithms could be developed if the information available from the VE system is incorporated. First: For any given font style, there are only 5 characters which have text elements which descend below the fundamental baseline of the text. Such characters are known as "descenders". They are the lower case letters g, j, p, q, and y. There are 9 characters which have the property of text elements which lie above the fundamental text height line. They are the lower case letters b, d, f, i, j, k, 1, and t (i and j are included by their possession of the dot above the character). These characters are known as "ascenders". Capital letters and numerals share the text height of the ascender set of lower case letters. The remaining 13 lower case characters a, c, e, m, n, o, r, s, u, v, w, x, and z establish the fundamental text "height" in that the lower edge of these characters form a "baseline" for the text (which is common with the ascender class of characters) and the upper edge of the character set form the "heightline" for the font in that all of the characters share a common upper value. The length below the baseline of the descending portion of descender characters is between 35% and 39% of the fundamental text height (we will use 37%). Also the height of ascenders, capital letters and numerals is 137% of the fundamental text height. For the case that the text is all capitals, this font height analysis is not necessary. Second: Baseline correction or compensation is established by the following scanner/software procedures: When the scanner is first to be employed on a series of text lines, it is placed into a "calibrate" mode by a software switch. Then a representative line of the text is scanned. The scanned image is examined by the specialized software algorithm which determines the fundamental text height. This is done by determining the highest and lowest scanner element addresses which are "l"s; i.e. the extent of black elements is determined within each text character. The extent of text characters is established by locating a series of scans which contain no black elements. That is scans which have black elements are grouped between series scans which have only white spaces. In the case of text characters which are occasionally connected, then the identified "character" may well consist of two or more true text characters. The computer will thus establish two fundamental heights of the scanned text. The larger value will be associated with ascenders, descenders, capital letters and numerals. The smaller value will be associated with the 13 lower case "fundamental text height" characters. This value is stored in memory for future reference. Third: The scanner is then switched into the "scan" mode and a scan is initiated. A baseline for the text is established after completion of one line of scanned text by locating the nearly constant lower address of text characters (abrupt downward changes of 25% or more of the stored text height are deleted from consideration). The baseline value observed at the beginning of the text is noted and any small changes (less than 28% of the text height) in text baseline are conected to the initial value by shifting the scanner element values up or down by the detected difference amount. Whenever a "descender" is noted and identified (change in apparent baseline by more than 28% downward) the program notes the beginning scan number of that character and includes that character into the baseline conection noted for the next succeeding baseline conection procedure thereby including the descender. This program thus produces a bitmapped image of the text which now resides on a completely flat horizontal baseline. Again, note that other algorithms can produce this same result if the algorithms are presented with the scanned text slices and the synchronized output of the virtual encoder. The text image must now be conected for non uniformity of scan stroke as well as the basic enor in scan velocity which produces a distorted image of the text. Therefore, a nanative but quite comprehensive description of the program/algorithm is also given here. Briefly; the program detects the onset of a leading edge of a character in the advanced discrete detector element 630. The number of scans that exist between this event and the event of detecting the onset of the same leading edge by the conesponding registered linear anay element (#658 for the case of the scan pen device already tested) is established. The comparison of that experimental number of scans as compared to the required "precise image" number of scans (664 for the present case) then permits the orderly elimination of scans on a regular proportional basis so that the remaining scans produce a faithful image of the text The next paragraph gives the nanative version of the computer algorithm flow chart specifically for the case where scans must be deleted in an orderly manner. A similar algorithm has been written for the case that additional scans must be added in a similarly ordered manner for accurate image representation when the scan has been produced at too fast a scan rate. The virtual encoder (VE) always views the text at an advanced position relative to the main array (MA). This advanced distance requires a set number of scans for true image presentation; this number of scans is designated as VAL. The program must recognize a light-to-dark transition in VE (0..1), note that scan number (scan number N), and subsequently identify the same (0..1) transition in the MA at element number MA-R, which is the MA element in exact horizontal registration with VE. At the start of processing of a text segment: START IF (EOF) then STOP 1. Set ctr = 0, ctrl = 0, ctr2 = 0, note the scan number in the file = N. 2. Read a scan. 3. If ctr = 0 and VE = 1 (already black) add 1 to ctrl and ctr2. GoTo 2. 4. If ctr = 0 and VE = 0 (has turned white) set ctr = 1, add 1 to Ctrl and ctr2. GoTo 2. 5. If ctr = 1 and VE = 0 (still white) add 1 to ctrl and ctr2. GoTo 2. 6 . If ctr = 1 and VE = 1 (transition to black) set ctr = 2. GoTo 2. 7. If ctr = 2 and MA-R = 1 (black) add 1 to ctr2 only. GoTo 2. 8. If ctr = 2 and MA-R = 0 (has turned white) set ctr = 3 and add 1 to ctr2. GoTo 2. 9 . If ctr = 3 and MA-R = 0 (still white) add 1 to ctr2. GoTo 2. 10. If ctr = 3 and MA-R = 1 (transition to black) this represents the end of the processing segment and the routine branches out to perform the image correction based on the information contained in VAL, N, ctrl, and ctr2. GoTo 11. 11. If (ctr2 - ctrl) > VAL (the number of scans required for accurate imaging) then some scans must be eliminated to provide a faithful image. The following procedure is to be applied for data scans number N to N + ctr2. a. Set variables Correct = 0; Int. sub.-- Correct = 0 (integer part of Correct); old. sub.-- Int. sub.-- Correct = 0. b. set W = VAL/ (ctr2 - ctrl) , this value is less than 1. c. Correct = Correct + W. d. Int. sub.-- Correct = Integer part of Correct. e. If Int. sub.-- Correct = old. sub.-- Int. sub.-- Correct remove this scan from the data , , , , , , shift all remaining scans down to lower address by 1 and reduce (N + ctr2) by 1. f. If Int. sub.-- Correct = old. sub.-- Int. sub.-- Correct + 1 keep this scan , , , , , , , set old. sub.-- Int. sub. -- Correct = Int . sub . - - Correct , , , , , , , , , , , , , , at end of segment : GOTO START As noted for other segments of the software that has been already developed by the inventors, there are other methodologies that could provide the properly conected text image if such programs were to be provided with the virtual encoder information as disclosed in this document. This processed image is then formatted for presentation to an OCR program for reduction of the text image to ASCII code representation. By "formatted" it is meant that the finalized bitmap image is given the appropriate file header so that the selected OCR program can process the information directly. With a text image processed according to the methodologies outlined here, there are several readily available OCR programs that are capable of accurately analyzing the data and providing the appropriate ASCII encoded text. Figure 11 is a flow diagram illustrating a retail-based transaction method 1100 using a database in accordance with one embodiment of the present invention. First, in operation 1102, an order for goods is received from a buyer utilizing the network. This may be accomplished using a site on the network, i.e. website, which provides information on goods, and allows the buyer to select desired goods. Next, in operation 1104, an electronic mail address is received from the buyer utilizing the network. As an option, the step of receiving the electronic mail address maybe preceded by the step of prompting the buyer to enter the electronic mail address. Payment is also accepted for the order of goods from the buyer utilizing the network. See operation 1106. Such payment may be accepted using a digital wallet and or a credit card number. Thereafter, in operation 1008, the electronic mail address is applied to the goods, and the goods are shipped, in operation 1010. During use, a shipping entity is capable of utilizing the electronic mail address to determine a physical mail address of the buyer, as set forth earlier. Figure 12 is a flow diagram illustrating a buyer-based transaction method 1200 using a database in accordance with one embodiment of the present invention. As shown, an order for goods is sent from a buyer to a seller utilizing the network in operation 1202. As discussed earlier, the buyer may select the goods from a plurality of goods displayed on a site on a network such as the Internet. Next, in operation 1204, a prompt is received to enter an electronic mail address of the buyer utilizing the network. In response to the prompt, the electronic mail address is entered for transmission to the seller utilizing the network. Note operation 1206. Further, payment is effected for the order of goods utilizing the network by sending the seller an account identifier, as indicated in operation 1208. In one embodiment of the present invention, the account identifier conesponds to a digital wallet and/or a credit card number. During the foregoing processes, payment may be effected using a credit card, but preferably involves a digital wallet. One exemplary digital wallet system will now be discussed. Figure 13 shows the overall architecture of the prefened system for utilizing an open communication network such as the Internet as a medium for the transfer of credit card account information. The system on which the cyber wallet is utilized includes a plurality of users, each provided with an individual cyber wallet, the users being connected to a plurality of merchant processors over the Internet (for example, by means of the World-Wide Web). Each of these merchant processors is connected by means of a secured network or by means of a secret tunneling or other channel protecting procedure to a credit processor held by at least one account servicer. As will be described in more detail below, payment information is transfened from a user to a merchant processor in the form of a public key encrypted authorization ticket, which is then forwarded by the merchant to the credit processor. All unprotected communications over the Internet are presumed to be accessible by unauthorized parties, and all merchants are subject to suspicion. The credit processors, however, are presumed to be secure and trustworthy. The cyber wallet on which the preferred system and method is based is in the form of any account and/or personal information required to be transmitted to the account servicer in order to verify the account status, and which may be "carried" on a tamper resistant portable electronic storage medium such as a smartcard, or stored on the customer's computer (or personal digital assistant, PCMCIA card, or the like) together with the browser/mosaic software which will enable the customer to utilize the wallet for transactions carried out on the Internet, and a public key file which will be described below. For some purposes, information in the wallet could also be accessible solely through use of a PIN mechanism, such as might be included in a smart card in order to ensure compatibility with such systems. It should be appreciated that the particular information contained on the card will vary depending on the requirements of the account servicer, as will the particular browser software included in the wallet. These elements per se are not part of the invention, but rather it is their combination with the public key file and the manner in which they are used to cany out a transaction that constitutes the invention. Those skilled in the art should also appreciate that, although the "wallet" may be contained in a smartcard or other physical device, it may also exist purely as software (which is why the "wallet" is refened to herein as a "cyber wallet"). This is not to say that the cyber wallet is merely a virtual or abstract concept, however. The cyber wallet does exist in static physical form, in the form of instruction stored in a memory device, or programmed into the wiring of an integrated circuit, and will be used by the customer in the same manner as a credit card. In one embodiment, for example, the cyber wallet is contained on a smartcard which can be inserted into a card reader in a manner similar to the manner in which existing credit or debit cards are used, without the need for entry of additional information. In one embodiment, the cyber wallet is in the form of software provided to the consumer by his credit card company or bank, and may be stored on the consumer's personal computer rather than being physically carried around like a smartcard. In either case, the cyber wallet includes what ever information is needed by the account servicer to authorize a transaction and, uniquely, a file containing a plurality of public keys. These public keys are an important feature of cyber wallet because it is these keys that are used to protect the information on the card as it is being transmitted to the merchant. Essentially, the concept of the key file is to use one of the public keys of a public-private key cryptosystem to encrypt the necessary information and send the encrypted information in the form of an "authorization ticket," which can then be forwarded by the merchant together with order information, as necessary, to the account servicer/authenticator in order to obtain authorization from the account servicer which allows the transaction to be completed. By using public keys to encrypt the information, so that the information can only be decrypted by the party in possession of the associated private key, the information can be fully protected as it is passed electronically to the merchant, and from the merchant to the account servicer. The inclusion of a public key file in the cyber wallet is to be distinguished from the inclusion of card authentication information. The present invention involves public key encryption of any information contained in the wallet which is necessary to authenticate the transaction, and private key decryption, the private key being held under secured conditions by the account servicer who carries the ultimate risk of any fraud. As an additional measure of security, the public key file contained in the wallet contains means for varying the public key used to encrypt the authorization ticket, thus reducing the likelihood that one of the keys could be compromised. Use of the cyber wallet is carried out as follows: First, the wallet is created by the account servicer or provider under secured conditions, by gathering together all information necessary to cany out credit transactions remotely over the Internet, including browser/mosaic software if necessary, account information, a user PIN number, a user ID, MAC, and any other information which might be needed during the payment and authentication process. This information is associated with a public key file preferably containing a plurality of public keys associated with a single root key, and key identifiers. The entire wallet is then provided to the customer, in any form which enables the customer to utilize the wallet, for example as a software package for use on the customer's portable computer, or on a smart card which can be carried around by the customer and used at kiosks provided with smart card readers. When a transaction is to be carried out, the customer selects the appropriate wallet, depending for example on which "credit card" he or she wishes to use, by retrieving the software from a disk, or inserting a smart card into a card reader, and establishes communications with the merchant. The customer then makes an order and the merchant requests an authorization ticket in the form of payment or account information encrypted by one of the public keys in the public key file. Selection of the public key may be in response to transmission from the merchant of a public key identifier associated with the public key. If the card has been inserted into a card reader, or if the software has been provided with provision for accepting a PIN number, entry of the PIN number can be required to proceed with the transaction at this time to unlock the information stored in the wallet or to verify the user identity as part of the credit card verification, and in addition the authenticity of information in the wallet can be verified using various techniques. When the merchant receives the authorization ticket, the merchant then embeds or associates it with whatever information the merchant needs to provide the account servicer. The authorization ticket is then forwarded to the account servicer, at which point the account servicer uses the private key associated with the selected public key in order to decrypt the file and verify the status of the account. If the transaction is approved, the account servicer then sends an approval message back to the merchant, together with decrypted information necessary for the merchant's records. It will of course be appreciated by those skilled in the art that rather than changing public keys by having the merchant instruct the cyber wallet which of a plurality of keys to use based on a key identifier, which may for example be provided to the merchant by the account servicer, which can thus prevent the use of compromised keys, a public key can be replaced by other means, for example by including provision in the cyber wallet for decrypting a new public key which has been encrypted by the old private key. Also, it is possible to provide for cyber wallets containing the necessary public key file and browser software to be downloaded by a merchant to a customer, rather than supplied by the "credit card" company directly to the customer, with the user adding the account and personal information necessary to effect a transaction, in which case the private key will still be held by the account servicer and the merchant will still have no access to any information in the authorization ticket which it forwards from the customer to the account servicer. Having thus described aprefened embodiment of the invention in sufficient detail to enable those skilled in the art to make and use the invention, it should therefore nevertheless be appreciated that numerous modifications and variations of the basic "cyber wallet" concept, and it is intended that the invention encompass all such modifications and variations without limitation to the details of the prefened embodiments described above. To the contrary, it is intended that the above description not be taken as limiting, but rather that the invention be defined solely by the appended claims. Figure 14 is a flow diagram illustrating method 1400 of verifying an age or other types of information on a buyer during an e-Commerce transaction using a database. The present method may be particular beneficial during a transaction with a seller for age-sensitive goods or services over a network. Such goods may include at least one of tobacco, adult video, and alcohol. Services such as financial transactions may also utilize the present system. First, a database must be established, as set forth earlier. Accordingly, in operation 1402, an identity of a buyer is received including an indication of an age of the buyer. In one embodiment, the information may include an address, zip code, phone number and/or professional affiliation. Thereafter, in operation 1404, a physical mail address of the buyer is received after which an electronic mail address is assigned to the buyer. Note operation 1406. The physical mail address, the identity, and the electronic mail address are all subsequently entered in a database for retrieving a physical mail address in response to the receipt of the electronic mail address. Note operation 1408. With the database in place, a request may be received from a seller for verification of the age or other information on the buyer utilizing a network. Note operation 1410. This request may be received via the Internet, or by any other means. In response, the database may be queried for retrieving the identity of the buyer, as indicated in operation 1412. In operation 1414, a verification of the age of the buyer may then be transmitted to the seller utilizing the network. In one embodiment of the present invention, a digital certificate including the identity of the buyer may be generated and stored in the database. In use, the buyer may be provided with the digital certificate for submission to the seller during the transaction. As such, the request received from the seller may include the digital certificate. In one embodiment, the digital certificate may be used by the seller themselves to authenticate the age of the user. Figure 15 is a flow diagram illustrating an electronic mail address validation scheme 1500 during an e-Commerce transaction using a database. During such transaction, the present method may be used by a retailer to determine whether the buyer is registered with the database. Again, the database must be established prior to carrying out the present method. To accomplish this, in operation 1502, an identity of a buyer is authenticated after which a physical mail address of the buyer is received so that an electronic mail address may be assigned to the buyer. Note operations 1504-1506. The physical mail address, the identity, and the electronic mail address are each subsequently entered in a database for retrieving a physical mail address in response to the receipt of the electronic mail address. Note operation 1508. During use of the present invention, a request may be received from a seller for verification of an electronic mail address of the buyer utilizing a network, as indicated in operation 1510. In response, in operation 1512, the database maybe queried for retrieving the electronic mail address of the buyer. Further, a verification of the electronic mail address of the buyer may transmitted to the seller utilizing the network. See operation 1514. As an option, the verification may include a verification of an existence of the electronic mail address in the database. In the alternative, the identity of the buyer may be received from the seller, wherein the verification of the electronic mail address includes a verification that the identity conesponds to the electronic mail address. Figure 16 is a flow diagram for an electronic delivery confirmation method 1600 using a database. Initially, in operation 1602, a parcel is shipped using an electronic mail address situated thereon by looking up an associated physical mail address in a database. During the shipment of the parcel, a location thereof is tracked utilizing a network in operation 1604. This may be accomplished by logging the parcel in a database each time the parcel changes locations. This can be accomplished by any means using hand held scanners, etc. Thereafter, a message is transmitted using the electronic mail address in operation 1606. Such message is indicative of the location of the parcel during the shipment thereof. In one embodiment of the present invention, the message may be transmitted upon the location of the parcel being the physical mail address. As an option, the electronic mail address may include a user name, a first level domain name, and a second level domain name for use on a network such as the Internet. Further, the network by which the location is tracked is different from that on which the electronic message is transmitted. In another embodiment of the present invention, a confirmation number may be assigned to the parcel upon looking up the associated physical mail address in the database. Such confirmation number may in turn be used to track the parcel. As an option, the confirmation number is scanned. Further, the message may be automatically sent each instance that the confirmation is scanned. In still another embodiment, the electronic mail address is used to transmit the message to at least one of a pager and a wireless phone. Figure 17 is a flow diagram for an escrow process 1700 using a database in accordance with one embodiment of the present invention. Such method is particularly beneficial in auction environments when the reputation or integrity of the seller can not be readily verified. First, in operation 1702, an agreement is facilitated between a buyer and a seller to transact utilizing a network. As an option, the agreement may be facilitated by providing an auction environment utilizing the network via a website or the like. Next, in operation 1704, an electronic mail address is received from the buyer utilizing the network. Payment is then accepted from the buyer for goods being sold by the seller utilizing the network. Note operation 1706. This may take the form of a digital wallet or credit card number, as set forth earlier. Thereafter, the payment is held in operation 1708. The seller is then provided with the electronic mail address for shipping the parcel in operation 1710. In operation, the shipping entity is capable of utilizing the electronic mail address to determine a physical mail address of the buyer, and tracking a location of the goods during the shipment thereof. Such tracking may take any desired form that is well known to those of ordinary skill. After verification by the shipping entity of the receipt of the goods by the buyer is the payment is the payment released to the seller. Note operation 1712. As an option, the verification of the receipt of the goods is received utilizing the electronic mail address. The shipping entity may also be provided with an electronic mail address of the intemiediary such that the intermediary receives the verification. i addition to the various other functions discussed hereinabove, the server 103 of Figure 1 is capable of providing electronic mail services. In order to accomplish this any desired mailing system may be employed. One exemplary mailing system will now be set forth. Figure 18 schematically shows, in block form, the structure of an electronic mail system 181 according to one embodiment of the invention. The electronic mail system 181 is composed of a host 182 undertaking the management of mailboxes MB; and a plurality of data processing systems 183, 184 for transmitting data to each other through the host 182. The host 182 is, for example, a general-purpose large-sized computer system and has the function of providing various network services including electronic mail service (i.e., mailbox service). When a mail M addressed to the data processing system 184 is input (put in the post) from the data processing system 183 for example, the host 182 once stores the mail M in the mailbox MB for the data processing system 184. Upon receipt of a request for transferring from the data processing system 184 or at a predetermined time, the host 182 transfers (delivers) the mail M to the data processing system 184. Each of the data processing systems 183, 184 is a stand-alone computer system composed of, for example, a personal computer, display unit, hard disk etc. and various kinds of application programs can be used with it. In the data processing systems 183, 184, an electronic mail terminal utility 185, which is a kind of application program, performs processing on signals concerned with mail services provided by the host 182. The electronic mail terminal utility 185 maintains a user mail server 186 which is a data base having a plurality of folders for storing data associated with electronic mails, and a folder table 187 in which types of data are shown in relation to folder names for ready reference. The contents of the user mail server 186 and the folder table 187 are created individually for each of the data processing systems 183, 184 and therefore their contents in the data processing system 183 are usually different from those of the data processing system 184. However, the users of the data processing systems 183, 184 may make arrangements for using the same number of folders and/or the same folder names. In the data processing system 184 of this embodiment, the user mail server 186 has, as shown in Figure 18, a message folder Fm, a shared folder FO and three dedicated folders FI to F3 as receiving folders. Figure 19 shows the anangement of data in the mail M. The mail M is composed of a content part MC containing optional information to be conveyed from one end user to another and an envelop part ME containing control information used to conectly transmit the content part MC and to properly manage the content part MC at the receiving side. The content part MC is composed of one or a plurality of heading files HF that are a group of text data conesponding to message information and one or a plurality of attachment files AF that are attached to the heading files HF in order to send data information. The file anangement (i.e., the number and type of data files which are a collection of data representing optional information) of the content part MC varies for every case. In some cases, the mail M to be transmitted includes the content part MC which consists of only data files conesponding to message information or only data files conesponding to data information. The format of the envelop part ME is fixed in the electronic mail system 1 and the envelop part ME is composed of 13 items of directory data Dl to D13 by which processing operations performed by the host 182 and the data processing systems 183, 184 are specified. The directory data Dl to D13 are 13 items of data indicating a serial No. allocated to every mail M; the postal indication of the mail M (ordinary, registered, confidential, express, multiple address etc.); the name of the mail M; an addresser's identification code; an addressee's identification code; a sending date; the length of the mail M (excluding the attachment files AF); the number of attachment files AF; the name of the attachment file AF; the attribute of the attachment file AF; the length of the attachment file AF; the name of the specified folder; and the presence or absence of aTequest for creating a new folder, respectively. One set of the directory data D9 to D13 conesponds to one attachment file AF, and therefore, when N-number of attachment files AF exist in the content part MC, N-sets of directory data D9 to Dl 3 are written in the envelop part ME. The attribute of the attachment file AF mentioned herein is the type of file classified in accordance with a desired feature such as applications software used for creating the file, or the presence or absence of a protect. Figures 20 and 21 schematically show the flow of the processing performed by the electronic mail terminal utility 185. The electronic mail terminal utility (hereinafter refened to as "utility") 185 has four functions, i.e., creating the mail M, transmitting the mail M, receiving the mail M and environment setting such as registering the management conditions of the mail M. When the operator of the data processing system 184 for example starts up the utility 185, the utility 185 displays a function-selection screen (initial menu) on a display unit, showing the four functions as well as termination as commands to be selected, and checks which command has been selected from the initial menu. Creating the mail M! When the operator selects the mail creating function, the utility 185 writes a mail name, an addresser's identification code and an addressee's identification code in the envelop part ME as the directory data D3, D4, D5, these pieces of information having been input by the operator through a key board. Thereafter, the utility 185 displays an interactive screen to require an operator's instruction and then executes editing processing for creating the content part MC (#1811 to 1813). Upon receipt of an instruction to terminate the editing, the utility 185 executes attachment file register processing for writing the name of the attachment file AF (directory data D9) in the envelop part ME. Then, the utility 185 calculates the length of the attachment file AF and the length of the mail M to store in the envelop part ME as the directory data Dl I, D7 (#1814 to 1817). The substantially finished mail M is stored in the transmitting folder (#1818). Figure 22 shows the flow of the attachment file register processing of Figure 23. In this sub-routine, the utility 185 writes the attachment file name input by the operator in the envelop part ME as the directory data D9 (#18161). With this step, one attachment file AF has been registered as transmitted data. When specifying a folder for storing the attachment file AF at the receiving side, the name of the specified folder is written as the directory data D12. If a request for creating a new folder is made when the specified folder does not exist at the receiving side, a flag for indicating the presence of the request is set and stored as the directory data D13 (#18162 to 18165). If there are a plurality of attachment files AF, the same processing is performed for every attachment file AF, and then, the program proceeds to Step 1817 in Figure 20 (#18166). Transmitting the mail M! When the operator selects the transmitting function in the initial menu (see Figure 20), the utility 185 firstly displays a list of mails M stored in the transmitting folder (#1821). The utility 185 selects one or a plurality of mails M specified by the operator as data to be transmitted. In response to a transmitting instruction sequentially input by the operator, a sending date (directory data D6) is written in the envelop part ME of the mail M selected as data to be transmitted and then the mail M is sent to the host 182 (#1822 to 1826). Receiving the mail M! When the operator selects the receiving function in the initial menu, the utility 185 makes enquiries to the host 182 about the presence or absence of the mail M addressed to the data processing system 184, and performs receiving processing for receiving the mail M if there exists (#1831, 1832). During the receiving processing, the heading file HF is stored in the message folder FM whilst the attachment file AF is once stored in the shared folder F0. Thereafter, the utility 185 performs attachment file analysis processing in which a folder suited for the attachment file AF is set and the attachment file AF is transfened from the shared folder FO to the set, suitable folder (one of the dedicated folders FI to F3 or a new folder) (#1833, 1834, 1835). In short, the attachment file AF is classified (attribute identification) and stored. This facilitates the editing operation (processing) of the attachment file AF which will be performed later by the use of applications software. Figure 23 shows the flow of the attachment file analysis processing of Figure 21. If folders are specified for all the attachment files AF of the mail M at the transmitting side and there exist all the specified folders within the user mail server 186, the utility 185 sets, in this sub-routine, the dedicated folders FI to F3 specified by the directory data D12 (the name of a specified folder) as folders suitable for storing the attachment files AF (i.e., transferring destination for the attachment files AF) and terminates the processing of the sub-routine (#18341 to 18344). If a request for creating a new folder is made when the folder specified by the transmitting side does not exist within the user mail server 186, a new folder having the specified name is created and set as the transferring destination for the attachment file AF. On the other hand, if there is no request for creating a new folder, the specified folder name is deleted and the folder specification is canceled (#18345 to 18347). If a folder for storing the attachment file AF is not specified by the transmitting side, the utility 185 reads data of a specified length (header) recorded in the leading end of the attachment file AF as file attribute information Att (#18348). The utility 185 then searches the folder table 187 in order to check the presence or absence of the read file attribute information Att. Figure 187 shows one example of the contents of the folder table 187. In Figure 187, each code which appears in the column of header code strings (file attribute information Att) conesponds to a file name. By collating the codes listed in the column of header code strings with the code in the leading end of the attachment file AF, the folder name conesponding to the attachment file AF can be retrieved (#18349, 18350). If the file attribute information Att is found in the folder table 7, the folder name conesponding to the file attribute information Att is read and one of the dedicated folders FI to F3 having the folder name which has been read is set as the transferring destination for the attachment file AF (#18351, 18352). If the attachment file AF is, for example, a text document, the file attribute information Att is the ASCII code which conesponds to the first character of the document or a specific code (extension) given by the applications software which the operator at the transmitting side has used when creating the attachment file AF. In the latter case, the value of the specific code varies depending on the applications software which has been used. It is to be understood from the above description that, in the attachment file analysis processing, the transferring destination for the attachment file AF which is a sort of data file is set in accordance with specific data stored in the mail M, such as the directory data D12 in the envelop part ME or the file attribute information Att which is part of the attachment file AF. If the transferring destination for the attachment file AF is not set in the attachment file analysis processing, the attachment file AF will not be transfened but kept in the shared folder FO. Environment setting! Reference is again made to Figures 20 and 21. When the operator selects the environment setting function in the initial menu, the utility 185 performs condition defining processing (#1841). Figure 25 shows the flow of the condition defining processing of Figure 21. i response to an input of table data composed of the file attribute information Att and a folder name, the utility 185 firstly enters the file attribute information Att in the folder table 7 (#18411, 18412, 18415). If the dedicated folders FI to F3 do not have the input folder name, a new dedicated folder is created and the input folder name is put to the new folder. Then, the folder name is entered in the table folder 7 in combination with the file attribute information Att (#18413, 18414, 18416). According to the foregoing embodiment, the directory data D12 (a specified folder name) for instructing the management condition of the attachment file AF at the receiving side is written in the envelop part ME of which format is fixed in the electronic mail system 181. With this anangement, there is no need to decide between users where the data is to be written, unlike the case where information instructing the management condition of the attachment file AF is written in the content part MC as message information. As a result, a new user can specify a folder to the receiving side without difficulties and reading of data by the electronic mail terminal utility 185 is facilitated. According to the foregoing embodiment, since the attachment file AF is classified in accordance with the file attribute information Att originally included in the attachment file AF, there is no need to write data for instructing the management condition of the attachment file AF in every mail at the transmitting side. This saves labor in creating a mail. According to the foregoing embodiment, since the attachment files AF are classified by applications software and stored, when the attachment file AF is edited (processed) at the receiving side by the use of the same applications software as used for creating, the operation can be easily performed. Although the attachment files AF are classified at the receiving side in the foregoing embodiment, the heading files HF containing message information may be classified instead. Although the foregoing embodiment has been described with the mail M having the content part MC containing message information (heading files HF) and data information (attachment files AF), the invention can also be applied to a mail having no message information. Figure 26 is a flowchart illustrating a method 2600 for selective advertising using the mailing system of the present invention First, in operation 2602, a request is received from a user including criteria relating to advertisements utilizing a network. Next, in operation 2604, a plurality of advertisements are received from advertisers utilizing a network. Such advertisements are subsequently filtered to render only pertinent advertisements that meet the criteria, as indicated in operation 2606. Thereafter, the user is allowed access to the pertinent advertisements utilizing the network and the electronic mailing system. Note operation 2608. In one embodiment of the present invention, an identity of the user is authenticated, and the user is provided with a digital certificate that may be used for verifying the identify of the user before receiving the request from the user. In another embodiment of the present invention, the criteria includes a time frame when the advertisements are to be received, and/or a type of products. As an option, payment may be received from the advertisers in exchange for the aforementioned service. In one example, a user of the present e-mail service may go to an advertising directory and select the type of advertising\information, etc that they are willing to receive and the time frame during which they are willing to receive that information. For example, one may go to the category Trucks, to the sub category Chevrolet, to the subcategory Suburban and select that he or she wishes to receive advertisement information on Chevrolet Suburbans from March 1st through March 31st. The digital certificate may authenticate the intentions of the user, and information could then be sold to anyone interested in sending specific information related to Chevy Suburbans. The senders of the information may pay for these qualified leads, and the digital certificate provides the ability to order advertisement mail without the sender of the mail having to validate that identity of the requestor and whether he or she really wants the information. Although only a few embodiments of the present invention have been described in detail herein, it should be understood that the present invention may be embodied in many other specific forms without departing from the spirit or scope of the invention. Therefore, the present examples and embodiments are to be considered as illustrative and not restrictive, and the invention is not to be limited to the details given herein, but maybe modified within the scope of the appended claims.

Claims: CLAIMS What is claimed is: 1. A method for shipping goods, comprising the steps of: (a) retrieving an elecfronic mail address from a parcel, the electronic mail address capable of being used to transmit information over a network; (b) querying a database using the retrieved electronic mail address, the database including a plurality of electronic mail addresses and associated physical mail addresses; (c) receiving from the database the physical mail address associated with the received electronic mail address in response to the query; and (d) shipping the parcel to the physical mail address. 2. A method as recited in claim 1, wherein the network is the Internet. 3. A method as recited in claim 1 , wherein the electronic mail address includes a user name, a first level domain name, and a second level domain name. 4. A method as recited in claim 1, wherein the electronic mail address is type written on the parcel. 5. A method as recited in claim 1, wherein the database is formed by the registration of a plurality of users. 6. A method as recited in claim 1, wherein the electronic mail address is hosted by an entity which ships the parcel. 7. A method as recited in claim 1, wherein the electronic mail address is scanned from the parcel. 8. A method as recited in claim 1, wherein the database is queried via the network. 9. A computer program embodied on a computer readable medium for shipping goods, comprising: (a) a code segment for retrieving an electronic mail address from a parcel, the electronic mail address capable of being used to transmit information over a network; (b) a code segment for querying a database using the retrieved electronic mail address, the database including a plurality of electronic mail addresses and associated physical mail addresses; (c) a code segment for receiving from the database the physical mail address associated with the received electronic mail address in response to the query; and (d) a code segment for shipping the parcel to the physical mail address. 10. A computer program as recited in claim 9, wherein the network is the Internet. 11. A computer program as recited in claim 9, wherein the electronic mail address includes a user name, a first level domain name, and a second level domain name. 12. A computer program as recited in claim 9, wherein the electronic mail address is type written on the parcel. 13. A computer program as recited in claim 9, wherein the database is formed by the registration of a plurality of users. 14. A computer program as recited in claim 9, wherein the electronic mail address is hosted by an entity which ships the parcel. 15. A computer program as recited in claim 9, wherein the electronic mail address is scanned from the parcel. 16. A computer program as recited in claim 9, wherein the database is queried via the network. 17. A system for shipping goods, comprising: (a) logic for retrieving an electronic mail address from a parcel, the electronic mail address capable of being used to transmit information over a network; (b) logic for querying a database using the retrieved electronic mail address, the database including a plurality of electronic mail addresses and associated physical mail addresses; (c) logic for receiving from the database the physical mail address associated with the received electronic mail address in response to the query; and (d) logic for shipping the parcel to the physical mail address. 18. A method for shipping goods purchased from a seller utilizing a network, comprising the steps of: (a) receiving an order for goods from a buyer utilizing the network; (b) receiving an electronic mail address from the buyer utilizing the network; (c) accepting payment for the order of goods from the buyer utilizing the network; (d) applying the electronic mail address to the goods; and (e) shipping the goods, wherein a shipping entity is capable of utilizing the electronic mail address to determine a physical mail address of the buyer. 19. A method as recited in claim 18, wherein the step of receiving the electronic mail address is preceded by the step of prompting the buyer to enter the electronic mail address. 20. A method as recited in claim 18, wherein the electronic mail address is capable of being used to transmit information over the network. 21. A method as recited in claim 18, wherein the electronic mail address is type written on the parcel. 22. A method as recited in claim 18, wherein the payment is accepted using a digital wallet. 23. A method as recited in claim 18, wherein the payment is accepted using a credit card number. 24. A method for receiving shipped goods purchased by a buyer utilizing a network, comprising the steps of: (a) transmitting an order for goods from a buyer to a seller utilizing the network; (b) receiving a prompt to enter an electronic mail address of the buyer utilizing the network. (c) entering the electronic mail address for transmission to the seller utilizing the network in response to the prompt; (d) effecting payment for the order of goods utilizing the network by sending the seller an account identifier, wherein a shipping entity is capable of utilizing the electronic mail address to determine a physical mail address of the buyer for shipping the goods thereto. 25. A method as recited in claim 24, wherein the account identifier conesponds to a digital wallet. 26. A method as recited in claim 24, wherein the electronic mail address is capable of being used to transmit information over the network. 27. A method as recited in claim 24, wherein the buyer selects the goods in the order from a plurality of goods displayed on a site on the network. 28. A method as recited in claim 24, wherein the account identifier conesponds to a credit card. 29. A method as recited in claim 24, wherein the network is the Internet. 30. A method for registering a user in a database, comprising the steps of: (a) authenticating an identity of a user; (b) receiving from the user a physical mail address of the user; (c) assigning an electronic mail address to the user; (d) providing the user with a digital certificate for effecting payment during transactions utilizing a network; and (e) entering the physical mail address, the digital certificate, and the electronic mail address in a database for retrieving a physical mail address in response to the receipt of the electronic mail address, and using the physical mail address to ship goods purchased during the transactions utilizing the network. 31. A method as recited in claim 30, wherein the identity of the user is authenticated by checking valid evidence of the identity of the user. 32. A method as recited in claim 30, and further comprising the step of receiving payment from the user for the registration. 33. A method as recited in claim 30, wherein the assigned electronic mail address is selected by the user. 34. A method as recited in claim 30, wherein the identity of the user includes an age of the user. 35. A method for receiving information on a buyer during a transaction with a seller for goods or services over a network, comprising the steps of: (a) authenticating an identity of a buyer; (b) receiving from the buyer a physical mail address of the buyer; (c) providing the buyer with a digital certificate for use during transactions utilizing a network; (d) entering the physical mail address, the identity, and the digital certificate in a database; (e) receiving the digital certificate as a component of a request from a seller for information on the buyer utilizing a network; (f) querying the database for retrieving information on the identity or the physical mail address of the buyer; and (g) transmitting the information on the buyer to the seller utilizing the network. 36. A method as recited in claim 35, wherein the identity of the buyer is authenticated by checking valid evidence of the identity of the buyer. 37. A method as recited in claim 35, wherein the network is a wide area network. 38. A method as recited in claim 37, wherein the network is the Internet. 39. A method as recited in claim 35, wherein the digital certificate is provided to the seller by the buyer. 40. A method as recited in claim 39, wherein the digital certificate is provided to the seller by the buyer via the network. 41. A method as recited in claim 35, wherein the information includes an age of the buyer.

Inventors: MORRIS WILLIAN A, PETERS JOHN ERIC, MORRIS, WILLIAN, A., PETERS, JOHN, ERIC
Applicants: ACCENTURE
Application year: 2001
Main classification: G06F17
IPC codes: G06Q10, G06Q30