WO2003073337A1

WO2003073337A1 - Method and system for getting on-line status, authentication, verification, authorization, communication and transaction services for web-enabled hardware and software, based on uniform telephone address

Info

Publication number: WO2003073337A1
Application number: PCT/IB2003/000634
Authority: WO
Inventors: Oleg Serebrennikov
Original assignee: Medialingua Group
Priority date: 2002-02-27
Filing date: 2003-01-24
Publication date: 2003-09-04
Also published as: AU2003248364A1

Abstract

Methods, systems, computer data signals, recordable media and methods of doing business for wireless or wired network communication between network resources each having a unique telephone number associated therewith, including, among other feature, forming a primary number file (PNF) comprising a uniform telephone address (UTA) which has a telephone number associated with a network resource. The present invention provides a very user-friendly and seamless payment procedure wherein payer or payee only need to know accordingly the payee or payer UTA number to allow transaction and seamless payment routing between payer and payee bank accounts. The invention also allows unified approach wherein financial institution also are networking Targets having UTA numbers assigned for them and the financial institution can receive Fund Transfer Agreement or Deal Agreement from networking Targets, authenticate payer using particular Target UTA and apply the payment from this particular UTA bank account.

Description

Method and System For Getting On-Line Status, Authentication, Verification,

Authorization, Communication And Transaction Services For Web-Enabled Hardware

And Software, Based On Uniform Telephone Address

Field of the Invention

The present invention generally relates to data processing on-line communication. More particularly, the present invention relates to a system, and method for facilitating information exchange and communications with various communications devices using a telephone number.

Description of the related art

U.S. Patent No. 6,151,624 (hereinafter, "the '624 patent") of Teare et al., which is hereby incorporated herein by reference in its entirety, and which is considered by applicant to be the closest known art to the presently claimed invention, describes a system and method that facilitates the search and retrieval of network resources, such as a Web page, by utilizing a natural language name. In the case of a Web page, the system and method of the '624 patent associates a natural language name with a Uniform Resource Locator ("URL") in a metadata file which also contains additional descriptive information about the Web page. Upon entry and submission of a natural language name in a Web browser's data entry field, the system and method consults an indexed database containing metadata information in order to find the corresponding URL associated with the given natural language name. The system and method of the '624 patent thereafter send the corresponding Web page, identified by the associated URL, to the user. In this manner, the user is freed from the constraint of being required to know the complete URL of a desired Web page before being able to access the Web page.

There are, however, several drawbacks and limitations associated with the system and method described in the '624 patent. As the '624 patent itself acknowledges, a natural language name is not unique and any particular natural language name provided by a user may result in more than one Web page from which the user must select. Accordingly, the '624 patent provides additional data and network processing for resolving such conflicts.

Moreover, a natural language name may be protected by trademark or domain name registration and, accordingly, may be off-limits to a Web site administrator desirous of associating his Web site with a particularly appropriate, but legally protected, natural language name.

Moreover, the '624 patent does not address communications with other communication facilitating resources and methods, e.g., email, voice mail and PDA devices.

What is desired, therefore, and has heretofore not been available, is a system and method which allows a user to utilize unique descriptive information to identify, retrieve and interact with Web sites or other network-based resources using information that is unique and known.

Public key cryptography is an approach to enabling secure communications using key pairs. Each key pair includes a public key and a private key. The public key and private key are related so that a message encrypted by one key may be decrypted only by the other, but it is computationally infeasible to deduce the private key given the public key. The private key is typically created and securely held by an entity; while the corresponding public key is typically made widely available. Secure communications between parties may then be enabled by using the parties' public and private keys.

The use of public key cryptography addresses many of the inherent security problems in an open network such as the Internet. However, two significant problems remain. First, parties must be able to access the public keys of other entities in an efficient manner. Second, since in many protocols entities are associated with and in some sense identified by their public keys, there must be a secure method for parties to verify that a certain public key is bound to a certain entity.

A public key management infrastructure (PKI) addresses these two problems. In one common approach, the public key management infrastructure is based on digital certificates, which are used to associate a certain public key to a certain entity with some degree of integrity. The public key management infrastructure typically would include a database of digital certificates, and various operations are provided in order to access and maintain this database. For example, requests for new digital certificates are processed, digital certificates are revoked, and the status of existing digital certificates is designated and checked.

The closest art known is as follows:

US Patent 6,151,624, RealNames, does not provide interoperability between communication networks and the Internet; on-line status check; secure connectivity; support of 3G communication standards => MMS/I-mode/FOMA and unified communication and messaging.

US Patent 6,324,645, VeriSign discloses use of digital certificates, but does not detail the use of certificates for web-enabled devices; secure purchase and transaction services based on the check of Uniform Telephone Address (UTA) and dynamic Uniform Resource Locators (URL)s;

US Patent 5,793,762 titled "System and method for providing packet data and voice services to mobile subscribers", and US Patent 5,457,736 titled "System and method for providing microcellular personal communications services (PCS) utilizing embedded switches" Major difference between these patents and present invention is that besides wirehne-to-mobtle, mobile-to-wirelme, mobile-to-mobile calls the present invention is applicable to browser -to-wirehne, browser-to-mobile, mobile-to-browser and wirehne-to- browser connectivity therefore providing cross operability not only between Mobile users via Internet but also between all Mobile, Wireline and the Internet users, meaning that Internet user can be a calling party without being a mobile subscπber.

US Patent 5,732,359 titled "Mobile terminal apparatus and method having network inter-operability" addresses interoperability between mobile and satellite communication networks, but does not address interoperability between any telephone communication networks and the Internet

US Patent 6,353,621 titled "Method to allow seamless service to mobile subscπbers across vaπous mobile switching centers supporting multiple intersystem standards", describes call termination and interoperability method for mobile services generally at the level of multiple switching centers using any protocols (meaning that Internet TCP/IP is included). However, this patent does not provide the same for hardware-to-software and vice versa communication.

US Patent 5,521,962 titled "Temporary storage of authentication information throughout a personal communication system", descπbes a method for managing authentication information for mobile users reducing number of authentication information copies distπbuted within current wireless infrastructure

The known art does not contemplate a central Internet Switch repository with number files database providing interoperability between Mobile communication network, wireline and the Internet Summary of the invention

The drawbacks and functional limitations of the prior art systems and methods descπbed above are overcome by the vaπous embodiments of the present invention which provides ter aha methods, systems, computer data signals, recordable media and methods of doing business including, among other feature, forming a pπmary number file (PNF) compnsing a uniform telephone address (UTA) which has a telephone number associated with a network resource.

One particularly advantageous aspect of the invention provides a method which includes forming a secondary number file and a default number file, the secondary and default number files being mirror images of the pπmary number file, and stoπng the default number file at a switch server which provides connectivity services for the network resources and is itself a network resource, and storing the secondary number file at an internet service provider.

Another particularly advantageous embodiment of the invention provides a method which includes issuing a temporary Digital Certificates containing UTA for use in at least one Temporary Target (TT), the TT serving as a temporary Target or Mover in the network, wherein a CA Switch issues UTA and UTA DC; transfers the UTA and DC directly to Temporary Target Number File or to a reseller; and the reseller assigns the UTA/DC to a particular temporary Target Primary Number File.

Yet another particularly advantageous embodiment of the invention provides a method which includes performing session encryption, wherein Targets use shorter key pairs in order to accelerate encryption of on-line audio and video streams; and each Target issuing new pair of shorter public and private keys, storing the private key in an internal memory of the Target, the private key being used only for one session, encrypting a new shorter public key with a sending target original private key, or with a receiving target original public key, and transmitting the encrypted message to the receiving target; and receiving target decrypting the received message containing the new shorter Public Key of the sending target and uses the received sending target public key to encrypt/decrypt the session exchange with sending target.

The foregoing is a general summary of only some of the aspects of the some of the more advantageous embodiments of the invention. Detailed description of the various embodiments of the invention is set forth below, while the scope of the invention is defined by the claims.

The foregoing needs, and other needs and objects, are fulfilled by the present invention, which comprises, in one aspect, a method of locating and communicating with networked resources using a telephone number, and a location identifier, comprising the steps of storing a first telephone number of the resource in association with the location identifier of the resource; receiving a request to locate the resource containing the first telephone number; retrieving the location identifier associated with the first telephone number; and communicating with the resource using the location identifier.

One feature of this aspect involves storing at least a second telephone number for the resource, in association with the location identifier; receiving requests to locate the resource based on the first or second telephone number; retrieving the location identifier associated with the first or second telephone number; and communicating with the resource using the location identifier. Another feature involves the steps of storing the first and second telephone numbers in association with the location identifier, and in a number file in a storage device associated with the resource.

Yet another feature involves the steps of retrieving a number file including a telephone number and an associated resource; parsing the number file; building an index entry based on the values parsed from the number file; and storing the index entry in an index that is stored apart from the storage device. Still another feature is the steps of sending the number file over the network to a client associated with the resource; and storing the number file in a server storage device of a server associated with the client. Another feature involves periodically polling the number file on the server associated with the client; testing whether one of the telephone numbers stored in the number file matches a third telephone number stored in a database indexed by the index; and updating the database when changes are detected in the number file. Yet another feature is the step of synchronizing the index to the database.

According to another feature, the method includes the steps of receiving a client identifier of a client associated with the resource; generating a set of metadata that describes the resource, the location identifier, and the client identifier; and storing the set of metadata in a persistent storage device associated with the client. Another feature is assigning a randomly generated name to the set of metadata. Yet another feature is instructing the client to store the metadata in a particular authorized location in the persistent storage device. Another feature is registering the set of metadata and the randomly generated name in a database.

The foregoing is merely a brief summary of various aspects of the invention. The invention encompasses many other aspects, as set forth in the appended claims. Brief Description of the Drawings

The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:

FIG. 1 A is a diagram of a number file.

FIG. IB is a block diagram of one embodiment of a system for navigating network resources based on metadata.

FIG. 2A is a flow diagram of a method of a registration service in the system of FIG. IB.

FIG. 2B is a flow diagram of a method of activating a number file in the system of FIG.

IB.

FIG. 3 is a flow diagram of a method of operating a crawler in the system of FIG. IB.

FIG. 4 is a block diagram of an index builder service of the system of FIG. IB.

FIG. 5 is a flow diagram of a method of operating a resolver service in the system of FIG. IB.

FIG. 6 is a flow diagram of a method of operating a number finding service in the system of FIG. IB.

FIG. 7A is a diagram of an exemplary statistics report page generated by the system of FIG. IB.

FIG. 7B is a diagram of another exemplary statistics report page generated by the system of FIG. IB.

FIG. 8 is a block diagram of a computer system that can be used to implement the present invention.

FIG. 9 is a simplified block diagram of a resolution and navigating system.

FIG. 10 is a block diagram of an UTA system financial structure in accordance with an advantageous embodiment of the present invention.

FIG. 11 is a diagram of an UTA registration in accordance with an advantageous embodiment of the present invention.

FIG. 12 is a diagram of an UTA financial clearing in accordance with an advantageous embodiment of the present invention.

FIG. 13 is a diagram of an UTA transaction processing in accordance with an advantageous embodiment of the present invention.

FIG. 14 is a diagram of a credit card encryption procedure in accordance with an advantageous embodiment of the present invention.

FIG. 15 is a diagram of a credit card authorization procedure in accordance with an advantageous embodiment of the present invention

FIG. 16 is a diagram of Extended UTA usage for remote device control.

FIG. 17 is a diagram of UTA card and record samples for UTA card services.

FIG. 18 is a diagram of a sample POS purchase procedure showing UTA charge service at POS location.

FIG. 19 is a diagram of a sample UTA outgoing procedure.

FIG. 20 is a diagram of a sample UTA incoming payment procedure.

Description of the preferred embodiments.

A mechanism for associating network resources with a telephone number and locating and communicating with network resources using the associated telephone number is described. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form or otherwise explained in a manner that avoids unnecessarily obscuring the present invention.

Number File Format

In one embodiment of the present invention, metadata is associated with network resources such as a Web page, networked computers, Web-enabled appliances or wireless or other communications devices. Generally, metadata is data that describes other data. The metadata defined herein provides information that describes a Web page or other networked communication resource in a manner analogous to the manner by which a catalog card describes a book in a library. For example, the metadata includes information that provides a telephone number associated with the Web page or other networked resource, a description of the resource, a language designation of the resource, a geographical location associated with the networked resource and other information pertinent to the resource. Continuing with the example of a Web page, the metadata is defined by an administrator of the server that stores the Web pages that are described in the metadata, and a copy of the metadata is stored in association with that server so that the metadata is accessible using the Web. Using a Librarian, the copy of the metadata is registered with a database that is coupled to an index. In this manner, a Web site may be identified by typing a known telephone number (stored with associated information in a metadata) into a Web browser. Thereafter, the information in the metadata is used to resolve the telephone number into the Web site associated with the telephone number in the metadata.

As stated, the metadata may associate other communications resources, in addition to Web pages, with a telephone number. For example, the metadata may associate a telephone number with a user's instant messaging facility, wireless telephone number (when the telephone number upon which the metadata is based is a landline phone) or even a user's internet video conferencing facility. In this manner, a telephone number and associated metadata can be utilized to locate a myriad of communication facilities associated with a telephone number in addition to a Web page.

While the following description of various embodiments of the present invention deals primarily with the resolution of Web page resources using telephone numbers, it is understood that one skilled in the art would be able to easily modify, the teachings herein to accomplish resolution of other communication resources using a telephone number as described below.

Preferably, the metadata is prepared and initially stored in the form of a Number File 64 which is a text file defined by the Extensible Markup Language (XML) grammar. XML is a language definition promoted by Microsoft® Corporation and Netscape® Communications Corporation. Further information about XML is provided in "XML: Principles, Tools, and Techniques," The World Wide Web Journal, vol. 2, no. 4 (Fall 1997) (Sebastopol, Calif: O'Reilly & Assoc, Inc.).

Preferably, the text in the Number File 64 is compatible with the Resource Definition Format ("RDF") format and CC/PP (Composite Capabilities/Preference Profiles) RDF-based framework for the management of device profile information, as well as with other XML initiatives related to Web-enabled and wireless appliances' metadata description. RDF is a syntax of XML designed by the World Wide Web Consortium for expressing semantics. The text file for the metadata described herein is also called an MLS file. An example of an MLS file is set forth in FIG. 1A.

The MLS file 900 is defined according to a grammar in which information elements are surrounded by complementary tags. For example, "<resource>" and "</resource>" are complementary tags. The MLS file 900 has two general parts, namely a schema section 902, and a data section 904. The schema section 902 and the data section 904 are enclosed within complementary tags ("<xml>, </xml>") that indicate that the MLS file 900 is in the XML grammar.

The schema section 902 is delineated by the <schema> and </schema> tags. The schema section identifies the schema that is used to organize data in the data section. In the example of FIG. 1A, an "href anchor code in the schema section refers to a file, "MLS-schema", located on a Web server, that contains the schema definition. The schema is assigned the name "MLS." Tags in the MLS file 900 that are part of the MLSschema have a prefix of "MLS". Based on this prefix, the XML parser that reads the MLSfile 900 can identify tags that are part of the MLS schema.

The data section 904 is delineated by the <xml:data> and </xml:data> tags. The data section contains one or more MLS entries 905. Each MLS entry 905 is delineated by the tags <assertions> and </assertions>. Conceptually, each MLS entry 905 is a set of assertions about a network resource that is identified within the <assertions> tag. In the example of FIG. 1A, one MLS entry 905 makes assertions about the network resource home.acme.com, which for exemplary purposes is the home page of a fictional company, Acme Corporation. Of course, in accordance with the present invention, the <assertions> tag may make assertions about resources other than Web pages. For example, the <assertions> tag may define a user's instant messaging "buddy" name.

In a further embodiment of the present invention, more than one type of resource may be associated with a telephone number and the various resources made available based on the availability of a particular resource. For example, a landline telephone number of a user may be associated with that user's instant messaging "buddy" name, SMS identifier, and online video conferencing facility, e.g., Microsoft NetMeetingD. The number file defining these various resources lists the resources in a hierarchical order, e.g., instant messaging, then video conferencing, then SMS messaging and is preferably constantly updated as to the on-line availability of each of the resources in accordance with known methods. Thus, when an attempt is made to contact the user by using the landline telephone number, the resource to be utilized to facilitate contact is determined based on the defined hierarchy and the on-line availability of the particular resource sat that instances. Continuing with the above example, communication will be made via instant messaging unless the user is not "on-line" with his instant messenger at which point communications will be attempted via video conferencing. If the user is not on-line via video conferencing, communications will be made via SMS. Other communications facilities may also be offered, e.g., a voice or video message may be stored for delivery to the user.

The metadata file of the present invention provides a uniform addressing scheme based upon a telephone number. The metadata file in combination with the uniform addressing scheme allows communications between and among different types of devices operating on disparate networks. As another example, the metatdata file of the present example can be used to facilitate addressing between an internet-based video conferencing system and a mobile telephone with videoconferencing capabilities, e.g., a 3G-based mobile phone with video capabilities. In this context, a connection may be initiated by the internet-based videoconferencing user by typing the telephone number into the address bar which is resolved by the metadata file into the videophone resource.

The RDF language provides a general mechanism for describing many types of resources. RDF does not inherently provide facilities for describing Web pages. Accordingly, a Number File 64 is expressed in an RDF vocabulary that is specific to Web pages that expresses the main attributes of a Web page. The attributes include a telephone number associated with the Web page, and preferably also includes a location identifier or URL, a description, a language attribute, a region attribute, and a listings attribute. Of course, one skilled in the art will appreciate that other attributes may be utilized for non- Web page resources as appropriate.

Each MLS entry 905 has a set of metadata 906. In the example of FIG. 1 A, the metadata 906 contains a value that identifies the telephone number associated with the resource. The real telephone number value, "212-555-1234" is between the <telnumber> and <telnumber> tags. The metadata 906 also includes a description value, a language identifier value, and a region identifier value. A pair of tags delineates each value. For example, in FIG. 1A, the description value is "Home Page of Acme Corporation," the language value is "English," and the region value is "Global." The description value provides a description of the network resource that is associated with the real telephone number which, in the present example, may be the main corporate telephone number for Acme Corporation. In accordance with the present invention, the telephone number may include an area code or a country code, and may include numeric, alphanumeric or mixed prefixes or extensions, e.g., 1-800-USA-RAIL, or any other type of symbol commonly used with telephone numbers. FIG.16 provides example of Extended UTA usage for "smart home" control wherein each device in the household has a particular local UTA extension assigned for it, such as +1-212-123-4567-ALARM for ALARM system.

When multiple resources are defined in one MLS file, it is preferred that for security reasons, each network address declared for a resource must be related to the shortest network address that is declared in the MLS file for any resource. In the preferred embodiment, each network address must be logically subordinate to or descended from the network address in the MLS file that is shortest in characters. For example, in the excerpt provided in FIG. 1 A relating to Web pages, all subsequent resource declarations would be required to identify network addresses that specify files located within the directory tree for which www.medialingua.com is the root node. This relationship is checked by the Registration Service 22 when the MLS file is initially created.

Of course, as described above, a non- Web page resource, e.g., an email address or a "buddy" identifier from an instant messaging buddy list, may be the resource defined in the MLS file.

Another key advantage of this mechanism is that it can be used to provide access to network resources using multiple telephone numbers. One or more Number Files 64 are established. The Number Files 64 store a plurality of entries. Each of the entries stores a telephone number associated with a certain one or more network resources in association with the <telnumber> field. However, each of the entries references the same network resource in association with the <resource> tag.

For example, one or more Number Files 64 have entries that respectively store a telephone number for Acme Corporation such as the main number for the legal, marketing, engineering and sales departments. Each entry identifies the same network resource. Accordingly, the entries establish a plurality of telephone numbers, all of which point to, or resolve to, the same network address. When a third party wishes to access the referenced network resource, the third party uses whatever telephone number of the network resource that is known to the third party. The Resolver 40 will resolve the telephone number, regardless of which telephone number is entered, to the same network address. Accordingly, a user can locate and access network resources using any one of a plurality of known telephone numbers.

In an alternative embodiment, the attributes also include a listings attribute set off by the tag <MLS:listings>. A listings attribute is one or more keywords or other values that describe other properties of a resource. For example, each resource has a subject property that identifies the general nature of the product, service, or organization that is associated with the resource. This enables the database to be organized like a " yellow pages" directory. As an example, Acme Corporation includes in its NumberFile 64 the line <MLS:listings>Anvils, Rockets, Slingshots to indicate that it is a manufacturer of anvils, rockets, and slingshots.

In an alternative embodiment, the resources described in the Number File 64 are persons rather than Web pages. A resource of type "person" has metadata including a mailing address, email address, and other personal information. In this embodiment, the system can be used as a person locator service rather than for navigating to Web pages or other network resources.

As an example, a resource of a person locator service may include links to Web pages whereby a user may send email to the resource owner. Additionally or in the alternate, the resource may provide links that include options to send an SMS message, page or other messaging communication to the resource owner. Moreover, ftp or other links to data associated with the resource owner may be provided at the Web pages. In this manner, the telephone number in the <telnumber>field of Number File 64 acts as a "Personal Internet Address" (PIA), i.e., a unifying personal identifier that can be utilized by others to contact, send and/or gain information about the resource in a variety of ways, e.g., direct dial, e-mail, ftp downloading or uploading, messaging, chatting, sending or scheduling a task or meeting request, leaving voice mail or a video message or checking the on-line status of the PIA owner. The usefulness of the telephone number associated with the person locator service is augmented where the telephone number is both a landline and a mobile telephone number, e.g., as in "one call" services offered by various TELCO and wireless providers that automatically ring a predefined mobile telephone when there is no answer at the landline telephone.

In instances where the resource provides means for sending messages, the sender's identification may be captured from the user's computer and operating system settings. For example, when sending an email, the present system may capture the sender's identity by referencing the Window operating system's ID setting as defined in the Start/Settings/Control Panel/Users/Properties setting. In this manner, the resource to which the message is sent will have an identification of the sender whereby the resource may respond to the message.

In accordance with various embodiments of the present invention, the resources described in the Number File 64 are wireless devices , Web enabled appliances or other communication facilities other than Web pages or persons. For example, a resource of type "device" has metadata defining the device, e.g., screen size, available memory, type of communication available, mailing address associated with the device, email address, a request for resource renewal, e.g., to attend to paper refill when a networked printer (the resource) is detected to have run out of paper, and other information. In this embodiment, the system can be used as a device locator, resource availability and status service rather than for navigating to Web pages or other network resources.

In other alternative embodiments, the Number File 64 may store other or additional attributes. For example, other attributes include Organization, Subject, Abstract, Type, Audience. The Organization attribute the Organization attribute the Number File 64 information that may identify an organization or company that owns or is associated with the network resource, for example, "Federated Stores Incorporated." In the Subject attribute, the Number File 64 stores information that describes the subject matter of the network resource, for example, "dogs." In the Abstract attribute, the Number File 64 stores information containing an abstract of the network resource. In the Type attribute the Number File 64 stores information describing a type of the network resource, for example, " RealAudio file". In the Audience attribute, the Number File 64 stores information describing the intended audience of the network resource, for example, "Women age 19-34".

Defining metadata for a network resource, associating the metadata with a network resource, and storing a copy of the metadata on a server that contains the network resource in this manner offers significant advantages. For example, maintenance of the metadata is convenient. Since a copy of the metadata is stored locally on the server that contains the network resource, the metadata can be updated at any time without contacting a central service. As described further herein, a metadata crawler mechanism periodically visits the server to monitor changes in the metadata. If a Number File 64 has changed, after validation, the changes are automatically propagated to the database and the index.

In addition, in combination, the Number Files 64 operate as a distributed database of metadata. Maintaining a distributed database enhances scalability, because modifying the metadata is not dependent upon the availability of a single centralized database. Further, by storing the metadata files in association with the server of a device on which the network resources are located, data integrity is improved. Only a user having authorization to store files on a server can create metadata mappings that reference network resources on that server.

Of course, one skilled in the art will appreciate that the metadata may, alternately or in addition, be stored at a central database. The central database may be periodically updated by the various respective network servers that contain the resource or information about the resources, or may be manually updated by a central administrator.

Yet another advantage is multi-lingual compatibility. The XML language supports the UNICODE character encoding standard. As a result, attributes stored in a Number File 64 can be expressed in any human language. Telephone Number System

Using the metadata stored in Number Files 64, in combination with a network resource locating system, attributes of a network resource can be used to locate and communicate with the network resource. For example, as described above, the telephone number attribute of a Number File 64 can be used to locate a Web page. FIG. IB is a block diagram of an embodiment of a network resource locating system comprising a Registry 10, a Librarian 20, an Index 30, and a Resolver 40. One skilled in the art will appreciate that variations in the presently described network resource locating system may be realized for resources other that Web pages.

It is understood that as used above and hereinafter, the term "network address" refers generally to an unambiguous identifier of the location of a network resource, one example of a network address being a URL.

The Registry 10 includes a database 12 in the form of a commercial database system, such as the SQL Server, or a proprietary database. The Registry 10 provides a centralized storage point for mappings of telephone numbers to network addresses or URLs, as well as descriptive information associated with the telephone numbers. By definition, each telephone number is unique across the Internet or any other communications network and, therefore, is unique within the Registry 10. The Registry 10 operates as a centralized, highly robust, and scalable persistent storage area for all metadata. The Registry 10 also stores statistics related to the usage of the metadata in the context of various services that are built on top of the Registry, such as the GO navigation system described herein.

Telephone numbers, network addresses, and the descriptive information are loaded into the Registry 10 by the Librarian 20. In the preferred embodiment, the Librarian 20 and the Index 30 communicate with the database 12 using an ODBC interface. In the preferred embodiment, the database 12 has a capacity on the order of several hundred million entries. The Registry 10 and database 12 help ensure a consistent structure and vocabulary across Web sites or other utilized resources.

The Librarian 20 has a Registration Service 22 and a Crawler 24, each of which is coupled to the database 12 and to a network such as the Internet 50 or other communication networks. The Registration Service 22 receives new mappings of telephone numbers to network addresses, and descriptive information, and loads them into or "registers" them with the Registry 10. The Registration Service 22 receives the mappings from a client 70 over the Internet 50. The Crawler 24 traverses or crawls the Internet 50, periodically connecting to registered Web servers that are connected to the Internet, to locate changes to the mappings stored in or in association with the Web servers. The telephone number system interacts with one or more Web servers or other resources that are connected to the Internet 50. As an example, one Web server 60 is shown in FIG. IB, but any number of Web servers can be used in connection with this embodiment. A local database 62 is coupled to the Web Server 60 so that the Web Server can retrieve values from the local database for use in Web applications running on the Web Server.

A Number File 64 is also stored in association with the Web Server 60 such that the Web Server can retrieve the Number File and forward its contents to the Internet 50 in response to a request. In the preferred embodiment, the Number File 64 stores one or more telephone number entries. Each telephone number entry contains a telephone number of a resource in the Web Server 60, a description of the resource, a network address, or other identifier of the location of the resource, and other information about the resource such as its language and intended geographic region of use. Preferably, the Number File 64 also stores an identifier of a grammar that is used to format the other information in the Number File. In this way, the information in the Number File is self-describing and language-independent.

As indicated by path 29, the Crawler 24 can contact the Web Server 60 and retrieve values stored in the Number File 64 using a connection through the Internet 50. As indicated by path 28, the Crawler 24 can notify the Index 30 that the Index Files 34 need to be updated to reflect a change in the information stored in the Number File 64.

The Index 30 is coupled to the Registry 10. The Index 30 comprises an Index Builder 32 and one or more Index Files 34 that contain an index of all telephone numbers, telephone number entries, and resources known to the system. For example, the Index Files 34 has index entries for values stored in the Number File 64. The Index Files 34 are constructed, managed, and updated by the Index Builder 32.

Generally, in the preferred embodiment, the Index Files 34 are more compact than the indexes maintained by conventional search engines, because the amount of information represented in all the Number Files 64 is far less than the total content of all network resources available on the Web. Such compactness is a distinct advantage, providing greater scalability and responsiveness than conventional search engines. In addition, the compact size of the Index Files 34 allows the Index 30 to be replicated in multiple different geographic locations.

The Resolver 40 comprises one or more resolver processes RI, R2, Rn, each of which is coupled respectively to a Service 42, 44, 46. Each resolver process RI, R2, Rn communicates with its respective Service 42, 44, 46 to receive requests containing a telephone number, convert or resolve the telephone number into a network address associated with the telephone number, and forward the network address and other information associated with the telephone number to the requesting Service. A client 70 is coupled to the Internet 50. The client is a computer, server, Web enabled appliance or wireless device or network in which a Web browser 74 runs under control of an operating system 72. An example of the Web browser 74 is Netscape Communicator. RTM., and an example of the operating system 72 is Microsoft Windows 95.RTM.. The services of the telephone number system are accessible to the client 70 over the Internet 50 using the browser 74 according to standard telecommunication or Internet and Web protocols.

For example, under control of the browser 74 and the operating system 72, the client 70 can establish an HTTP connection through the Internet 50 to the Registration Service 22. The browser 74 retrieves pages or forms from the Registration Service 22 that are prepared in the HTML language. The browser 74 displays the pages or forms. A user of the client 70 reads the pages, or enters information in a form and sends the filled-in form back to the Registration Service 22. In this way, the client 70 and the Registration Service 22 carry out a dialog by which a user of the client 70 can perform functions offered by the system.

Preferably, the Registration Service 22, Crawler 24, Index Builder 32, and Resolver 40 are one or more computer programs having the functions and procedures described herein. In one embodiment, each of the Registration Service 22, Crawler 24, Index Builder 32, and Resolver 40 is an independent process, and one or more instance of each such process can be active and executing at a given time. In the preferred embodiment, the computer programs are constructed using an object-oriented programming language and related tools, such as the Java., language.

The Registration Service 22, Crawler 24, Index Builder 32, and Resolver 40 preferably execute on one or more server computers that can rapidly access, manage, and update the database 12 and index files 34. The foregoing elements can be distributed or segregated. For example, it is contemplated that the Resolver 40 and its processes RI, R2, Rn execute on one server computer, and the Registration Service 22, Crawler 24, and Index Builder 32 operate on the same computer or on a set of computers separate from the server that hosts the Resolver 40. In this configuration, the Resolver 40 can rapidly receive and respond to client requests for access to network resources that are indexed in the Index Files 34, without affecting or interfering with the other elements and their functions.

In one embodiment, the Librarian 20, and other functions of the system, are accessed by connecting the client 70 to one or more administrative Web pages 80 that implement the functions, using an HTTP connection. The administrative Web pages 80 are hosted on a Web server and are generated by a Web server application that can communicate with the other elements of the system. The Web server application sends a top-level page to the client 70. The browser 74 of the client displays the top-level page, which presents a menu of options for working with the system. For example, preferred menu options are set forth in Table 1. TABLE 1

TOP LEVEL MENU OPTIONS

MLS FILE Create Activate Modify Delete

STATS & BILLING Stats Billing

CUSTOMER New Customer Modify Profile Change Contacts Logout

Each of the top level menu options can be selected by moving the cursor generated by the client 70 over the name of the desired option, using the client's pointing device, and clicking on the desired option. The functions carried out by selecting each menu option are described below in the context of the functional module that carries out the functions.

In the preceding discussion, the elements of the system have been described with respect to the Internet 50 as an interconnecting element. However, the Internet is merely one example of an interconnecting element that can be used to facilitate communication among the elements of the system. Other elements, such as local-area networks, wide-area networks, other wired and wireless networks, Intranets, and extranets can be used. Also, the protocols that define the Internet, such as Transmission Control Protocol and Internet Protocol, are not required; other protocols are suitable and can be used.

In this configuration, the system has numerous advantages over prior approaches. For example, customer Web sites 60 are isolated from the database 12. The Index Files 34 are separate from the database 12 and only the Index Files are accessed by the Resolver 40. This reduces database loading and increases responsiveness, and provides scalability. The architecture is well suited to distributed replication of the Index Files. Customer Profile Functions

In one embodiment, the system provides a set of customer information management functions that store, track, and update information about customers of the system. The information managed for each customer is called a customer profile. The customer profiles are stored in the database 12.

When the Customer/New Customer option is selected, the system generates one or more Web pages containing forms that enable a user to enter a new customer profile. The form has fields for entry of a name, address, telephone number, contact person, and payment method. The Web pages and forms are communicated to the client 70 and displayed by the browser. The user of the client 70 enters appropriate information into the data entry fields and clicks on or selects a "SUBMIT" button on the Web page. In response, the client 70 returns the filled-in form in an HTTP transaction to the system. The system extracts the entered information from the fields and stores the information in a table of the database 12.

In the preferred embodiment, the Customer/New Customer registration process is initiated using a Web page generated by the system in the form shown in Table 2: TABLE 2-REGISTRATION HOME PAGE

Welcome to the Telephone Number System registration site. Before you can submit your Telephone Number, you need to provide us with some information about you and the organization that you may represent.

To initiate the registration process, you first need to enter your email address as your login name, and select a password.

You will need to remember this login name and password, as the Telephone Number System uses them to grant you access privileges.

Name Password [BACK] [NEXT]

In Table 2, the designations [BACK] and [NEXT] represent function buttons. The user enters the user's email address in the Name field, and a user-selected password in the Password field. When the user clicks on the NEXT function button, the Name and Password are stored in the database 12 in association with one another.

Preferably, the system then displays a Web page containing a form that enables the system to receive further information about the user. The form may have fields for entering the user's name, address, city, state, postal code, nation, and telephone number, instant messaging or buddy list identification, e-mail address, mobile and fixed line service providers, equipment type and model number. The user enters the requested information and clicks on a NEXT button. Alternately, or in addition, certain of the information may be retrieved from information already available at the user's computer, e.g., preferred language settings or country and area code information stored in the user's Web browser or in the user's Windows® operating system. The system checks each value to verify that it matches the proper data format required for the corresponding field. The values are stored in the database 12 in association with the user's name and email address. Collectively, this information is the customer profile. Once the customer profile is established, the user can create telephone number entries and store them in one or more Number Files 64.

Selecting the Customer/Modify Profile option causes the system to generate a Web page containing a form that enables a user to change a previously entered customer profile. To ensure secure operation, the user's IP address is extracted from the HTTP transaction that the user used to request the Customer/Modify Profile option. The user is permitted to view and modify only that profile that corresponds to a previously created Number File that is stored on a server having the same IP address as the user. Based upon the user's IP address, the system looks up the corresponding profile in the database 12 and retrieves the contents of the profile. The contents of the profile are displayed in the Web page.

The user may then move the cursor generated by the client 70 to any of the data values displayed in the Web page and enter modifications to the values. When the user selects or clicks on the "SUBMIT" button, the Web page containing the filled-in values are returned to the system in an HTTP transaction. The system updates the database 12 using the values in the page.

Selecting the Customer/Change Contacts option enables the user to change the billing contact associated with a registered Number File. Selecting the Customer/Logout option enables the user to terminate the current session, or log in as a different customer. These functions are provided using a Web application that receives and loads appropriate values into the Registry. Registration Service

FIG. 2A is a flow diagram of an embodiment of a preferred method of operating the Registration Service 22 of the Librarian 20.

Preferably, the Registration Service 22 has a Web page interface by which one or more clients 70 can access functions offered by the Registration Service by selecting function buttons of the Web pages to activate the functions.

The primary function offered by the Registration Service 22 is registration of new telephone numbers into the Registry 10. In one embodiment, the Registration Service 22 is invoked by selecting the Create option from the top-level menu page. As shown in block 200, an external user or "customer" of the system identifies himself or herself to the system so that information entered later can be associated with the customer. This information includes an electronic mail address of the customer whereby messages can be directed from the Registration Service 22 to the customer over the Internet 50. In this context, the terms "customer" and "user" refer to the operator of a computer remotely connected to the system, for example, the client 70.

As indicated in block 202, the customer then provides information to the Registration Service 22 that identifies a network resource of the Web Server 60, by its location, its telephone number, and descriptive information about the network resource. For example, the customer enters the telephone number "212 555 3000" (the main number for the company named XYZCorp), the URL http://www.xyzcorp.com, and a description about the resource. Preferably, this information is entered in fields of a Web page that is constructed for the purpose of receiving the information, in the form shown in Table 3: TABLE 3

TELEPHONE NUMBER ENTRY PAGE

Telephone Number: 212-555-3000 URL: http://www.xyzcorp.com. Type: company Language: English Region: North America

Description: This is the home page for the widget manufacturers, XYZ Corp. [BACK] [NEXT]

When the user has entered all the information, to continue processing of the Number File 64, the user clicks on the NEXT function button at the bottom of the page.

In response, at step 203, the system initiates a review service whereby a cost of providing the described resolution service is calculated. As an example, a flat fee may be charged based on the expected number of resolutions for a certain resource on a per month basis. The expected number of hits for any particular site may be based on a recorded history of past activity at the site. As an example, MSN provides a service that documents the number of hits at various Web sites on a per month basis. By referencing this database, the system may determine how many hits will be expected at the Web Site identified by the user and the system may charge the user accordingly, either in advance or on a forward-looking basis.

At step 203A, the user is informed of the charge for providing the resolution service and either refuses the charge and exits the program or accepts the charge and proceeds to step 204.

At block 204, the Registration Service 22 constructs a Number File 64 based on the information entered by the customer. At this point, the Number File 64 is stored on a server accessible to the Registration Service 22. However, the Number File 64 is not yet stored in association with the Web server 60.

In block 205, the Registration Service 22 generates a file name at random for the Number File 64. A random file name is used in order to prevent unauthorized programs, processes, or users from identifying or modifying the Number File 64 when it is stored in association with the Web Server 60. If the same file name was used, at any Web server registered with the Registry 10, an unauthorized user could modify an entry stored in the Number File 64 to reference a different network resource. Eventually, as will be discussed further below, the Crawler 24 would detect the modification and store the telephone number in the Registry 10. Accordingly, it is desirable to hide the name of the Number File 64 from all unauthorized users.

In block 206, the Number File 64 is sent as a file attachment to an electronic mail ("email") message to the customer. Block 206 includes the step of receiving an email address from the user. In the preferred embodiment, the system displays a Web page having a data entry field for the email address, in the form shown in Table 4: TABLE ■

EMAIL ENTRY PAGE

Please enter your email address so that we can send you the telephone number file that you have just built.

joe@xyzcorp.com [BACK] [NEXT]

After sending the Number File 64 in an email to the user, the system displays a confirmation page at the client 70. In the preferred embodiment, the confirmation page has the form shown in Table 5.

TABLE 5

CONFIRMATION PAGE

Your Telephone Number File has been mailed to the address joe@xyzcorp.com. You should now save this file on your Web site according to the instructions in the email that you will receive. Once this step is accomplished, the file will have to be activated through the Telephone Number file activation service. (Simply follow the previous link, or in Customer Service, look for the menu item Activate under the MLS File category.) [FINISH]

In block 208, the customer installs the Number File 64 in the Web Server 60 or in a manner that is accessible to the Web Server. Preferably, the Number File 64 is stored in a location on the Web Server 60 that is specified by the Registration Service 22. For example, the email specifies that the Number File 64 shall be stored in the root directory of the network resource that is named in the Number File 64. This is done to ensure that the receiving customer individual is authentic; the Registration Service 22 presumes that only an authentic customer representative would have root directory access to the Web server on which the named network resource is located. The root directory is also specified for the convenience of the customer. When the Number File 64 is stored in the root directory of the Web server, the customer can modify or reorganize the Web server without affecting the Number File. Conversely, if the Number File 64 was stored in a subordinate directory of the Web server, then there would be a risk of disabling the Number File by accidentally deleting its directory.

In block 210, the customer confirms to the Registration Service 22 that the Number File 64 has been stored in the specified location by the customer. The customer confirmation can be provided in an email directed to the Registration Service 22 or by entering an appropriate command using the Web interface of the Registration Service 22.

Thereafter the user is required to activate the Number File. Activation is a process of verifying that the Number File is stored in the correct location by an authorized user. Optionally, the activation process also includes the process of arranging payment for the privilege of having a registered Number File recognized by the system. One embodiment of an activation method is shown in FIG. 2B. In the preferred embodiment, the user activates a Number File after creating it by selecting the MLS File/Activate function from the top-level menu option list. In response, as shown in block 212, the system constructs a page that requests the user to enter a type of activation, and sends the page to the client, which displays it. For example, the system displays a page of the form shown in Table 6: TABLE 6

ACTIVATION TYPE SELECTION PAGE

Please select the appropriate service: (*) Live update of a previously registered Number File. (*) Registration of a new Number File on your website. [BACK] [NEXT]

Preferably the symbols shown in the form "(*)" in Table 6 above are displayed as radio buttons, or another graphic element, that can be selected by the user. When the user selects the first option ("Live update of a previously registered Number File"), as shown in blocks 214-216, the system activates the Crawler, which locates the user's Number File over the Internet, and updates the database 12, as described below. Thus, the "Live update" function provides a way for a user to force the system to locate a modified Number File and update itself with the new information. Alternatively, as described below in connection with the Crawler, the user may simply wait and the Crawler eventually will locate the modified file and update the database.

When the user selects the second option ("Registration of a new Number File on your website"), as shown in blocks 220 to 222, in response the system constructs and sends to the client 70 a Web page with which the user can enter payment information pertaining to the user and its Number Files in accordance with the amount calculated and actions taken at steps 203 and 203A. Payment steps of the activation process are an entirely optional part of the process, and other embodiments are contemplated that omit any payment mechanism including those relating to steps 203 and 203A. In the embodiments that do use a payment mechanism, the Web page contains fields that accept entry of payment information. For example, the fields enable entry of a credit card type, card number, expiration date, and cardholder name. The system receives the payment information values in block 224.

In block 226, the system prompts the user to enter the network address of the Number File to be activated, and a description of the Number File. In block 228, the Registration Service 22 establishes an HTTP connection to the Web Server 60, requests and uploads a copy of the Number File 64. This step is carried out to verify that the Number File 64 is valid and is stored in the correct location. In block 230, the Number File 64 is parsed, and values identifying the network resource are extracted. In block 232, the system constructs a Web page that displays all the entries parsed from the current Number File 64, and sends the page to the client 70. Within the Web page, the system displays a prompting message, such as the following:

"The Number File that we have downloaded from your site contains the following entries. Please verify these entries are correct. Press NEXT to continue.

[BACK] [NEXT]"

As shown in block 234, the user reviews the entries, verifies that they are correct, and clicks on the NEXT function button. If any of the entries is not correct, the user clicks on the BACK function button, which provides access to the MODIFY function described herein.

In the preferred embodiment, the system then displays a Web page containing a written legal agreement governing payment of registration fees and resolution of disputes involving other issues such as legal issues, as shown in blocks 236-238. The agreement concludes with function buttons labeled ACCEPT and DECLINE. To accept the terms of the agreement and proceed with registration, the user clicks on the ACCEPT button. To decline the terms of the agreement and discontinue the activation process, the user clicks on the DECLINE button. Use of the legal agreement is entirely optional and embodiments that do not use such an agreement are contemplated and are within the scope of the invention.

The system then stores values parsed from the Number File 64 in the database 12 of the Registry 10, as shown in block 240.

For security reasons, the network address or URL of the Number File 64 must match the root directory of the Web server 60. This prevents redirection of telephone numbers to unauthorized different network addresses. It also prevents the owner of the Web server 60 from redirecting to that Web server any telephone number that he or she does not own.

In block 242, the Registration Service 22 notifies the Index Builder 32 that a new entry has been made in the database 12. Path 26 of FIG. IB represents the notification. The notification includes information sufficient to identify the new entry in the database 12, for example, a row identifier ("rowid") of a table in which the new entry is stored. In response, the Index Builder 32 carries out a live update of the Index Files 34, in the manner discussed further below. Thus, the Number File 64 created by the user is activated and available for use by the Resolver 40.

In the preferred embodiment, the database 12 is available to receive queries from registered members of the system. As a result, a registered member can submit queries to the database 12 that request the database to display currently registered information about network resources or Web pages of other organizations. Accordingly, if another registered user succeeds in registering information that misrepresents the content of that user's network resources, the misrepresentation can be reported to the Registry for corrective action. Thus, in this manner, the formality of the registration process, and the open query capability of the database 12 enable the present system to avoid the deception that is possible through the improper use of metatags. Modifying and Deleting Number File Information

After a Number File is created having one or more entries, the entries can be edited or deleted using the MLS File/Modify and MLS File/Delete functions shown in the top-level menu list.

When the user selects the MLS File/Modify function, the system reads the MLS file from the server associated with the user, and displays the contents of the file in a Web page having the form shown in Table 7 TABLE 7

MLS FILE/MODIFY PAGE DISPLAY

The current list of MLS entries contained in your MLS file is shown below. To edit an entry, select the appropriate word and press EDIT. To delete an entry, select the appropriate word and press DELETE. To add a new MLS entry, press ADD. Press NEXT when you are done editing the MLS file. [BACK] [EDIT] [DELETE] [ADD] [NEXT]

Telephone Number: 212-555-3000

URL: http://www.xyzcorp.com

Type: Company

Language: English

Region: North America

Description: the home page for widget manufacturer, XYZ Corp.

Selection:

Telephone Number: 212-555-1234 URL: http://www.acme.com

Type: Company

Language: English

Region: Global

Description: Home page for Acme Corp

Selection:

The page consists of a text instruction section, a set of editing function buttons, and a list of entries currently contained in the Number File. The text instruction section explains the functions carried out by the editing function buttons. In the preferred embodiment, the function buttons of this page operate on entire Number File entries rather than individual fields within each entry. For example, to edit an entry, a user selects the appropriate telephone number, such as "212-555-1235" and presses the EDIT function button. In response, the system displays an entry editing page that contains the selected entry. The user can enter modified text in fields of the entry editing page.

Similarly, to delete an entry, the user selects the appropriate word and presses the DELETE function button. In response, the system constructs a new Number File that contains all the prior entries except the entry selected for deletion.

To add a new entry to the currently displayed Number File, the user clicks on the ADD function button. In response, the system displays a page in the form of Table 3 discussed above in connection with creating a new Number File.

To apply changes made in the EDIT, DELETE, or ADD operations, the user presses the NEXT function button. Selecting the NEXT function button causes the system to construct a new Number File, preferably in the above-described XML format. The system emails the new Number File to the user in an appropriate explanatory message. For security reasons, the user is required to store the new Number File in a directory specified by the system, as in the case of creation of a new file. Crawler

FIG. 3 is a flow diagram of an embodiment of a method that is preferably carried out by the Crawler 24. In the preferred embodiment, the system includes a Scheduler process that triggers activation and execution of the Crawler 24. For example, the Scheduler stores a schedule of events. An event states that the Crawler 24 should execute every twenty-four hours. Upon the occurrence of a scheduled event, the Scheduler launches the Crawler 24.

In block 302, the Crawler 24 reads the database 12 of the Registry 10 and retrieves one or more rows or records that identify network resources that are indexed in the Index Files 34. The protocol for selecting the rows or records is not critical, and several different schemes can be used. For example, the Crawler 24 can select all rows or records that have not been updated since the last time that the Crawler executed. Alternatively, the Crawler 24 can select all rows or records that have been created within a specified time frame or that are older than a particular number of days. In still another alternative, the Crawler 24 selects the least recently updated record. In a preferred embodiment, the system includes a mapping of telephone numbers to MLS file names and locations called the File Info table. The Crawler matches the selected rows to the File Info table and locates the network address, location or URL of the Number File associated with each telephone number, row or record.

For each of the selected rows or records, in block 304, the Crawler 24 polls the customer Web site that is represented by the row or record, searching for updates to the Number File 64 that is stored in association with that Web site. The polling step includes the steps of opening an HTTP connection to the Web site, requesting and receiving a copy of the Number File. The Crawler 24 parses the Number File, using an XML parser, to identify telephone number entries, and values within each telephone number entry, that specify the telephone number, network address, and descriptive information relating to network resources. An XML parser is commercially available from Microsoft® Corporation.

For each entry in the Number File, as shown in block 306, the Crawler 24 tests whether the entry matches a row or record in the database 12. Thus, the Crawler 24 determines whether the contents of the Number File are different from entries in the database 12. If so, as shown in block 308, then the Crawler 24 updates the database 12, and requests the Index Builder to rebuild the index entry associated with the updated row or record in the database 12.

In this way, the Crawler 24 polls Web sites on the Internet 50 to locate customer sites that have updates. Because the Number Files are distributed across the network at numerous customer sites, each customer has the freedom and flexibility to modify its Number File at any desired time. The customer need not notify the telephone number system, because the Crawler 24 will eventually locate each change and update the database 12 accordingly. Thus, the Librarian 20 automatically monitors changes to Number Files distributed across the network, and periodically updates the Registry 10 with the change. Advantageously, customers or end users are not involved in updating the database 12; the Crawler 24 updates the database automatically.

In the preferred embodiment, a customer can instruct the Librarian 20 to immediately execute the Crawler 24 with respect to a specific Web site. In this way, changes to a particular Number File are immediately identified and loaded into the database. The customer activates immediate execution of the Crawler 24 by selecting the Live Update option from the top-level menu. In the preferred embodiment, the system also carries out, once weekly, a comprehensive update of the Index Files 34 based on the contents of the database 12. In this way, at least weekly, the Index Files 34 are rebuilt based on the current contents of the database 12.

In an alternate embodiment, the Crawler 24 also validates each of the network resource locations that are identified in each Number File. For example, the Crawler 24 attempts to connect to and load each network resource that is identified in a Number File entry. If an error occurs, an appropriate email message is composed and sent to the contact person of the organization that registered the Number File. The email message advises the contact person that the network resource location in the Number File is invalid. Index Builder

The Index 30 comprises an Index Builder 32 and Index Files 34. The Index Builder 32 is a software program or process that operates in two modes. In the first mode, a Reconstructor process of the Index Builder 32 periodically polls the database 12, discovers changes to the database, and indexes the changed telephone number records in the Index Files 34. In a second mode, the Index Builder 32 updates the Index Files 34 in real time, based upon a queue of requests to update the indexes. FIG. 4 is a block diagram of a preferred embodiment of the Index Builder 32. Computers labeled GO Machines 100, 102, 104 each run an instance of the Index Builder 32. Each GO Machine 100, 102, 104 is associated with a network interface process Ml, M2, Mn of a Queue Agent 92a. The Queue Agent 92a is coupled to a network 106, such as a local area network, and receives requests to build index entries from the Librarian 20. The Queue Agent 92a propagates a copy of each request to one of the network interfaces Ml, M2, Mn, which forwards the request to its associated GO Machine 100, 102, or 104. This architecture is highly responsive to external queries, and is fault-tolerant.

Within each GO Machine, the Index Builder 32 is coupled to a pair of queues 90a, 90b and a pair of indexes 34a, 34b. The GO Service 42 can access either of the indexes 34a, 34b, but always accesses only one of the indexes at a time. The Resolver 40 is omitted from FIG. 4 for clarity, but it should be understood that the GO Service 42 accesses each index 34a, 34b through a Resolver 40 process.

It is important for the GO Service 42 to be in constant communication with one index or the other. Accordingly, using the architecture shown in FIG. 4, the Index Builder builds the indexes using the following process. The GO Service is placed in contact with index 34b and instructed to communicate telephone number resolution requests only to index 34b. As index build requests arrive from the Queue Agent 92a at the Index Builder 32, the Index Builder 32 adds the requests to both of the queues 90a, 90b. When one of the queues is sufficiently full, for example, queue 90a, the Index Builder 32 sequentially removes entries from the queue, in first-in- first-out order, and updates the index 34a with each queue entry. Concurrently, if any new index build requests are received, they are routed to both of the queues. When the queue 90a is empty and the index 34a is fully updated, the Index Builder 32 instructs the GO Service 42 to communicate telephone number resolution requests only to index 34a. The Index Builder 32 then removes entries only from queue 90b and updates only index 34b from that queue. Thus, the Index Builder 32 can add index entries to either of the queues 90a, 90b, but always updates only one index at a time using the contents of only one of the queues at a time. The queue with which the Index Builder 32 communicates is always the opposite or complement of the indexes 34a, 34b with which the GO Service 42 is currently communicating. In this way, the GO Service 42 constantly communicates with an index, and the Index Builder 32 can update the index in real time without disrupting telephone number resolution operations.

Preferably, the index build requests comprise an identifier, called a Fileld, of a file or row that is mapped in the File Info table described above. The Index Builder 32 looks up the FilelD in the File Info table and retrieves all entries in the database that match the FilelD. Each database entry includes a unique identifier that is associated with a network resource that is described in the database entry. The unique identifiers are generated using a sequence facility of the database server. Based on the unique identifier, for database entry that matches the FilelD, the Index Builder retrieves a matching index entry. The information in the index entry is compared to the information in the build request. If the information in the build request is different, the index entry is updated. If the information in the build request indicates that the associated network resource has become inactive or unavailable in the network, the index entry is deleted.

To provide scalability, reliability, and rapid response, each of the GO Machines 100, 102, 104 has a similar configuration and operates in parallel. Although three GO Machines 100, 102, 104 are shown in FIG. 4 as an example, any number of GO Machines can be used in the system. In the preferred embodiment, a Scheduler process determines when the Index Builder 32 executes. Resolver

Generally, the Resolver 40 functions as a runtime query interface to the metadata that is stored in the Registry 10. The Resolver 40 functions to receive telephone number requests from services 42, 44, 46, query the index 30 to identify network addresses corresponding to the telephone number requests, and respond to the services with the network addresses. The Resolver 40 is structured to respond rapidly to query operations and to service millions of requests per day. To maximize response time and ensure scalability, the Resolver 40 does not directly access the database 12 of the Registry 10 in responding to queries. Instead, the Resolver communicates with the Index 34 that is stored in fast main memory.

In the preferred embodiment, the Resolver 40 operates in any number of multiple instances RI, R2, Rn, each of which is associated with a service 42, 44, 46 that is making a request to the Resolver. The services 42, 44, 46 communicate with Resolver instances RI, R2, Rn using HTTP connections. Further, it is preferred to operate the computer hardware on which the Resolver 40 runs in a triple-redundancy configuration. This configuration provides rapid response to the requesting services 42, 44, 46 and provides reliability. Each instance RI, R2, Rn is implemented as an instance of a Web application that implements the Resolver. The services 42, 44, 46 communicate with Resolver instances RI, R2, Rn using HTTP connections.

In one embodiment, an instance of the Resolver 40 is implemented as a dynamically linked library (DLL) that is integrated into the services 42, 44, 46. In the preferred embodiment each instance of the Resolver 40 is a detached, separate process or program that operates according to the method shown in FIG. 5. The Resolver 40 is implemented with one or more APIs that allow the development of services that use the Resolver, such as "yellow pages" and search services.

As shown in blocks 502-504, an external Web client, server or browser, such as the client 70, accesses the Resolver 40. In one embodiment, the client 70 connects to the Resolver 40 using an HTTP connection. In block 502, the client 70 establishes an HTTP connection to the Resolver 40. In block 504, the client 70 provides a URL to the Resolver that requests the network address corresponding to a particular telephone number. For example, the URL is in the form http://www.resolver.com/resolve? tn=TELRPHONE NUMBER . In a URL of this form, "http://" identifies the URL as an HTTP request, www.resolver.com is the server domain, and "resolve" is the name of a program running on that server domain that implements the resolver. The statement "tn=TELEPHONE NUMBER" passes the value "TELEPHONE NUMBER" to a parameter "rntn" that is recognized by the resolver. In instances where the telephone numbers are stored with accompanying area and country codes, the client browser is preferably programmed to add the country and area code to a telephone number that is entered by the user without one or both of the codes. This information may derived from settings in the user's Window's operating system.

In another embodiment, the client 70 connects to one of the services 42, 44, 46 associated with an instance of the Resolver 40. The services 42, 44, 46 communicate with the client 70 to request and receive a telephone number.

Thus, in one of these ways, the Resolver 40 receives a telephone number requested by the client 70. In response, the Resolver 40 constructs a Qualifier object in main memory that contains the telephone number. In block 506, the Resolver connects to the Index 30 and submits a query requesting the network address or URL that corresponds to the telephone number in the request from the client 70. In the preferred embodiment, the query is submitted by sending a message containing the Qualifier object to an Index Store object. The Index Store object encapsulates or provides an abstract representation of the Index 30. The Index Store object executes an index query.

In block 508, the Resolver 40 receives a response from the Index 30 that contains the network address or URL that corresponds to the telephone number in the request from the client 70. In the preferred embodiment, the Index Store object returns an Entry Set object to the Resolver 40. The Entry Set object contains or references a set of one or more entries from the Index 30 that correspond to the requested telephone number. Preferably, an entry Set object is configured to supply the location or URL of a network resource described in an entry of the object.

Use of The Entry Set object allows operation when only a part of a telephone number is entered. This is particularly useful when a user of the present system knows only a part of the telephone number for which information is sought. As an example, a user who knows only the last four digits of a telephone number may enter "3421". The Entry Set object will contain all telephone number entries that end with the numbers "3421", e.g., "212-324-3421", "213-247- 3421" and "702-397-3421" and the user may then select the number or corresponding resource that is believed to be the desired resource.

The Index Store object also has logic for ordering entries in the Entry Set object based on a function of past usage. When the Entry Set object has just one entry, ordering is not needed. When the Entry Set object has more than one entry, the entries may be in using any desired method to indicate any desired ordering preference.

In block 510, the Resolver 40 formats the response of the index into an output message. In a preferred embodiment, the Resolver 40 constructs an XML file containing the information in the response from the Index 30. In the preferred embodiment, the services 42, 44, 46 each are provided with an XML parser that can convert the XML file produced by the Resolver 40 into text or other information in a format that is usable by the client 70. Also in the preferred embodiment, each entry referenced in the Entry Set object contains a usage value that indicates the number of times that the entry has been resolved. The usage values may be used to order the entries when they are displayed or otherwise used by one of the Services 42-46.

Preferably, after each telephone number resolution, the Resolver 40 writes an entry in a log file 84 that describes the telephone number, the total number of times it has been resolved in the past including the current resolution, the IP address and domain name of the client or server that requested the current resolution, and the time at which the current resolution occurred.

In the preferred embodiment, the Index 30 and the Resolver 40 execute on the same physical computer, and the Index Files 34 are stored in main memory of that computer. This configuration improves response time of the Resolver 40 by providing it with high-speed access to the Index 30. It is contemplated that the Resolver 40 will respond to several tens of millions of telephone number resolution requests per day. Also in the preferred embodiment, the Index 30 and the Resolver 40 are implemented as a plurality of Component Object Model (COM) programmatic objects that communicate with the AltaVista runtime library using AltaVista's API. The AltaVista runtime library is commercially available for license from Digital Equipment Corporation in the form of the AltaVista Software Development Kit (SDK).

In an alternate embodiment, the Resolver 40 is capable of distinguishing among network addresses that refer to resources located on the Internet, an internal business network or "intranet", and an externally accessible internal business network or "extranet". In an intranet environment, the Resolver 40 accesses a Registry 10 that is located within the organization that owns and operates the Resolver. The Registry 10 stores resource information that identifies intranet resources. This is particularly applicable for businesses having PBX-based telephone systems utilizing internal four or five digit extension dialing. The Resolver 40 resolves the telephone number or extension entered by the user into the locations of intranet resources, and navigates the user to the resources. Services

The services 42, 44, 46 can be implemented in several variations. In one embodiment, the GO service 42 is a computer program that is installed into or attached to the browser 74 of the client 70. For example, the GO service 42 is installed into the client 70 as a plug-in to the browser 74. The user downloads the GO service 42 from a central distribution site and stores the service on the client 70. The user executes an installation program that installs the service into the browser 74. Once installed, the GO service 42 intercepts telephone numbers entered by the user into the browser 74 and resolves the telephone numbers into network addresses that are usable by the browser 74.

FIG. 6 is a block diagram of a method of operating the GO service 42 in this configuration. In block 600, the user invokes or initiates execution of the browser 74. The browser 74 has a URL data entry field into which a user customarily types a network address of a document to be retrieved and displayed by the browser, such as a URL. In block 602, the user enters a telephone number into the network address data entry field. In block 604, the GO service 42 captures all keystrokes that are typed by a user into the network address data entry field of the browser 74 and thereby receives the telephone number entered by the user.

Control is next passed to block 609. In block 609, the service 42 requests the Resolver 40 to resolve the telephone number received at the browser into a network address. For example, the service 42 constructs a URL that references a pre-determined location of the system that implements the Resolver 40. The URL contains, as a parameter to be passed to the Resolver 40, the telephone number received at the browser. The service 42 opens an HTTP connection from the client 70 to the Resolver 40 using the URL that contains the telephone number. The Resolver 40 extracts the value of the telephone number from the URL, and carries out the resolution process described above. The Resolver 40 then returns the network resource location values in an HTTP message to the browser 74.

If a corresponding network resource location value is received from the Resolver 40, in block 610, the GO service 42 redirects the browser 74 to the network address found by the Resolver 40. For example, the service 42 extracts the network resource location value from the HTTP message received from the Resolver 40, and passes the value to functions of the browser 74 that can load and display Web pages. The browser 74 then loads and displays the file or page located at the network address in conventional manner. Alternatively, if more than one network resource location value is received from the Resolver 40 in response to the Resolver 40 receiving only a partial telephone number, then in block 610 the service displays a list of the network resource location values. The results are displayed in an order, from most prior resolutions to least prior resolutions, based on the resolution values compiled and stored by the Statistics Service 82. In another variation, the service returns to the client 70 an HTTP response containing an XML in which the results of the query are stored.

In an alternate embodiment, the GO service 42 is implemented as a Web application that runs on a dedicated Web server. To locate a network resource, the client 70 connects to the GO Web server using a predetermined network address or URL. In response, the Web application of the GO service 42 displays a Web page comprising a form with a data entry field. The end user types the telephone number of a network resource into the data entry field. The GO server 42 locates the network resource in the manner described above.

In another alternate embodiment, the GO service 42 is linked to a button or panel that is embedded in a Web page of an external Web server. The button or panel is anchored to a network address or URL that invokes the GO service 42 when the button or panel is selected by a user viewing the external Web server. This configuration provides a way to enter telephone numbers that does not require use of a browser.

In yet another alternate embodiment, the GO Service 42 includes a mechanism to detect and respond to the language being used by the client 70 that contacts and provides a query to the GO Service, defining the country code this way. Assume the computer that is running the GO Service 42 operates using UTF-8 character set encoding and the English language, whereas the client 70 is using the Japanese language and a different character set encoding. When the GO Service 42 sends a Web page to the client 70 that contains the telephone number entry form, the Web page includes a hidden field that stores a pre-determined text string. The client 70 receives the Web page, and its browser or operating system converts the Web page to the character set that it uses. The user of the client 70 enters a telephone number into the Web page and submits it to the GO Service 42. The GO Service 42 receives the Web page, extracts the value of the hidden field, and compares the hidden field value to a table or mapping of hidden field values to character set encodings and languages The GO Service 42 retrieves the corresponding character set encoding and language. Based on the language (country codes)., the GO Service 42 selects a resource having a matching Language value in the metadata section 906 of the resource. In this way, the system transparently determines the language of the client that originates a query, and supplies a resource that is appropriate to that language.

In another alternate embodiment, the GO Service 42 and the Resolver 40 use the values of the metadata in the Number File 64 associated with resources to respond to advanced queries. For example, assume that United Airlines registers a Number File 64 that describes resources in several different languages such as English, French, and Japanese. A user desires to locate a Web site affiliated with United Airlines that is located in France or prepared in the French language. The user enters the telephone number for reservations for United Airlines in the United states appended with the word "France" as follows: "1-800-241-6522 France," into the GO Service 42. The Resolver 40 attempts to match the entry to the Description, Region, and Language fields of the metadata section 906 associated with the United Airlines Number File 64. The Resolver 40 and the Go Service 42 redirect the user's browser to a United Airlines site presented in French.

In an alternate embodiment, when the GO Service 42 is implemented as a browser plug-in installed in the client 70, the GO Service provides character encoding information to the Resolver 40. To obtain the character encoding currently used on the client 70, the GO Service 42 calls an operating system function of the operating system that runs on the client 70. The GO Service 42 attaches the character encoding information to the URL that is used to return the user's query to the Resolver 40. In this way, the Resolver receives information indicating the language and character set currently used by the client 70, and can respond with a network resource that is appropriate to that language.

In another alternate embodiment, the computer system further includes a microphone coupled to an analog-to-digital converter. The analog-to-digital converter is coupled through an appropriate interface to the bus of the computer system. Under control of driver software or another appropriate application program, the analog-to-digital converter receives an analog audio input signal from the microphone and converts the signal to a digital representation of the signal. The driver or application program receives the digital representation and converts it into a phoneme, string of words, keyword, or command for the GO Service 42. The converted digital representation is used by the GO Service 42 as input, as a substitute for input from the keyboard or mouse. Thus, a user can view the user interface display 1000 and speak words into the microphone to command the GO Service 42 to locate a particular network resource. In this way, the user can navigate the Web using spoken words (numbers).

Another alternate embodiment is shown in FIG. 9. A Service is implemented in the form of a Web server or middle-tier Web application server 60a. The Web application server 60a communicates to the client 70 using HTTP messages through the Internet 50. The Web application server 60a includes a Common Gateway Interface (CGI) script processor, an application server such as Netscape's Kiva, Microsoft's Active Server, or Apple's WebObjects.RTM.. An application program running on the Web application server 60a communicates with the Resolver 40 through the Internet 50 over paths 40a, 40b using CGI scripts to generate HTTP requests and responses. The Web application server 60a uses calls to functions provided by the API of the Resolver 40 to communicate along paths 40a, 40b. Using this structure, the Web application server 60a issues requests containing queries to the Resolver 40. In response, the Resolver 40 evaluates the query, queries the Index 30, and creates a set of metadata for all Index entries reflecting Web pages that match the query. The set of metadata is packaged as an XML file and delivered to the Web application server 60a by the Resolver 40. The Web application server 60a has an XML parser that can parse the XML code in the XML file. Based on the parsed XML code, the Web application server 60a creates one or more HTML documents and delivers the HTML documents to the client 70. The client 70 displays the HTML documents to the end user. Statistics Service

As described above in connection with the Resolver 40, each time a telephone number resolution is carried out by the Resolver, it writes a log file entry. The system includes a Statistics Service 82 that is responsible for reading the log file and loading information from the log file into the Index Files 34.

In the preferred embodiment, the Statistics Service 82 operates periodically on a scheduled basis. The Statistics Service 82 reads each record of the log file and constructs an index object based on the information in the log file. The Statistics Service 82 then sends a message to the Index Builder 32 that requests the Index Builder to persistently store the values in the Index Files 34. In response, the Index Builder 32 stores the values in the Index Files 34.

The top-level menu page of the system has hyperlinks that enable the user to access statistics and billing functions.

When the Statistics & Billing/Statistics option is selected, the system generates a Web page 700 in the form shown in FIG. 7A. The Web page 700 has a list 702 of top-level options. A set of function buttons 704 enable the user to establish other global functions such as resolving an address, entering new customer information, obtaining customer service, and learning more information about the telephone number system.

Report function buttons 706 enable the user to access report generation functions of the system. In an embodiment, the report function buttons 706 include a Select Entries button 712, a Select Time button 714, a Report per Entry button 716, and a Report per Origin button 718.

The Select Entries button 712 is used to identify a range of entries within a Number File for which statistics are to be generated. When the user selects the Select Entries button 712, the system reads the Number File on the server having an IP address matching the IP address of the user's current domain. The system parses the Number File and displays a list of all the telephone numbers in a new Web page that is sent to the client 70. The Web page displays a radio button adjacent to each of the telephone numbers in the list. By clicking on the radio button and then submitting the Web page to the system, the system will provide statistical information for all the selected telephone numbers in all reports that are generated later.

The Select Time button 714 is used to identify a time frame for which statistics are to be generated. When the user selects the Select Time button 714, the system generates a new Web page and sends it to the client 70. The Web page includes a form into which the user enters a starting date and an ending date. When the user submits the filled-in page to the system, the system receives and stores the date values. When reports are generated thereafter, the reports will contain statistical information for resolutions of telephone numbers that occurred within the specified dates.

The Report per Entry button 716 is used to generate a report and graph showing all telephone number resolutions that have occurred for each telephone number entry defined in the current Number File. When the Report per Entry button 716 is selected, the system reads statistical information that is stored in the statistical tables of the database 12 for each of the telephone numbers that are defined in the current Number File. The system generates a graph and a chart of the statistical information, and generates a Web page containing the graph and chart.

FIG. 7A is an example of a Web page generated in this manner. The graph pane 708 shows an exemplary bar graph. Each bar in the bar graph represents a telephone number defined in the current Number File. The vertical axis 720 identifies the number (in thousands) of resolutions of each telephone number. The horizontal axis 722 identifies each Number for which statistics information is reported. The statistics pane 710 comprises a description column 730 with information taken from the Description field from the Number File, a quantity of resolutions column 732, and a percentage column 734. The description column 730 lists each telephone number and associated Description that is defined in the current Number File. The quantity of resolutions column 732 gives the number of resolutions of that telephone number that have occurred within the currently defined time period. The percentage column 734 indicates, for each telephone number, the percentage of total resolutions represented by the resolutions of that telephone number.

FIG. 7B is an example of another type of graph generated by the statistics service. The vertical axis 720 shows the number of resolutions of each telephone number. The horizontal axis 722 comprises a plurality of bars 738, each bar associated with a telephone number. The bar represents the number of resolutions of that telephone number. A second vertical axis 736 displays a number indicating the percentage of total resolutions carried out by the system that is represented by each telephone number shown in the horizontal axis 722.

In an embodiment, a fee is charged by the owner of the telephone number system to end users or customers who register telephone numbers in the Registry 10. The Librarian 20 records a charge against the account of the user when a new entry is submitted to the system using the Registration Service 22. In another embodiment, end users or customers who register telephone numbers in the Registry 10 pay a fee to the owner of the telephone number system for each resolution executed by the Resolver 40 in response to a third-party request. The Resolver 40 records a charge against the account of the user when each resolution is completed. In these embodiments, the account information and charges are logged and accumulated in tables of the database 12. Periodically, an external billing application reads the charge and account tables of the database 12 and generates invoices that are sent to the user. The Statistics & Billing/Billing Information option of the top-level option list 702 enables the user track and monitor, in real time, the user's credits and payments for registered telephone number entries, as well as resolution fees. When the Billing Information function is selected, the system reads the charge and account tables of the database 12 and generates a report, in a Web page, summarizing the charges to the customer. The Web page is delivered to the client 70 and displayed by it. Hardware Overview

FIG. 8 is a block diagram that illustrates a computer system 800 upon which an embodiment of the invention may be implemented. The system of Fig. 8 is directed to the above- described embodiments for the resolution of Web page resources using telephone numbers. One skilled in the art will appreciate that the system of Fig. 8 can be modified appropriately using known methods and components to accomplish resolution of other resources as described above, e.g., mobile telephones, PDAs, etc.

Computer system 800 includes a bus 802 or other communication mechanism for communicating information, and a processor 804 coupled with bus 802 for processing information. Computer system 800 also includes a main memory 806, such as a random access memory (RAM) or other dynamic storage device, coupled to bus 802 for storing information and instructions to be executed by processor 804. Main memory 806 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 804. Computer system 800 further includes a read only memory (ROM) 808 or other static storage device coupled to bus 802 for storing static information and instructions for processor 804. A storage device 810, such as a magnetic disk or optical disk, is provided and coupled to bus 802 for storing information and instructions.

Computer system 800 may be coupled via bus 802 to a display 812, such as a cathode ray tube (CRT), for displaying information to a computer user. An input device 814, including alphanumeric and other keys, is coupled to bus 802 for communicating information and command selections to processor 804. Another type of user input device is cursor control 816, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor 804 and for controlling cursor movement on display 812. This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a plane.

The invention is related to the use of computer system 800 for providing a telephone number-based network resource locating system. According to one embodiment of the invention, network resource locating is provided by computer system 800 in response to processor 804 executing one or more sequences of one or more instructions contained in main memory 806. Such instructions may be read into main memory 806 from another computer-readable medium, such as storage device 810. Execution of the sequences of instructions contained in main memory 806 causes processor 804 to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the invention. Thus, embodiments of the invention are not limited to any specific combination of hardware circuitry and software.

The term "computer-readable medium" as used herein refers to any medium that participates in providing instructions to processor 804 for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, optical or magnetic disks, such as storage device 810. Volatile media includes dynamic memory, such as main memory 806. Transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise bus 802. Transmission media can also take the form of acoustic or light waves, such as those generated during radio-wave and infra-red data communications.

Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, or any other magnetic medium, a CD-ROM, any other optical medium, punchcards, papertape, any other physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read.

Various forms of computer readable media may be involved in carrying one or more sequences of one or more instructions to processor 804 for execution. For example, the instructions may initially be carried on a magnetic disk of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to computer system 800 can receive the data on the telephone line and use an infra-red transmitter to convert the data to an infra-red signal. An infra-red detector coupled to bus 802 can receive the data carried in the infra-red signal and place the data on bus 802. Bus 802 carries the data to main memory 806, from which processor 804 retrieves and executes the instructions. The instructions received by main memory 806 may optionally be stored on storage device 810 either before or after execution by processor 804.

Computer system 800 also includes a communication interface 818 coupled to bus 802. Communication interface 818 provides a two-way data communication coupling to a network link 820 that is connected to a local network 822. For example, communication interface 818 may be an integrated services digital network (ISDN) card or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface 818 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, communication interface 818 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.

Network link 820 typically provides data communication through one or more networks to other data devices. For example, network link 820 may provide a connection through local network 822 to a host computer 824 or to data equipment operated by an Internet Service Provider (ISP) 826. ISP 826 in turn provides data communication services through the world wide packet data communication network now commonly referred to as the "Internet" 828. Local network 822 and Internet 828 both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on network link 820 and through communication interface 818, which carry the digital data to and from computer system 800, are exemplary forms of carrier waves transporting the information.

Computer system 800 can send messages and receive data, including program code, through the network(s), network link 820 and communication interface 818. In the Internet example, a server 830 might transmit a requested code for an application program through Internet 828, ISP 826, local network 822 and communication interface 818. In accordance with the invention, one such downloaded application provides for a language-independent network resource naming system as described herein.

The received code may be executed by processor 804 as it is received, and/or stored in storage device 810, or other non-volatile storage for later execution. In this manner, computer system 800 may obtain application code in the form of a carrier wave. Variations; Advantages

In the foregoing specification, the invention has been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

Other embodiments of the invention relate to a system, and a method for facilitating secure on-line communication using uniform address as one of the parameters. Definitions:

Secure layer protocols: Secure Sockets Layer (SSL); Microsoft® Passport single sign-in (SSI); other similar.

URL. URL (Uniform Resource Locator) is a unique identifier (such as IP address, Keyword, telephone number or DNS etc.), which uniquely identifies network resources.

IP address. IP (Internet Protocol) address is a numeric URL and represents a layer beneath DNS system; IP addresses are unique by definition; IP addresses may have DNS names assigned for them. The DNS name or Keyword cannot be used if there is no IP address assigned for it.

UTA (Uniform Telephone Address). UTA is a telephone number assigned for networking Target. Each Target has only one UTA assigned for it and therefore each UTA uniquely identifies particular Target. Each UTA has at least one Number File assigned for the UTA and associated with it. UTA system is a URL layer over phone number, IP address and DNS systems. UTA is compatible with Keyword system by RealNames. UTA can be assigned to any networking Target including Internet web resources and telephone fixed or mobile lines.

UTA's Target. Target is a web enabled networking object of any nature such as hardware (such as computing device/appliance, media, chip/processor), software (such as web browser, instant messenger, e-mail enabling software etc.), data (such as web site, page etc.), wave frequency, modulation, division or their composition (for example particular Radio station). Each Target is enabled to require network to assign URL for it. There is only one unique UTA assigned for each Target.

IP address locating Target in the Internet is called Primary IP address and Primary Number File belongs to Target and accessible at Primary IP address. All Targets have web- enabling means such as web server, web browser, and other hardware/software to enable Target managing Primary Number file, connecting, communicating and exchanging via Internet. For Target's Primary number file there should be assigned preferably two mirror copies called Default and Secondary Number files; the files are being located and accessible on-line at Switch and ISP servers accordingly.

Dynamic and Static IP addresses (URLs) and roaming mobile IDs. Each Target can be accessed in the network by using its URL. In the Internet Targets usually have static IP address assigned for them when using leased line (DSL, TI, etc); dial-up or mobile (roaming) Targets usually have temporary dynamic IP address assigned for them through DHCP (Dynamic Host Configuration Protocol) while Target is connected to particular ISP or cell. When roaming, mobile devices numbers are mapped and devices serviced by using such wireless roaming standards as ANSI-41 and GSM-MAP. ANSI-41

ANSI-41 provides support for roamers visiting your service area, and for your customers when they roam outside your area. When a visiting roamer registers in your service area, for example:

• Using the roamer's MIN/ESN, your mobile switching center (MSC) visiting location register (VLR) determines the appropriate MSC home location register (HLR) for routing.

• Your MSC directs the message through SS7 network and, if appropriate, through our gateway access to other SS7 networks, to the home MSC/HLR for validation.

• The caller's MSC HLR validates the roamer and sends a response allowing calls to proceed.

When your customers roam outside your service area, the process is the same, but messages flow through the network to your MSC/HLR. GSM-Map

Much like ANSI-41, GSM-MAP allows for transport of crucial MSC/HLR/VLR registration and seamless roaming data between you and your roaming partner's GSM network, and this message protocol also provides instant access to advanced SS7 related offerings such as Number Portability.

One area in which GSM-MAP and ANSI-41 transport differ is in the area of roamer administration. GSM-MAP networks rely on an International Mobile Station Identifier (IMSI), as opposed to the Mobile ID Number (MIN) used in ANSI-41. The IMSI is a 15-digit identifier, which is made up of the Mobile Country Code (MCC) representing the roamer's home country, the Mobile Network Code (MNC) identifying the home network provider of the user, and lastly the Mobile Station Identification Number (MS IN), which identifies the actual mobile unit. When a visiting roamer registers in your service area, for example:

• The roamer's phone is turned on in your service area; your VLR launches a Registration request to the roamer's HLR. Each HLR is identified via a Mobile Country Code and Mobile Network Code.

• The HLR responds to your serving VLR and your VLR, in turn, notifies the MSC of the roamer's profile.

The roamer is now registered in your service area.

When your customers roam outside your service area into roaming partners' GSM networks, the process is the same, but messages flow through the network to your

MSC/HLR.

UTA's Default, Primary and Secondary URLs. UTA Primary URL is an address locating UTA's Primary Number File associated with Target itself in the Internet. UTA Secondary URL is a URL locating UTA Secondary Number File (the mirror copy of Primary Number File associated with ISP location) in Internet. Secondary Number File is preferably kept at ISP web site. UTA Default URL locates UTA Default Number File which is kept at Switch web server. Secondary URL and Default URL are used preferably while target is offline, i.e. is not accessible by its Primary URL, and for check and verification purposes.

UTA Number file. Number file is described in detail in U.S. Patent Application Number 10/085,717 which is the parent to this CIP. Such a number file is assigned to a particular UTA designating Target.

UTA Default, Primary and Secondary Number files. Number file contains Metadata, associated with UTA. Number file is preferably XML based RDF, CC/PP data file. Default number file is located at Switch server Default URL, which is described below. Primary number file is located at Target Primary URL and the Secondary number file is located at ISP Secondary URL. There could be Tertiary and further URLs providing different or distributed Internet services & connectivity; accordingly they are associated with Tertiary and further number files. Primary Number file preferably contains three URLs i.e. for Default, Primary and Secondary URLs. The Default URL is always the Switch server Primary URL. The Secondary URL is always the Target ISP's Primary URL. Both Default and Primary URLs are provided to Targets when subscribing and stored into Primary Number file during installation or dynamically when connecting to the network. Both Default and Secondary Number files are mirror copies of Primary Number file.

UTA Number file metadata content: The Metadata preferably use XML and compatible RDF, CC/PP and other formats and may contain next data associated with the Target:

Telephone Number (UTA).

Primary URL. Primary URL is not nil if Target is "on-line", and is nil for "off-line"

Target.

Secondary URL

Default URL

Authorization Center Primary URL

CA Primary URL (if different from Switch)

Network Security Primary URL

Authorization Center UTA

CA UTA

Network Security UTA

Primary (Switch) Public Key

Secondary (originating ISP) Public Key

Authorization Center Public Key

CA Public Key (if different from Switch)

Network Security Public Key

On-line status. On-line status data is Primary URL derivative.

Current status of device resources available and required

Purchased resources and current status of purchase

Data related to Network Security policy, contain financial or banking data, e-wallet, proxies, access authorization, authentication and identification datasets, biometric datasets other etc. • User preferences (regular telecom services such as Caller ID, order and terms to switching to order facilities such as text mode, instant messaging mode, SMS mode etc)

• Methods and protocols access verification and authorization

• Other metadata disclosed in the parent to this CIP application

• Other data provided by third parties such as Microsoft Passport or VeriSign certificates etc.

• CA (Switch) Digital Certificate (preferably includes all PNF fields with permanent values)

• Authorized privileges for Public key cryptography (preferably is a part of DC) Target' secure area metadata:

**Credit Card Record**

**Bank account information**

**Secure private key file for Public key cryptography**

**Password for disposable handset use**

Target On-line status check: IP address "ping" command description

The "ping" command or similar command checks on-line accessibility of particular Target at its IP address. Ping is accessible in manual mode in Windows using prompt Start - Programs- Accessories - Command Prompt. To ping the IP or URL the command string shall be: ping <IP address> or ping <DNS name>

Here is the ping command example:

Microsoft Windows 2000 [Version 5.00.2195]

C:\>ping www.names.ru

Pinging www.names.ru [212.24.32.169] with 32 bytes of data:

Reply from 212.24.32.169: bytes=32 time<10ms TTL=121

Reply from 212.24.32.169: bytes=32 time=10ms TTL=121

Reply from 212.24.32.169: bytes=32 time<10ms TTL=121

Ping statistics for 212.24.32.169: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 0ms, Maximum = 10ms, Average = 5ms

C:\>

Web server. This is networking firmware or software installed on particular Target; usually web server provides Internet connectivity, data & script computing, etc. Web server is SSL enabled and therefore supports Public key encryption infrastructure (PKI) and procedures, it can generate Certificate Signature Request (CSR), Public and Private keys, search, retrieve, receive and store Digital Certificate issued by Certification Authority (CA). It can also operate within PKI operating as Mover or Target for the infrastructure. Web server can be firmware - just a chip such as ACE1101MT8 or PIC12C509A SN (http://world.std.com/~fwhite/ace/) or software. Web server is always a part of Target but Target may have no web server.

Web browser. This is networking hardware or software. Web browser provides a set of functions that may vary but shall provide at least next functions: addressing & locating Targets in Internet and web enabled communication networks; connecting to chosen Target; screening the Internet static content (HTML, XML, etc.); screening and scoring/visualizing Internet dynamic content & live on-line voice & video exchange using voice & video over IP technology (dynamic mark-up languages, streaming data, voice &video over IP etc). Web browser is SSL enabled and therefore supports Public key encryption infrastructure (PKI) and procedures, it can generate Certificate Signature Request (CSR), Public and Private keys, search, retrieve, receive and store Digital Certificate issues by Certification Authority (CA). It can also operate within PKI operating as Mover or Target for the infrastructure.

UTA Subscription Authority. SA is an authority, which keeps central UTA repository, providing registration, management and resolution services for UTA and associated Number Files. Switch server is a data management engine at SA site.

Certification Authority. CA is an central PKI authority, providing Digital Certificates for UTA Number Files and related SSL services. The CA is preferably the SA.

Switch server. The Switch is Internet server providing on-line connectivity services for subscribed and non-subscribed Targets. Switch is a Central Target and keeps Default Number files providing Default URLs for each one. Being a Target, the Switch server has got its own Default, Primary and Secondary Number files. Local area network may have local LAN Switch. This unit controls UTA call routing between the LAN and external network as shown in FIG. 16. Network Security file. Switch server and ISP may implement and apply Security policy for chosen or all IP communications, connections, calls and transactions. The Policy data are stored in Network Security file available at both Switch and ISP, Default and Secondary Network Security file. Security File may have UTA assigned for it and therefore can be reached in the network by using the Security UTA. Such UTA may be a well-known number like 911 or other local assigned numbers such as 01, 02 and 03 in Russia, etc.

On-line status. For the purposes of the patent application the "on-line status" term is understood as accessibility of particular Target through the web by using its UTA Primary URL (Status is "on-line") and the "off-line status" term applies to the Target, which is not accessible at its UTA Primary URL (the status is "off-line").

Mover. Mover is a Target initiating IP call, trying to connect to other Target by using Target's UTA. The calls can be performed via Internet as hardware-to-hardware, hardware - to-software, software - to - hardware, and software - to - software IP calls. Mover can provide Target its caller ID and other metadata from Mover Primary Number file. Mover can be anonymous entity.

IP call. IP call is an Internet connection between Mover and Target for data, voice & video point-to-point exchange via Internet using TCP/IP, voice & video over IP technology, other relevant web-enabling means. It can be made as wireline-to-mobile; mobile-to-wireline; mobile-to-mobile calls the present invention claims browser -to-wireline; browser-to-mobile; mobile-to-browser and wireline-to-browser, where mobile is understood as both cell and satellite communication. In secure mode the IP call may use known encryption methods such as RSA, Diffie-Hellman and other, SSL, MS SSI and PKI.

Service Provider or ISP. ISPs are Internet and web enabling communication network Service Providers. Being a Target, each ISP may have its own Default, Primary and Secondary Number files.

Point Of Sales (POS). POS is a UTA node in communication network, providing sales, exchange and transactional services. Each POS may have UTA assigned for it and therefore may be addressed via web-enabled networks. Implementation

Use of preferable authentication standard means. X.50lrecomendations; X.509 directory services; X.519 directory access protocol; Preferably using IETF Kerberos (http://www.ietf.org/html.charters/krb-wg-charter.html); Cryptographic Message Syntax (CMS); other

Digital certificates, encryption issues: Internet X.509 certificates PKI can be used in conjunction with IETF "Use of ECC Algorithms in CMS" http://search.ietf.org/internet- drafts/draft-ietf-smime-ecc-06.txt specification to distribute agents' public keys. The use of ECC algorithms and keys within X.509 certificates is specified in

- L. Bassham, R. Housley and W. Polk, "Algorithms and Identifiers for the Internet X.509

Public Key Infrastructure Certificate and CRL profile", PKIX Working Group Internet-Draft, November 2000.

- FIPS 186-2, "Digital Signature Standard", National Institute of Standards and

Technology, 15 February 2000.

- SECG, "Elliptic Curve Cryptography", Standards for Efficient Cryptography Group,

2000. Available from www.secg.org/collateral/sec 1.pdf .

Financial and transactional services: Preferably implement and use ANSI X9.62- 1998, "Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)", American National Standards Institute, 1999; Electronic Commerce Markup Language (ECML)

Primary Number File (PNF) creation. When a user subscribes for the first time to the UTA product & service, the user provides all necessary information including his UTA to the Subscription and Certification authorities and the latter form the Primary Number File. To enable the user to use PNF for transaction and SSL services, CA issues a Digital Certificate (DC) to enable SSL and PKI. Public part of information for PKI is being stored into UTA PNF and available to other PKI users and the private part is being stored securely at Target's memory. DC is signed by CA Private key and contains at least UTA and Target's Public key. The digital certificate complies with the X.509 format; and the UTA is contained in an X.509 extension.

Primary URL assignment and Primary Number file synchronization: Each time when Target enters a network, ISP assigns for it Primary URL; upon assignment this URL is then preferably provided to Target and stored in metadata in Primary Number file; Primary URL record is then preferably stored in Secondary Number file (at ISP) and in Default Number file (at Switch). While entering the network, Switch preferably authenticates Target using DC; Target then synchronizes Primary Number file entries with Secondary and Default Number files. To do so Target takes Secondary and Default URL from PNF and connects to the Secondary and Default Number Files; when connected Target starts metadata synchronization. To authorize and verify Targets and to prevent impostor from entering network resources, the Switch, ISP or any other SSL enabled entity can retrieve Digital Certificate from PNF and decrypt it using CA Public key receiving at least original UTA and Target's Public key; then exchanging via SSL the checking entity can ensure that the user does not personate the Target and the Target has appropriate privileges.

Updating Secondary and Default Number files: ISP continuously and timely updates Secondary number file by connecting to Primary or/and Default number files. Target's "on-line status" can be also checked through regular means of telecommunication service providers and then converted to number file format, stored into Secondary Number file.

Updating Default Number file:

Method 1: Switch server continuously and timely updates the Default Number files with data taken (Switch pulls) or received (ISP push) from Target's Secondary Number files; when call for particular Target is received, Switch server checks this Target's Primary URL in Default number file and if the latter is not nil Switch connects to it; If connection fails Switch terminates the call and sets Default Number file Primary URL field to nil and its status field to "off-line". Otherwise the Target' "on-line status" can be got using ISP's own means and then retrieved from ISP to Switch server for each particular Target. As optional the Switch server can be set to ping continuously all subscribed targets using their Primary URLs and checking this way their "online status" continuously. Each time when on-line status check is complete, the Switch updates the status in the Default number file for each Target UTA. Method 2: While entering network each Target connects to Switch server and synchronizes its Primary Number file with Default Number file metadata. Switch server continuously and timely communicates with each particular Target and updates the Default Number files with data taken (Switch pulls) or received (Target push) from Target's Primary Number files; when call for particular Target is received, Switch server retrieves Target's Primary URL from Default Number File and if the Primary URL is not nil Switch connects to it; If it is nil or connection fails Switch terminates the call and sets Target's Primary URL field in Default Number file to nil and its status field to "offline". Making outgoing IP call: When Target's UTA is entered into Mover's Internet browser address bar or other web enabling interface, the Mover connects and communicates with the Switch server as disclosed in the parent of this CIP, and receives Target's metadata from Default Number file; if the UTA's Primary URL is not a nil, Mover attempts to access UTA (Target) by using UTA's Primary URL taken from Target's Default Number File; if the Primary URL is valid and Target responds, the Mover and the Target provide their Digital Certificates to each other and make network security policy check; depending on policy Mover can access Target's Primary number file, and vice versa Target can check Mover Primary number file; Mover and Target compute security data applying security policy; accessing and exchanging data with the Target if privileges allow. Preferably IETF Session Initiation Protocol or similar to be used for exchange between Mover and Target.

When the Target's Primary URL is valid and Mover is calling to Target, but Target does not answer the call, the browser attempts to leave a message in device memory;

When the Primary URL is not valid or nil the browser retrieves Secondary URL and attempts to locate the Secondary Number File and etc. and when responding sequential URL is found the web browser allows composing and leaving there a message of any kind.

Answering incoming IP call: When IP call is received; Target automatically turns into "answer" / "deny" or other applicable mode, rings or otherwise indicates the incoming call; The Target attempts to retrieve Mover's UTA and Digital Certificate from Mover Primary Number file; Target can check UTA and Digital Certificate validity and Target's privileges using PKI. Target then makes a decision to allow or deny Mover' connection in accordance with security/calling policy, privileges and preferences of both parties provided in Number File's metadata and Digital Certificates. If secure call is requested then both parties encrypt the exchange using SSL and PKI, their Private and Public keys. The secure mode allows purchase, payment and other secure transaction services. When check, verification, authentication is complete preferably IETF Session Initiation Protocol or similar to be used for exchange between Mover and Target.

Enabled and Disabled calling ID lists. Each particular Target has a list of other networking Target' IDs related to the particular Target somehow (i.e. telephone number list of friends, partners, relatives etc.). The list can be divided at least in preferably parts: Those Targets, which are not allowed to see on-line status of the particular Target; Those Targets, which are allowed to see the particular Target's on-line status; those Movers which are not allowed to call to the Target; those Movers which are allowed to call to the Target etc. Therefore each Mover can check and receive "on-line status" for only those Targets who allow the Mover to check it. Before calling to particular Target Mover can check whether the Target is on-line and can save calling time if the Target is currently off-line.

Issuance of Digital Certificate (DC) for UTA/Target. When UTA Subscription Authority creates and registers UTA associated with particular Target, and creates Primary Number File for the Target, the Certification Authority (CA) creates a Digital Certificate (DC); to allow DC creation the Target shall be SSL enabled and:

• The Target provides completes all required fields of Primary Number File (preferably all PNF fields with permanent values) and generates Certificate Signature Request (CSR) file, Public key and Private key; The Private Key is being securely stored at the Target's memory;

• The Target provides its CSR and Public key to the UTA CA for signature

• The Public key file and UTA Primary Number File are being encrypted (signed) by CA (Switch) with CA Private Key, and the encrypted message represents a UTA Digital Certificate;

• The CA signs the CSR and returns it to the Target as Target's Digital Certificate (DC). The DC includes UTA, and the digital certificate is digitally signed by the CA.

• The Target stores the DC in the Target Primary Number file and makes it available for SSL procedure.

Verification and authentication are used to prevent impostors from entering network and particular Target resources using particular Target's PNF, the digital Certification Authority, Switch or Target:

• Simple authentication in non-secure mode (SSL is disabled): Takes UTA from Mover's Primary Number File; retrieves Default, Primary and Secondary Number Files for Mover's UTA; verifies Mover's UTA by comparing key data from Secondary and Default Number Files with those in Primary Number File; if verification is complete successfully the Mover is authorized to use requested services and the Target is provided with verification from Switch;

• Strong authentication in secure mode (SSL is enabled) where Target A (A) authenticates Target B (B):

B: α encrypts the Dataset B using Private Key B forming Dataset Bl α composes a check message containing DC B and Dataset Bl α transmits the check message to A; and A: α Retrieves DC B and Dataset Bl from the check message α Decrypts DC B using CA (Switch) Public Key

□ retrieves Dataset B and Public Key from the decrypted B's DC

□ decrypts the Dataset Bl using Public Key B forming Dataset A

□ compares the Dataset A with Dataset B and if the Dataset A is identical to the Dataset B the A makes decision that B possesses correct CA's certified Private Key B and the verified Dataset B, therefore B is authentic;

Where Dataset B is preferably a part of DC B and preferably the UTA B; or other DC B fields, or some or all the DC B fields; or DC B itself.

Other similar/applicable authentication procedure can be set up based on particular cryptography use.

Verification authentication and authorization by Target. To authorize and verify Movers, and to prevent impostors from entering Target resources personating/using particular Mover's PNF, the Target via SSL

• Retrieves Digital Certificate from the Mover's Primary Number File; decrypts the DC with CA (Switch) public key; checks validity of the DC; authenticates the Mover; allows Mover to connect to Target based on Mover's privileges if the check is successful and denies connection if the check failed. '

Verification authentication and authorization by Mover. In order to verify that a connection made to valid Target and not to an impostor, and to prevent impostors from entering Movers resources using particular Mover's PNF, when connecting to Target, Mover retrieves Target's DC from Target's PNF; decrypts it by using CA (Switch) Public Key; verifies Target's UTA and checks Target privileges.

Secured transaction services between Targets representing Buyer and Seller.

IP transaction services can be provided based on applicable Network Security policy and user's privileges using Secure Socket Layer (SSL), PKI and UTA CA services. The Public key cryptography allows verifying UTA though Public key cryptography infrastructure. SSL (secure socket layer) enables PKI usage for secure on-line e-commerce, banking etc. transaction services, data and live interaction exchange. All are based on the use of DC and its content. The payment between Buyer and Seller can be processed using procedure similar to credit card payment authorization procedure described below:

Purchase message

"Purchase message" is a message composed by a Buying Target. "Purchase message" contains preferably

• Seller DC

• Seller Primary URL (optional)

• Purchase data (currency and money values, time of purchase, purchase/transaction number and other appropriate purchase information)

"Purchase message" is agreement to buy, digitally signed i.e. encrypted using Buyer's Private Key.

Charge message

"Charge message" is a message composed by a Selling Target. "Charge message" contains preferably

• Buyer DC

• Buyer Primary URL (optional)

• "Purchase message" signed using Buyer's Private Key.

"Charge message" is agreement to sell, digitally signed i.e. encrypted using Seller's Private Key.

Authorization message

"Authorization message" is a message composed by an Authorization Center. "Authorization message» contains preferably

• Buyer DC

• Buyer Primary URL (optional)

• "Purchase message" signed using Buyer's Private Key.

"Authorization message" is an authorization, digitally signed i.e. encrypted using Authorization Center's Private Key.

"Pay" Authorization Method comprising the steps:

• Establishing wired or wireless connection between the Buyer and Seller

• Displaying or otherwise indicating the Name of purchase and the value of purchase, other appropriate purchase/transaction data to the user

• Waiting to receive the Buyer's authorization for purchase and if authorization is granted:

• Executing preferably Strong Buyer / Seller cross-authentication in secure mode

• If Seller and Buyer are authentic, Buyer: o Composing "Purchase message" o Connecting to the Authorization Center using Authorization Center

Primary URL o Executing Strong cross-authentication with the Authorization Center in secure mode if applicable o Transmitting the "Purchase message" to the Authorization Center o The Authorization Center

^■ decrypts the "Purchase message" using Buyer's Public Key taken from Buyer's DC during authentication AND

^■ Authorization Center

• composes the "Authorization message"

• transmits the "Authorization message" to the Buyer

• Buyer transmits the "Authorization message" to the Seller

• the Seller decrypts the "Authorization message" using Authorization Center's Public key

^■ OR Authorization Center

• resolves via Switch the Seller Primary URL using Seller UTA taken from Seller DC; OR takes Seller Primary URL from "Purchase message"

• connects to Seller using Seller Primary URL

• authenticates the Seller and if Seller is authentic: • verifies the purchase parties and data

• composes the "Authorization message"

• transmits the "Authorization message" to the Seller

• the Seller decrypts the "Authorization message" using Authorization Center's Public key o the Seller allows the purchase if the payment is authorized

"Charge" Authorization Method

The method includes these steps:

• Establishing wired or wireless connection between the Buyer and Seller

• Displaying or otherwise indicating the Name of purchase and the value of purchase, other purchase/transaction data to the user

• If Seller and the Buyer are authentic, Buyer: o Composing "Purchase message" o Transmitting the "Purchase message" to the Seller; The Seller:

* decrypts the "Purchase message" using Buyer's Public Key taken from Buyer's DC and verifies the purchase data if applicable to policy and if purchase data is correct

^■ composes "Charge message"

^■ connects to the Authorization Center using Authorization Center Primary URL

^■ Executing Strong cross-authentication with the Authorization Center in secure mode if applicable to policy and if cross- authentication succeeds,

^■ transmits the "Charge message" to Authorization Center; the Authorization Center:

• decrypts the "Charge message" using Seller Public Key and retrieves and decrypts "Purchase message" using Buyer's Public Key taken from Buyer's DC • verifies the purchase parties and data

• composes "Authorization message"

• transmits "Authorization message" to Seller

^■ the Seller allows the purchase if the payment is authorized

Credit card record. The credit card record (CCR) is typical credit card record. The CCR is typically recorded on the credit card magnet stripe or in the smart card internal memory or in another credit card memory.

Credit card authorization method. In order to use credit card for on-line transactions the CCR must be taken from the credit card and saved in the Target' secure area metadata. Then CCR is used as described in Authorization methods. If it is required by particular Credit card system (such as VISA, MasterCard or other) to change CCR when authorizing particular transaction, the changed CCR is being changed by the Credit Card system and returned to the Target encrypted using the Target Public Key, then the received CCR is decrypted by the Target using its Private Key and stored in the Target' secure area metadata for further use.

Bank account charge method. Bank account charge can be deployed in a way similar to the Credit card authorization method .

Temporary UTA. In order to reduce cost per call and increase service accessibility & flexibility, Temporary Digital Certificates containing UTA can be issued by CA (Switch) and used for web-enabled disposable telephone handsets and web browsers or other networking objects/Targets all further called Temporary Targets (TT); they all can serve as temporary Targets or Movers in the network. CA (Switch) issues UTA and UTA DC; transfers the UTA and DC directly to Temporary Target Number File or to reseller; and the reseller assigns the UTA/DC to particular temporary Target Primary Number File.

Such disposable handsets may use Transaction, Text, Voice & Video over IP exchange only and be sold and set up for use with or without assignment of static (permanent) network UTA (telephone number) for them. When purchased handset is turned on, it prompts user: to manually type /use particular preset UTA, or set to automatically choose a dynamic UTA provided by network.

Semi static UTA mode: If user chooses to use particular UTA, a handset preferably requires to type a "Password for temporary UTA" to verify the user's rights to use the UTA (the Password is similar to Personal Identification Number for GSM SIM card); when the password is stored, handset connects to UTA issuing authority' (CA, Switch, ISP, reseller etc) server via SSL and verifies the "Password for temporary UTA" OR verifies the Password with the encrypted Password record contained in the Handset secured memory area; if the check is successful, the user is granted access to network resources using chosen UTA and is treated as an original UTA user; if the check fails the handset can be denied, blocked or reported stolen based on security policy; OR

Particular UTA with DC can be assigned and valid through a standard period of time or number of connections/transactions for the handset/software and if assigned, such UTA shall be typed (it may be preset to appear in interface when handset is turned on) and should be confirmed for use by the user;

Dynamic UTA mode: When after purchase user turns on a handset for the first time, the handset connects via Internet to the Switch server; Switch server registers the handset in the network and assigns dynamic UTA and temporary Default Number File for it; Default Number File is a copy of Primary Number File; the dynamic UTA can be used only for duration of each particular call unless the user requires to hold the UTA for a standard period of time or based on other standard terms of use. Dynamic UTA is revoked after the call is disconnected or assigned and held for the handset for standard period of time if required by user. In order to get the UTA, handset shall be enabled to update its Primary Number File with the particular UTA and the CA shall issue a DC containing the UTA and assign it to the handset as described above. PNF as Digital Identity Dataset. PNF can be used as a Digital Identity Dataset including all identifying information required for particular verification, authentication, and authorization and transaction purposes.

Session encryption using new shorter Key pair. In order to accelerate encryption of on-line audio and video streams Targets may use Shorter session Key-pairs. To do so, each Target:

• issues new pair of shorter Keys (public and private)

• Private Key is to be stored safely in Target' internal memory and used only for the one session

• each Target encrypts the new shorter Public Key with the Sending Target Original Private Key or with Receiving Target Original Public Key and transmits the encrypted message to the Receiving Target

• Receiving Target decrypts the received message containing the new shorter Public Key of the Sending Target and uses the received Sending Target Public Key to encrypt/decrypt the session exchange with Sending Target.

It is understood that in Public Key Infrastructure Targets can encrypt a message (stream):

• using the Receiving Target Public Key and the Receiving Target decrypts the message using its Receiving Target's Private Key

• using the Sending Target's Private Key and the Receiving Target decrypts the message using Sending Target's Public Key

Business model 1: selling UTA, which is valid for a period of time or number or fixed money value of services provided etc.

Business model 2: selling Digital Certificates where UTA is a main verifiable part and privileges contain terms of use based on a time period or number or fixed money value of services provided etc.

Business model 3: Selling PNF with permanent UTA for permanent Targets or without permanent UTA for Temporary Targets.

Business model 4: Selling media (SIM cards for GSM and later 3G standards, CD, DVD, or other media) with PNF files recorded on the media.

Business model 5: Selling record able memory chip or processor (SIM cards for GSM and later 3G standards, CD, DVD, or other media) with PNF files recorded on the memory.

Business model 6: Selling PNF as a Digital Identity Dataset.

Business model 7: Selling UTA and /or Number File resolutions (on per resolution charge basis).

Business model 8: Selling UTA and/or Number File data to third party (on per provision charge basis).

Business model 9: Selling UTA and /or Number File authentication services (on per authentication charge basis).

Business model 10: Selling UTA and /or Number File charge authorization services (on per authorization charge basis).

Business model 11: Selling UTA Software Development Kit (SDK) realizing functionality of all described methods.

One skilled in the art would also appreciate the possibility of using CCR (or bank account details) encrypted using AC Public key as shown in FIG. 14. This implementation, provides the possibility of limiting to one the parties capable of reading the CCR and this entity being the authorization center. Therefore, this implementation provides sustainable secure charge service and permanent theft protection with the highest level of security. Another feature, is that this allows the use of regular existing credit card charge authorization infrastructure of major CCR (FIG.15), and, therefore, makes the implementation of such authorization scheme very inexpensive. Using E-UTA-CCR provides double strong authentication possibility, comparing UTA taken from E-UTA -CCR and UTA taken from DC.

One skilled in the art would appreciate the possibility of using Account Record (AR) encrypted using AC Public key and thus forming EAR. This implementation provides the possibility of limiting to one the number of parties capable of reading the AR and this entity being the authorization center. Therefore, this implementation provides sustainable secure charge service and permanent theft protection with the highest level of security. The use of AC Public key for CCR encryption also allows any third party to encrypt the AR using the AC Public key and thus allows unlimited number of third parties to securely encrypt Account Records securely linking up with AC services this way.

One skilled in the art would also appreciate that due to the issuing of the ADC (which comprises the network resource UTA, the network resource Public key and the network resource EAR), the AC/CA becomes capable of "on-the-fly" authentication of a particular network resource and verification of the network resource's rights to use the particular EAR, thus securely mapping the particular network resource to the particular EAR and providing secure transaction services (see FIG. 15). Consequently AC/CA does not need to set up, run and securely manage a database mapping each particular CCR to each particular network resource UTA, and, therefore, the scheme allows AC/CA to be free from all database related expenses. On the other hand, the absence of the database allows AC/CA transaction services to be free of security failures associated with the database security and private data management. Another feature is that EAR allows the use of regular existing credit card charge authorization infrastructure of major CCS block 1201 in FIG. 15, and, therefore, makes the implementation of such authorization scheme very inexpensive, virtually limiting AC/CA credit card authorization means to one regular CCS POS terminal having single CCS merchant account.

Using EAM along with DC provides a separation of certification and authorization responsibilities and distribution of said services without reducing the security level of the provided transaction services.

The EAR independence on the account nature (bank or service provider, or credit card system account, fingerprints or other biometric measures, tax IDs and data, social security data etc.) makes the method uniquely uniform for the accounts of any nature including, without limitation, bank accounts, Credit Card System accounts, service provider accounts, biometric and other accounts that are applicable.

Another feature of particular network resource PIN code or Password encryption using the network resource Public key allows the network resource to establish and independently compose and manage a password as a theft protection means, protecting the use of the network resource for transaction purposes.

Transaction infrastructure

Transaction Infrastructure is illustrated by way of example in Figure 10, and includes networking Targets 1000 each having assigned UTA number, financial institution targets 1001, 1002 each having assigned routing UTA number and authorization & clearing infrastructure 1003. Each networking target represents payer and payee, the financial institution targets represent a financial account provider (preferably banks) for said payers and payees, and the infrastructure represent a clearing & authorization system which according to one embodiment is a clearing account provider for financial institution targets.

Said financial institution targets have assigned Routing UTA (RUTA). Each RUTA is either ordinary UTA or specific UTA numbers. RUTA numbers are issued and stored, and indexed in the Switch database.

The method described herein provides a creation of a specific "Zero-based" RUTA system. This method allows to assign "zero-country" zone with 100 billion available numbers including a "total zero" +0-000-000-0000 UTA number; and "zero area" zone like +1-000-000-0000 with up to 1 million available numbers for each country; and "zero based" number stack in each area of each particular country providing up to 1 million additionally available UTA number for each area code such as a stack of +1-212-000-0000 to +1-212- 099-9999 for special authorization purposes for the USA New York 212 area. For example the Global Registry or Global Clearing & Authorization House 1101 as shown in Figure 12 may have assigned "total zero number" for it and the local authorization nodes can use "zero- country" or/and "zero area code" numbers and "zero-based" numbers like 000-OOOX.

The form of UTA financial account number for global reach must include both UTA and its RUTA routing numbers for each dealing Target in the network and therefore the global routing number would use RUTA/UTA format. For example + 1-212-000-0000/+ 1- 718-123-4567 would mean that particular USA, New York, 718 area Target having UTA +1- 718-123-4567 is being served by a financial institution located in the USA, Manhattan, area 212 having RUTA +1-212-000-0000. UTA extensions are being used, as shown, for example in FIG. 16, providing UTA access to each device within LAN, for example ATMs belonging to one particular bank can be accessed using this bank LAN switch.

In a very similar way corresponding relationship between banks may be established and used as a compound RUTA involving respective banks RUTA numbers. For example, as shown in Figure 10, RUTA2/RUTA1/UTA would mean that this particular UTA Target is a client of particular RUTA1 bank and said RUTA1 bank has got a corresponding account in particular RUTA2 bank. This allows very simple and seamless routing services for networking Targets just by storing the appropriate RUTA in the particular Target Primary Number File metadata. This also allows to set up infrastructure wherein independent of Target location area and its bank location area each Target can choose any particular bank to serve Target's account; and each Target can use multiple bank and credit card accounts too.

Within each area code of a particular country the financial institutions can be indexed based on ordinary UTA numbers although "Zero-based" numbering system is being preferable and provides ordinate numbering wherein first issued RUTA number within particular area code has "0" as a very right digit, the next one has "1", next "2" etc. hereafter such number is being accomplished to a complete telephone number size by adding zeros from left. The last UTA in such stack would start with "0" having all "9"s afterwards. Therefore for example first specific RUTA number assigned in the USA for New York area 212 will be +1-212-000-0000 and the second +1-212-000-0001, next +1-212-000-0002 and the last +1-212-099-9999. Said zero-method of assigning RUTA numbers allow to use the available zone of "Zero-based" telephone numbers for transaction purposes and to organize the RUTA database issuing consecutive RUTA numbers. This stack of available numbers runs from 000-0000 to 099-9999 for 7-digit based telephone numbering systems providing therefore up to one million of available routing numbers within each area zone of each country code.

Illustrated in Figure 10, is an example of "ACH RUTA N" financial institution, where ACH is an acronym for Automated Clearing House. In fact, if RUTA number is assigned for an ACH institution, it would represent a corresponding account for all ACH member institutions. If the member institutions are members of RUTA infrastructure, then each must be assigned a RUTA-B number. Therefore if, for example, SWIFT has a RUTA-SW number, then each SWIFT number for particular SWIFT-member bank would be addressed via RUTA infrastructure as RUTA-SW/RUTA-B, and the bank clients accounts would have RUTA- SW/RUTA-B/UTA for global reach VIA SWIFT. This requires no need to know SWIFT numbers although allows for use of these numbers. Therefore RUTA infrastructure can serve as bridge gateway between all ACHs.

Set forth below is an illustrative example of SWIFT clearing via RUTA infrastructure.

Suppose that CITIUS33 is a legal SWIFT clearing number for CITIBANK N.A., and that SWIFT clearing system RUTA is: +0-(000)-00-SWIFT. Then , RUTA number for CITIBANK within SWIFT can be, for example: +0-00C-ITI-US33. Next, let us assume that a client, whose UTA is +1-212-123-4567, has a bank account with CITIBANK N.A. Then RUTA/UTA global reach substitute for CITIBANK client account via SWIFT can be, for example:

+0-(000)-00-SWIFT / +0-00C-ITI-US33 / +1-212-123-4567

In general, all corresponding relationships in bank community are often grounded in currency relationships. That is, for example, if a Russian bank wants to provide USD accounts/payments for its customers it must open an account in an USD zone which, in turn, must open a corresponding account in one of US banks. Therefore, when RUTA is put into a Digital Certificate (DC), the DC must also define currency set assigned for such RUTA unless the bank account is RUTA-multicurrency. The currency issue can be addresses by using a country-code-defined currency value approach. In particular, if some bank's RUTA is +7-00C-ITI-BANK, then its domestic currency code is 7 (which in this example is Russian Roubles (RUR)). If this bank has a corresponding relationship with +1-00C-ITI-BANK, i.e. a bank in the USD currency zone, all Russian bank clients' accounts using compound RUTA +1-00C-ITI-BANK / +7-00C-ITI-BANK / UTA would be nominated in USD. On the other hand, all US bank clients' accounts using +7-00C-ITI-BANK / +1-00C-ITI-BANK /UTA would be nominated in Russian Roubles (RUR). Accordingly, multicurrency institution may use 0 area code or multicurrency sign attached to the appropriate RUTA account in DC or appropriate currency description in the number file. The latter approach is to use standard approach provided in "XML schemas" which describe meaning of XML tags such as RUTA for example. Accordingly, when RUTA +1-00C-ITI-BANK tag is taken its schema must be taken at RUTA +1-00C-ITI-BANK XML number file corresponding location and currency values resolved accordingly using XML approach.

The present invention provides a very user-friendly and seamless payment procedure wherein payer or payee only need to know accordingly the payee or payer UTA number to allow transaction and seamless payment routing between payer and payee bank accounts. The invention also allows unified approach wherein financial institution also are networking Targets having UTA numbers assigned for them and the financial institution can receive Fund Transfer Agreement or Deal Agreement from networking Targets, authenticate payer using particular Target UTA and apply the payment from this particular UTA bank account.

All financial institutions must have RUTA numbers assigned for them and must comply with the Gateway requirements in order to allow on-line transactions flow via RUTA/UTA transaction infrastructure. The Gateway must provide secure on-line mapping of the internal financial account numbers to the appropriate UTA numbers of their respective owners or the internal account numbering must be built upon UTA numbering approach. This allow to use UTA authentication procedure as a major part of payment authorization.

As shown herein the invention allows UTA use for financial routing too. The UTA represent a higher layer upon traditional routing systems in the Internet and telecommunications and for financial infrastructure. UTA layer therefore broadens, unites and unifies Internet and telecommunications and financial exchange addressing and routing and allows a uniform ISO/OSI transport layer for networking Targets of any nature. Clearing & Authorization system infrastructure

After applying a payment to a particular payer bank account, the payer's bank must transfer appropriate funds to the payee's bank. Therefore between financial institutions there must be a clearing facility established and used in order to allow this bank interchange.

In one embodiment illustrated in Figure 12, Routing UTA transaction authorization & clearing system can use the existing infrastructures such as worldwide SWIFT number based or domestic one such as American Bank Association (ABA) number based FedWire in the USA or Bank ID Code (BIC) based system in Russia or other bank routing, interchange and clearing systems. In this embodiment the UTA numbers are being mapped to the existing SWIFT or ABA or BIC or other routing number and appropriate number descriptive information.

Alternatively transaction & clearing system can be set up as independent RUTA Clearing & Authorization House (CAH) using uniform UTA procedures for authentication between payer bank and payee bank using their respective bank RUTA numbers and bank Digital Certificates comprising RUTA numbers as a major verifiable part.

Alternative embodiment might not include CAH and instead can be built on the use of bilateral authorization & clearing agreements between banks wherein the payer bank may directly connect to the payee bank, cross-authenticate and transmit the Wire Transfer Agreement to the payee bank and clear the transaction using UTA methodology provided herein.

Digital Agreements and the use of PKI for on-line transaction services

On-line transaction services are such wherein the charged and charging targets are online.

The on-line transactions use PKI and digital signatures to authorize transaction.

The use of RUTA can be implemented by storing RUTA numbers along with Encrypted Account Records (EAR) or without storing the latter into DC or ADC. Multiple accounts can be resolved and managed using UTA infrastructure for each particular Target. To allow multiple accounts management for Particular Target, the appropriate RUTA numbers of particular financial institutions must be stored into DC or ADC. Therefore at least particular networking Target UTA and its Public key and the particular Target's financial institution RUTA numbers must be stored into Digital Certificate to allow incoming and outgoing payments for this particular Target accounts.

There are three types of digitally signed agreements:

Deal Agreement (DA)

The DA comprises DCs or/and ADCs of both Charging and Charged Targets and Agreement to buy digitally signed by the Charged Target and Agreement to sell digitally signed by the Charging Target and purchase values.

Funds Transfer Agreement (FTA)

The FTA is the Charged Target Agreement to pay; FTA is digitally signed by Charged Target; FTA comprises at least DC of the Charged Target and UTA of the Charging Target and money and currency values of the transfer. FTA may be unconditioned or may contain a reference for transfer.

Wire Transfer Agreement (WTA)

It is an Agreement issued and digitally signed by a financial institution in order to allow bank interchange and comprising at least the issuing bank client Target's Deal or Funds Transfer Agreement, the issuing bank DC and the transfer money/currency values and other applicable information.

The suggested method of performing sales provides at least three types of services:

• The Deal, wherein both dealing Targets must sign the transaction agreement reflecting their agreement to buy or to sell

• The Fund Transfer, wherein any networking Target may unconditionally or by reference decide to transfer funds to any other particular networking Target.

• The Wire Transfer, wherein two financial institutions may allow funds exchange and account clearing

The Deal transaction type is being used for all B2C, C2B, G2C and B2B (EFT) transactions and between individuals (P2P).

For example, e-commerce on Internet, ordinary supermarket commerce, fuel station or anywhere else wherein the cashier applies charge to the consumer's UTA stored into POS terminal and the consumer receives the payment request on his/her networking device and authorizes the payment from his/her own networking device by entering his/her password. The Deal type would greatly facilitate the payment for telecommunication services wherein the Service Provider initiates a payment request on the client networking device and the device end user simply authorizes the payment by entering the password.

The Deal can serve and B2B purposes providing on-line transaction services capability for business networking Targets spread worldwide.

Deal type can facilitate concluding a deal between two people being at the time of transaction in different geographic locations but connected via the network.

In general the Deal type of transaction allows the charged party and the charging party both to sign obligatory agreement for goods, information or services supplied for the payment and thus provides legal background for the deal so that each party feels legally secured.

Funds Transfer is being used for transactions wherein payer can use unconditional or referenced intention to transfer funds to payee's account. The Fund Transfer is being used when Target end user needs to transfer funds to someone else. Such services can be on-line substitution for services provided by "Western Union" offices.

The use of " UTA credit/debit card" records for off-line transaction services

The off-line transaction services is a basic part of credit card system services. For this invention purposes the off-line transaction services are understood as such wherein the charged Target is off-line. Therefore in order to apply the payment to the charged Target the invention provides the use of UTA credit cards and other credit mediums comprising readable UTA records being used as credit/debit account records. The charge can be applied if valid charged Target secret password or PIN code was entered and submitted into Charging Target POS terminal. UTA Card and record samples are shown in Figure 17.

Example of UTA payment service implemented in a supermarket

The purchase exemplary procedure is shown in Figure 18. When customer with a basket full of goods comes to a cashier, as usually the cashier counts the value of purchase by reading bar codes from the goods or manually or otherwise and receives the total value of purchase block 1301 in FIG 18.

Hereafter if the customer prefers UTA payment method block 1302, the cashier either inputs the customer's telephone number into POS terminal manually or reads the UTA bar code located on the customer's mobile phone surface or on the customer's credit card or business card etc. The customer's handset can also be capable of displaying the UTA bar code and the bar code can be read from the handset display using ordinary POS terminal bar code reader. Examples of UTA record location and exposure are shown in Figure 17.

Hereafter Cashier submits the UTA input block 1302 Figure 18. And thereafter:

On-line

As shown in block 1304 in Figure 18 the supermarket's payment request message comes to the customer's handset and the latter displaying the supermarket authenticated identity and the value of purchase and the prompt "accept - reject" the payment to the customer.

Customer chooses "accept" option and enters his/her secret password to confirm the purchase. Thereafter the customer submits the password authorizing the payment block 1305 in Figure 18.

The cashier and the customer receive payment confirmation message from the network authorization means respectively on POS terminal and on the customer's mobile device as shown in the block 1306 on Figure 18.

The confirmation is being logged and the transaction complete.

In this example the handset can be capable of receiving the list of goods being purchased from supermarket POS terminal and displaying the list including purchase value, bar code, picture, weights, price per kilo and other measurements related to each good. The handset can be capable of saving these data and using the data next time when customer wants to repeat the purchase in respect to chosen goods.

The handset can be capable also of managing many bank and credit card accounts therefore enabling the customer to choose from the account list which particular account must be used in this particular transaction. The accounts may be arranged to be used orderly wherein first account is being used by default and each consecutive account is being automatically or manually used in case if previous major account is not available for the payment. This payment transaction is a Deal Agreement.

Off-line

Whenever the customer's handset is off-line (i.e. the handset battery has died or the handset is not available for end user at the moment) after storing the UTA into the POS terminal the POS terminal internal memory block 1302 in Figure 18, it displays the Customer's secret password input field and submit prompt block 1303. Optionally the POS terminal resolves the customer's UTA and shows the customer's identity descriptive information (ID number, face picture, name etc) on the POS display as shown in block 1303. The further step requests the customer to show his/her ID (driver license, passport etc) confirming his/her identity to use the UTA.

Alternatively, biometric fingerprint device coupled to the POS terminal can be used. Provided that Number file contains original customer's fingeφrint EAR, it can be used for fingerprint authentication of fingerprints taken from customer at POS location instead of Password.

The customer enters his/her secret password and submits it. The password check request is being further resolved via authorization infrastructure and if the password check has been successful and authorization granted the POS terminal receives authorization message and displays it to the cashier and customer block 1307. Same authorization message is being sent to the particular customer UTA networking Target for further use.

The confirmation is logged and the transaction complete.

This payment transaction is a Deal Agreement.

Example of UTA payment service used by payer

The payer chooses pay operation in the handset user interface block 1401 in Figure 19.

The payer enters the payee UTA number into input field on the handset display block 1402.

The payer chooses currency and enters the value of transaction and payment reference if applicable block 1403.

The payer submits the payment.

The payer enters the secret password to confirm the transaction block 1404. After password check procedure and if the password is correct the payment is being effected.

Payer receives authorization message from the network and the message is being displayed to confirm the execution of the transfer block 1405.

The payee receives authorization message from network as a notification informing that his/her account was credited and showing the authenticated identity of the payer and reference information if applicable.

The confirmation is logged and the transaction complete.

This payment transaction is a Funds Transfer Agreement.

Similar UTA online charge sample procedure used by payee is provided in Figure 20.

Clearing & Authorization procedure

On-line procedure

Assume the financial institutions are banks.

When Deal or Funds Transfer Agreement is composed and digitally signed it is being preferably transmitted by the payer to the payer RUTA bank in order to avoid unnecessary traffic. Although it might be instead the payee or payer Target and payee bank or payer bank without significant change in authorization procedure. The payer bank authenticates the payer Target signature and if authentic retrieves the transaction value and the payee Target RUTA/UTA or at least payee Target UTA which is further being resolved to the payee Target RUTA/UTA via Switch.

Using existing clearing system

After receiving the Deal or Funds Transfer Agreement the payer bank can resolve via Switch the RUTA number into SWIFT or other payee bank routing details and thus may further execute payment using any international or domestic third party (such as SWIFT and/or other systems) routing and clearing routine. This method allows the use of existing clearing and routing infrastructure and thus provides very inexpensive implementation of the RUTA/UTA clearing for payment methods provided herein. If an existing SWIFT or other clearing system is being used, the appropriate system- specific routing account records are being stored into each particular financial institution RUTA Primary, Secondary and Default Number Files. While transacting Mover and Target exchange their respective RUTA taken accordingly from Target's and Mover's Primary or Default or Secondary Number File or from their DC or ADC. Further payer provides the payer's bank with a particular payee RUTA/UTA and the payer bank resolves the payee RUTA via Switch server receiving from Switch the ordinary SWIFT or other routing record assigned to the payee bank. This allows the payer bank to complete transaction with the payee bank in ordinary way. In this case the preferred embodiment would require that each particular UTA Primary Number File and its copies , DC or ADC must include RUTA as the only bank routing information and Number Files must not have the appropriate bank ordinary routing details to allow Switch to apply transaction fee, wherein the lack of particular Target bank ordinary routing details will make payer bank to resolve the RUTA number via Switch. In this case Switch would apply a fee schedule for all RUTA resolution and may require each payer bank to provide the Switch with information on the transaction and its value in the process of each transaction, thus allowing the Switch server to apply appropriate transaction fee to the payer or payee, based on transaction value percentage fee or a flat fee basis or on distance fee basis or on all said fees.

Using RUTA clearing system

RUTA clearing block diagram is shown on Figure 12. When the payer bank receives from payer the Deal Agreement or Funds Transfer Agreement, in turn the bank composes its own Funds Transfer Agreement called a Wire Transfer Agreement (WTA) which is being digitally signed by the issuing bank and comprising at least the transaction value; and payer and payee global RUTA/UTA or payer and payee UTA numbers. Thereafter the payer bank resolves via Switch the payee bank RUTA number receiving payee bank primary URL. Thereafter the payer bank composes and signs a bank's Wire Transfer Agreement (WTA) The bank connects to the RUTA Clearing & Authorization House (CAH) and to the Payee bank, cross-authenticates and transmits the WTA to CAH and to the payee bank.

CAH further authorizes or denies the transaction. CAH authorization or denial is provided in a form of Authorization Agreement (AA) digitally signed by the CAH. If payer bank clearing account balance allows the transaction, CAH debits the payer bank clearing account and credits the payee bank clearing account for the value of the transaction and applies fees. The AA is further being securely transmitted to both payee and payer banks. If authorization is granted and authentic the payee bank credits the payee UTA bank account and the payer bank debits the payer UTA bank account for the transaction value and appropriate transaction fees.

Off-line procedure

Off-line is understood to be the case when at the time of transaction the CAH is not available on-line. In this embodiment the payer bank may directly connect to the payee bank, cross-authenticate and transmit the Wire Transfer Agreement to the payee bank and post is to the CAH. The CAH timely retrieves the WTAs, grants or denies authorization, composes and signs the Authorization Agreement (AA). Further CAH connects to each payee and payer banks on timely basis and transmits the AA.

Automatic Teller Machine (ATM) Implementation

RUTA may be assigned to an Automatic Teller Machine (ATM) and the "Cash Request" can be generated using the ATM machine in order to charge any UTA networking device wherein, after on-line or off-line authorization of the transaction by a particular UTA end user, cash is dispensed to the requesting ATM user. In this regard, the POS terminal as referenced above, may also be implemented as an ATM.

An example of an ATM cash withdrawal in accordance with present invention is as follows:

An ATM client chooses UTA Withdraw operation,

Types in UTA or sweeps/puts in the UTA card in the ATM,

OFF-line: the ATM requires ATM client to type password (i.e., authentication information); when authorization is given the ATM provides cash to the ATM user.

ON-line: as described above, but in the end the Mover receives cash from ATM.

ATM can be equipped with a telephone or videophone to be able to provide live authentication by voice and picture wherein Target (payer) can see and talk to the Mover when authorizing a payment and Mover gets cash from ATM in ON-line mode if Target has authorized it. Similarly ATM capable of accepting cash deposits can be used to implement "cash => cash" transaction between two ATM users. Regular ATMs can be used for "major credit/debit card => cash" and vice versa transactions between two ATMs. In this embodiment UTA numbers assigned to each ATM are being used to establish IP connection between ATMs and make the transaction independent of each ATM location. ATM videoconferencing capability would greatly facilitate visual authentication for both ATM users in this case.

Business models

In the above described cases the Authorization Center may act as Clearing & Authorization House for respective registered banks and running a database which is mapping each particular RUTA to the particular routing details for specific Routing/Clearing system and remaining bank' clearing account balance information.

The Subscription Authority for a fee issues RUTA for banks and other financial institutions and Switch applies fee schedule for RUTA resolution services.

Transaction fee can be either a percentage or a flat fee or both fees applied per clearing transaction (fee per amount and fee per transaction).

Transaction fee may also be based on a distance between Mover and Target (e.g., local versus long distance calls).

While various implementations and methods of getting on-line status, authentication, verification, authorization, communication and transaction services for web-enabled hardware and software, based on uniform telephone address according to the present invention have been described in detail, a skilled artisan will readily appreciate that numerous other implementations and variations of these implementations and methods are possible without departing from the spirit of the invention. Accordingly, the scope of the invention is defined by the claims set forth below.

Claims

1. A method for wireless or wired network communication between network resources each having a unique telephone number associated therewith, said method comprising:

forming a primary number file (PNF) comprising a uniform telephone address (UTA) which has a telephone number associated with a network resource;

forming a secondary number file and a default number file, said secondary and default number files being mirror images of said primary number file;

storing said default number file at a switch server which provides connectivity services for said network resources and is itself a network resource; and

storing said secondary number file at an internet service provider,

wherein at least one of two communicating network resources is a web disabled wire line or mobile or satellite communication device.

2. The method as claimed in claim 1 wherein the Internet Service Provider is a conventional wire line or mobile or satellite Telecommunication Service Provider (TSP) using GSM-MAP or ANSI-41 or similar transport; and TSP is using SS7 or Number Portability or other signaling networks.

3. A method for wireless or wired network communication between network resources each having a unique telephone number associated therewith, said method comprising:

forming a primary number file (PNF) comprising a uniform telephone address (UTA) which has a telephone number associated with a network resource; forming a secondary number file and a default number file, said secondary and default number files being mirror images of said primary number file;

storing said default number file at a switch server which provides connectivity services for said network resources and is itself a network resource;

storing said secondary number file at an internet service provider; and

assigning to a network resource a Primary URL each time when said network resource enters a network,

wherein the Primary URL is at least one of:

IP address or DNS or Internet Keyword;

a Caller ID used in the landline communication networks;

an International Mobile Station Identifier (IMSI) used in GSM-MAP;

a Mobile ID Number (MIN) used in ANSI-41; and

an Identifier used in a telecommunication protocols and/or services;

the Primary URL being retrieved via said at least one of said protocols and/or services and stored in said PNF, SNF and DNF as a value in the Primary URL field.

4. A method for wireless or wired network communication between network resources each having a unique telephone number associated therewith, said method comprising:

storing said secondary number file at an internet service provider,

wherein

said communication method comprises establishing communication between Mover and Target network resources,

an UTA Subscription Authority creates and registers UTA associated with a particular Target and creates a Primary Number File for the particular Target,

a Certification Authority (CA) creates a Digital Certificate (DC), and

said particular Target is SSL enabled,

said method further comprising: said particular Target providing required fields of Primary Number File and generates Certificate Signature Request (CSR) file, Public key and Private key files, said Private Key being securely stored in a memory of said particular target;

said particular Target providing its CSR and Public key to the UTA CA for signature, said Public key file and said UTA Primary Number File being encrypted by CA with CA Private Key, and the encrypted message representing a UTA Digital Certificate;

said CA encrypting said CSR and returning said CSR to said particular Target as a Digital Certificate (DC) of said particular Target;

said particular Target storing said DC in the Primary Number file of said particular Target and making said DC available for SSL procedure; and the Authorization Center (AC) is the Certification Authority (CA).

5. A method for wireless or wired network communication between network resources each having a unique telephone number associated therewith, said method comprising:

storing said secondary number file at an internet service provider,

wherein

a Certification Authority (CA) creates a Digital Certificate (DC), and

said particular Target is SSL enabled,

said method further comprising: said particular Target providing required fields of Primary Number File and generates Certificate Signature Request (CSR) file, Public key and Private key files, said Private Key being securely stored in a memory of said particular target; said particular Target providing its CSR and Public key to the UTA CA for signature, said Public key file and said UTA Primary Number File being encrypted by CA with CA Private Key, and the encrypted message representing a UTA Digital Certificate;

said particular Target storing said DC in the Primary Number file of said particular Target and making said DC available for SSL procedure; and

the Authorization Center (AC) is the Internet Service Provider (ISP) or the Authorization Center (AC) is the Telecommunication service provider (TSP).

6. A method for wireless or wired network communication between network resources each having a unique telephone number associated therewith, said method comprising:

storing said secondary number file at an internet service provider,

wherein

said switch server is a Certification Authority (CA); said communication method further comprises providing secure transaction services between Buying Target network resources and Selling Target network resources;

said secure transaction includes processing payment between a Buying target and a Selling target, said method further comprising said Buying Target composing a purchase message, said purchase message comprising: a DC of said Selling Target, and Purchase data; and

the purchase message further comprises an Encrypted Account Record (EAR).

7. A system comprising:

a plurality of wireless or wired network resources each having a unique telephone number associated therewith;

a switch server which provides connectivity services for said network resources and is itself a network resource;

a primary number file (PNF) comprising a uniform telephone address (UTA) which has a telephone number associated with at least one of said network resources;

a secondary number file; and

a default number file,

wherein

said secondary and default number files are mirror images of said primary number file,

said default number file is stored at said a switch server, said secondary number file is stored at said internet service provider,

said switch server is a Certification Authority (CA),

said system further comprises means for providing secure transaction services between Buying Target network resources and Selling Target network resources,

said means for providing secure transaction services comprise:

means for processing payment between a Buying target and a Selling target;

said Buying Target composing a purchase message, said purchase message comprising:

a DC of said Selling Target, and

Purchase data; and

the purchase message further comprises an Encrypted Account Record (EAR).

8. A method for wireless or wired network communication between network resources each having a unique telephone number associated therewith, said method comprising:

storing said default number file at a switch server which provides connectivity services for said network resources and is itself a network resource; and storing said secondary number file at an internet service provider,

wherein

said communication method comprises answering an incoming IP call from a Mover network resource received by a Target network resource, said method further comprising:

automatically turning said Target into receive mode which include providing indication of the incoming IP call,

said Target attempting to retrieve UTA of said Mover and a Digital Certificate from said Mover Primary Number file,

said Target checking UTA and Digital Certificate validity and privileges of said Target; and

said Target deciding to allow or to deny connection of said Mover in accordance with security/calling policy, privileges and preferences of both said Target and said Mover provided in metadata of said Number File and said Digital Certificates;

if said IP call is a secure call then both said Mover and said Target encrypt the exchange using SSL and PKI, their respective Private and Public keys;

said secure call facilitates purchase, payment and other secure transaction services;

at least one of said purchase, payment and other secure transaction services uses a credit card, said credit card having a credit card record (CCR); and

the Credit Card Record (CCR) comprises information embossed or printed on the credit card surface, said information comprising at least one of: a credit card system name, an owner's name; an issue date; an expiration date; and credit card number.

9. The method as claimed in claim 8, wherein the CCR further comprises at least one of credit card billing address and other required credit card authorization information.

10. A method for wireless or wired network communication between network resources each having a unique telephone number associated therewith, said method comprising:

storing said secondary number file at an internet service provider,

wherein

said Target checking UTA and Digital Certificate validity and privileges of said Target; and said Target deciding to allow or to deny connection of said Mover in accordance with security/calling policy, privileges and preferences of both said Target and said Mover provided in metadata of said Number File and said Digital Certificates;

at least one of said purchase, payment and other secure transaction services uses a credit card, said credit card having a credit card record (CCR);

Bank Account Record (BAR) or Service Provider Account Record (SPAR) is being used instead of the CCR; and

an Account Records (AR) comprises at least one of the CCR, the BAR and the SPAR.

11. The method as claimed in claim 10, wherein the BAR comprises: bank name, account and routing numbers, and other information required for nationwide and/or worldwide banking systems to enable bank account payments.

12. The method as claimed in claim 11 wherein the BAR further comprises a beneficiary name and or other beneficiary ID.

13. A method of encryption of an Account Record (AR) of a particular network resource using an Authorization Center (AC) Public key, the method comprising forming an Encrypted Account Record (EAR) capable of being decrypted using AC Private key, whereby only AC is capable of decrypting the EAR when authorizing a transaction.

14. The method as claimed in claim 13 further comprising storing the encrypted EAR in a network resource Primary Number File (PNF) in the PNF public or PNF secure area metadata.

15. The method as claimed in claim 13, wherein said AC uses AC's Private key to encrypt both said network resource UTA and said network resource EAR thereby forming encrypted authorization message (EAM) comprising UTA and EAR, the EAM is being used along with the ordinary DC issued by the CA for authorization puφoses; or

said AC:

retrieves said particular network resource Digital Certificate (DC);

decrypts said DC using Certification Authority Public key;

retrieves the particular network resource UTA and Public key from the decrypted DC;

authenticates the network resource in a strong mode; and

if the network resource is authentic, uses AC Private key to encrypt both said network resource Public key and said network resource EAR thus forming encrypted authorization dataset (EAD) comprising said network resource Public key and EAR, the EAD being used for strong authentication to authenticate the use of EAR by the particular network resource having the particular network resource Public key.

16. The method as claimed in claim 13, wherein said AC:

retrieves said particular network resource Digital Certificate (DC); decrypts said DC using Certification Authority Public key;

authenticates the network resource in a strong mode; and

if the network resource is authentic, uses AC's Private key to encrypt said network resource UTA and said network resource EAR and said network resource Public key thus forming Authorization Digital Certificate (ADC) comprising said UTA, EAR and Public key, the EAR being used by at least Authorization Center for authorization and authentication puφoses.

17. The method as claimed in the claim 4, wherein said CSR comprises at least three components including: the network resource UTA, the network resource Public key and the network resource Encrypted Account Record (EAR);

the Digital Certificate (DC) issued by AC/CA comprises said at least three components; and

the Digital Certificate (DC) represents an Authorization Digital Certificate (ADC) and is used for authorization and authentication puφoses.

18. The method as claimed in claim 17, wherein said AC/CA is the Subscription Authority (SA); and

AC/CA/SA issues the network resource ADC and the said network resource Number File comprising at least said network resource UTA, Encrypted Account Record (EAR) and ADC.

19. A system comprising:

a secondary number file; and

a default number file,

wherein

said default number file is stored at said a switch server,

said secondary number file is stored at said internet service provider,

said switch server is a Certification Authority (CA),

said means for providing secure transaction services comprise:

means for processing payment between a Buying target and a Selling target;

a DC of said Selling Target, and Purchase data;

said Selling Target comprises means for composing a charge message, said charge message comprising:

a DC of said Buying Target,

said Purchase message signed using a Private Key of said Buying target, and

said Purchase data;

said system further comprising an Authorization Center for composing an authorization message, said authorization message comprising:

a DC of said Buying Target,

said Purchase message signed using a Private Key of said Buying target, and

said Purchase data;

said system further comprising:

means for establishing wired or wireless connection between said Buying target and said Selling target;

means for displaying or otherwise indicating purchase/transaction data to said Buying and Selling target, said purchase transaction data comprising a purchase description and a value of said purchase;

means for receiving an authorization of said Buying target for said purchase,

wherein, if said authorization is granted:

executing Buyer / Seller cross-authentication;

if said Selling Target and said Buying target are authentic, then

said Buying target composes said purchase message; said Buying target connects to the Authorization Center using Primary URL of the Authorization Center;

said Buying target executes cross-authentication with the Authorization Center; said Buying target transmits said purchase message to the Authorization Center; and

either:

said Authorization Center decrypts said purchase message using said Public Key of said Buying target taken from DC of said Buying target during authentication;

said Authorization Center composing said authorization message;

said Authorization Center transmitting said Authorization message to said Buying target;

said Buying target transmits said Authorization message to said Selling target;

the Selling target decrypts said Authorization message using a Public key of said Authorization Center;

or:

said Authorization Center resolves via said Switch server Primary URL of said Selling target using UTA of said Seller taken from DC of said Selling target, or takes Primary URL of said Selling Target from said Purchase message; said Authorization Center connects to said Selling target using said Primary URL of said Selling target;

said Authorization Center authenticates the Selling target and if Selling target is authentic:

said Authorization Center verifies said Selling Target and said Buying target, and said purchase data;

said Authorization Center composes said Authorization message;

said Authorization Center transmits said Authorization message to said Selling target; and

said Selling target decrypts said Authorization message using said Public key of said Authorization Center; and

AC comprises credit card payment authorization terminal means, the AC being capable of:

using an existing Credit Card System (CCS) transaction infrastructure;

receiving the Purchase message or Charge message;

decrypting the Purchase or Charge messages for retrieving from said messages said purchase data and said EAR;

decrypting said EAR thus retrieving said CCR;

transmitting the retrieved CCR along with purchase data to the credit card payment authorization terminal means, said credit card payment authorization terminal mean transmitting the CCR along with the purchase data to a credit card authorization center for authorization; granting authorization for the purchase if said credit card authorization center's authorization is granted; and

denying the authorization for the purchase if said credit card authorization center's authorization is denied.

20. The system as claimed in claim 19, wherein BAR or SPAR is being used instead of CCR; and the particular bank or service provider's payment authorization terminal means and authorization infrastructure is being used instead of CCS authorization means and infrastructure.

21. The method as claimed in claim 16, wherein said issued Authorization Digital Certificate (ADC) is being used to authenticate the network resource UTA, and to authenticate the right of the authenticated network resource UTA to use the particular EAR contained in the ADC.

22. The method as claimed in claim 15, wherein: the DC and the EAM are used together; the DC issued by CA is being used to authenticate the network resource UTA; and the EAM issued by AC is being used to authenticate the right of the authenticated UTA network resource to use the EAR contained in the EAM.

23. A system comprising:

a plurality of wireless or wired network resources each having a unique telephone number associated therewith; a switch server which provides connectivity services for said network resources and is itself a network resource;

a secondary number file; and

a default number file,

wherein

said default number file is stored at said a switch server,

said secondary number file is stored at said internet service provider,

said switch server is a Certification Authority (CA),

said means for providing secure transaction services comprise:

means for processing payment between a Buying target and a Selling target;

a DC of said Selling Target, and

Purchase data;

said Selling Target comprises means for composing a charge message, said charge message comprising: a DC of said Buying Target,

said Purchase message signed using a Private Key of said Buying target, and

said Purchase data;

a DC of said Buying Target,

said Purchase message signed using a Private Key of said Buying target, and

said Purchase data;

said system further comprising:

means for receiving an authorization of said Buying target for said purchase,

wherein, if said authorization is granted:

executing Buyer / Seller cross-authentication;

if said Selling Target and said Buying target are authentic, then

said Buying target composes said purchase message;

said Buying target connects to the Authorization Center using Primary URL of the Authorization Center; said Buying target executes cross-authentication with the Authorization Center; said Buying target transmits said purchase message to the Authorization Center; and

either:

said Authorization Center composing said authorization message;

said Buying target transmits said Authorization message to said Selling target;

or:

said Authorization Center resolves via said Switch server Primary URL of said Selling target using UTA of said Seller taken from DC of said Selling target, or takes Primary URL of said Selling Target from said Purchase message;

said Authorization Center connects to said Selling target using said Primary URL of said Selling target; said Authorization Center authenticates the Selling target and if Selling target is authentic:

said Authorization Center composes said Authorization message;

the authorization for purchase is being granted by the Buying Target in a form of an entered credit card PIN code.

24. A method of defining a password, where a network resource user initiates a password definition/change procedure; the network resource prompts the user to identify the old password; and/or the network resource prompts the user to identify the new password and confirm the entered new password by entering the new password a second time in a separate prompt, the method comprising:

encrypting the new password by using a network resource Public key; and

forming an Encrypted Password Record (EPR) which can be decrypted by said network resource Private key, whereby only said network resource is capable of decrypting said EPR when a password is entered by a user.

25. The method as claimed in claim 24, wherein the EPR is being stored in a network resource Primary Number File (PNF) in the PNF public or PNF secure area metadata.

26. A system comprising:

a secondary number file; and

a default number file,

wherein

said default number file is stored at said a switch server,

said secondary number file is stored at said internet service provider,

said switch server is a Certification Authority (CA),

said means for providing secure transaction services comprise: means for processing payment between a Buying target and a Selling target;

a DC of said Selling Target, and

Purchase data;

a DC of said Buying Target,

said Purchase message signed using a Private Key of said Buying target, and

said Purchase data;

a DC of said Buying Target,

said Purchase message signed using a Private Key of said Buying target, and

said Purchase data;

said system further comprising:

means for receiving an authorization of said Buying target for said purchase, wherein, if said authorization is granted:

executing Buyer / Seller cross-authentication;

if said Selling Target and said Buying target are authentic, then

said Buying target composes said purchase message;

said Buying target connects to the Authorization Center using Primary URL of the Authorization Center;

either:

said Authorization Center composing said authorization message;

said Buying target transmits said Authorization message to said Selling target;

or: said Authorization Center resolves via said Switch server Primary URL of said Selling target using UTA of said Seller taken from DC of said Selling target, or takes Primary URL of said Selling Target from said Purchase message;

said Authorization Center connects to said Selling target using said Primary URL of said Selling target;

said Authorization Center composes said Authorization message;

the authorization for purchase is being granted by the said Buying Target by entering a PIN code or password provided by a network or a PIN code or password related to handset or to SIM card or password defined by the user.

27. A method for wireless or wired network communication between network resources each having a unique telephone number associated therewith, said method comprising:

storing said secondary number file at an internet service provider,

wherein

said switch server is a Certification Authority (CA);

said communication method further comprises providing secure transaction services between Buying Target network resources and Selling Target network resources;

said secure transaction includes processing payment between a Buying target and a Selling target, said method further comprising said Buying Target composing a purchase message, said purchase message comprising: a DC of said Selling Target, and Purchase data; said method further comprising said Selling Target composing a charge message, said charge message comprising: a DC of said Buying Target, said Purchase message signed using a Private Key of said Buying target, and said Purchase data; said method further comprising an Authorization Center composing an authorization message, said authorization message comprising: a DC of said Buying Target, said Purchase message signed using a Private Key of said Buying target, and said Purchase data;

said method further comprising: establishing wired or wireless connection between said Buying target and said Selling target; displaying or otherwise indicating purchase/transaction data to said Buying and Selling target, said purchase transaction data comprising a purchase description and a value of said purchase; waiting to receive an authorization of said Buying target for said purchase and if said authorization is granted: executing Buyer / Seller cross-authentication; if said Selling Target and said Buying target are authentic, then said Buying target composes said purchase message; said Buying target connects to the Authorization Center using Primary URL of the Authorization Center; said Buying target executes cross-authentication with the Authorization Center; said Buying target transmits said purchase message to the Authorization Center; and either: said Authorization Center decrypts said purchase message using said Public Key of said Buying target taken from DC of said Buying target during authentication; said Authorization Center composing said authorization message; said Authorization Center transmitting said Authorization message to said Buying target; said Buying target transmits said Authorization message to said Selling target; the Selling target decrypts said Authorization message using a Public key of said Authorization Center; or: said Authorization Center resolves via said Switch server Primary URL of said Selling target using UTA of said Seller taken from DC of said Selling target, or takes Primary URL of said Selling Target from said Purchase message; said Authorization Center connects to said Selling target using said Primary URL of said Selling target; said Authorization Center authenticates the Selling target and if Selling target is authentic: said Authorization Center verifies said Selling Target and said Buying target, and said purchase data; said Authorization Center composes said Authorization message; said Authorization Center transmits said Authorization message to said Selling target; and said Selling target decrypts said Authorization message using said Public key of said Authorization Center; and the authorization for purchase is being granted by the said Buying Target by entering a credit card PIN code.

28. A method for wireless or wired network communication between network resources each having a unique telephone number associated therewith, said method comprising:

storing said secondary number file at an internet service provider,

wherein

said switch server is a Certification Authority (CA);

said secure transaction includes processing payment between a Buying target and a Selling target, said method further comprising said Buying Target composing a purchase message, said purchase message comprising: a DC of said Selling Target, and Purchase data; said method further comprising said Selling Target composing a charge message, said charge message comprising: a DC of said Buying Target, said Purchase message signed using a Private Key of said Buying target, and said Purchase data;

said method further comprising an Authorization Center composing an authorization message, said authorization message comprising: a DC of said Buying Target, said Purchase message signed using a Private Key of said Buying target, and said Purchase data;

said method further comprising: establishing wired or wireless connection between said Buying target and said Selling target; displaying or otherwise indicating purchase/transaction data to said Buying and Selling target, said purchase transaction data comprising a purchase description and a value of said purchase; waiting to receive an authorization of said Buying target for said purchase and if said authorization is granted: executing Buyer / Seller cross-authentication; if said Selling Target and said Buying target are authentic, then said Buying target composes said purchase message; said Buying target connects to the Authorization Center using Primary URL of the Authorization Center; said Buying target executes cross-authentication with the Authorization Center; said Buying target transmits said purchase message to the Authorization Center; and either: said Authorization Center decrypts said purchase message using said Public Key of said Buying target taken from DC of said Buying target during authentication; said Authorization Center composing said authorization message; said Authorization Center transmitting said Authorization message to said Buying target; said Buying target transmits said Authorization message to said Selling target; the Selling target decrypts said Authorization message using a Public key of said Authorization Center; or: said Authorization Center resolves via said Switch server Primary URL of said Selling target using UTA of said Seller taken from DC of said Selling target, or takes Primary URL of said Selling Target from said Purchase message; said Authorization Center connects to said Selling target using said Primary URL of said Selling target; said Authorization Center authenticates the Selling target and if Selling target is authentic: said Authorization Center verifies said Selling Target and said Buying target, and said purchase data;

said Authorization Center composes said Authorization message; said Authorization Center transmits said Authorization message to said Selling target; and said Selling target decrypts said Authorization message using said Public key of said Authorization Center; and the authorization for purchase is being granted by the said Buying Target by entering a PIN code or password provided by a network or a PIN code or password related to handset or to SIM card or password defined by the user.

29. A method as claimed in claim 28, wherein the PIN code or password is being encrypted by using the Buying Target Public key thus forming an Encrypted Password Record (EPR) and said EPR is being stored in the public or secure area of the Buying Target PNF metadata.

30. The method as claimed in claim 29, wherein when the Buying Target authorizes a purchase by entering a PIN code or password, the Buying Target displays or otherwise indicates to the user an invitation to enter the PIN code or password to authorize the purchase; and PIN code or password is being entered by the user; and in order to verify the entered PIN code or password comprises one of:

the Buying Target encrypting the entered PIN code or password by using the Buying Target Public key thus forming Password Check Request (PCR);

retrieving from the Buying Target PNF metadata the saved encrypted password record (EPR);

the Buying Target comparing the PCR with the EPR;

the Buying Target granting authorization for the purchase if the PCR is identical to the EPR; and

the Buying Target denying authorization if the PCR is not identical to the EPR;

or:

the Buying Target retrieving the saved EPR from the Buying Target PNF metadata;

decrypting the retrieved EPR by using the Buying Target Private key thus forming Password Check Request (PCR);

the said Buying Target comparing the entered PIN code or password with the decrypted PCR;

the Buying Target granting authorization for the purchase if the PCR is identical to the entered PIN code or password; and

the Buying Target denying authorization if the PCR is not identical to the PIN code or password.

31. The method as claimed in claim 4, wherein:

the AC/CA is using two pairs of Private and Public keys;

the first pair of Private and Public keys are used for Certification /authentication puφoses and the second pair of Private and Public keys are used for Authorization puφoses;

the first AC/CA Private key is used by CA/AC to sign the ADC comprising particular network resource UTA, EAR and Public key;

the first AC/CA Public key is used by AC/CA and third parties to decrypting the ADC in order to authenticate particular network resources;

the second AC/CA Public key is used by AC/CA and third parties encrypting a particular network resource Account Record (AR) thus forming Encrypted AR (EAR); and

the second AC/CA Private key is used by AC/CA decrypting EAR for authorization puφoses.

32. A method for wireless or wired network communication between network resources each having a unique telephone number associated therewith, said method comprising:

wherein

said communication method comprises establishing communication between Mover and Target network resources and performing authentication in secure mode,

said switch server is a Certification Authority (CA), and

a second target network resource authenticates a first target network resource,

said method further comprising: said first target encrypting a fist dataset using a first Private Key thereby forming first new dataset; said first target composing a fist check message containing a first Digital Certificate (DC) and said first new dataset; said first target transmitting said first check message to said second target; said second target retrieving said first DC and said first new dataset from said fist check message; said second target decrypting said first DC using a Public Key of said CA; said second target retrieving said first dataset and said Public Key from the decrypted first DC; said second target decrypting said first new dataset using said first Public Key forming a second dataset; said second target comparing said second dataset with said first dataset; and if said second dataset is identical to said first Dataset, said second target decides that said first target possess correct first Private Key and the verified first dataset, thereby authenticating said first target; and the second Target is enabled to display or otherwise indicate to the user that authentication has been complete successfully or has failed.

33. A method for wireless or wired network communication between network resources each having a unique telephone number associated therewith, said method comprising:

storing said secondary number file at an internet service provider,

wherein

said switch server is a Certification Authority (CA),

said communication method further comprises providing secure transaction services between Buying Target network resources and Selling Target network resources, and

the Selling Target is enabled to display or otherwise indicate to the user that transaction has been complete successfully or has failed.

34. A method for wireless or wired network communication between network resources each having a unique telephone number associated therewith, said method comprising: forming a primary number file (PNF) comprising a uniform telephone address (UTA) which has a telephone number associated with a network resource;

storing said secondary number file at an internet service provider,

wherein

said switch server is a Certification Authority (CA);

said method further comprising: establishing wired or wireless connection between said Buying target and said Selling target; displaying or otherwise indicating purchase/transaction data to said Buying and Selling target, said purchase transaction data comprising a purchase description and a value of said purchase; waiting to receive an authorization of said Buying target for said purchase and if said authorization is granted: executing Buyer / Seller cross-authentication; if said Selling Target and said Buying target are authentic, then said Buying target composes said purchase message; said Buying target connects to the Authorization Center using Primary URL of the Authorization Center; said Buying target executes cross-authentication with the Authorization Center; said Buying target transmits said purchase message to the Authorization Center; and either: said Authorization Center decrypts said purchase message using said Public Key of said Buying target taken from DC of said Buying target during authentication; said Authorization Center composing said authorization message; said Authorization Center transmitting said Authorization message to said Buying target; said Buying target transmits said Authorization message to said Selling target; the Selling target decrypts said Authorization message using a Public key of said Authorization Center; or: said Authorization Center resolves via said Switch server Primary URL of said Selling target using UTA of said Seller taken from DC of said Selling target, or takes Primary URL of said Selling Target from said Purchase message; said Authorization Center connects to said Selling target using said Primary URL of said Selling target; said Authorization Center authenticates the Selling target and if Selling target is authentic: said Authorization Center verifies said Selling Target and said Buying target, and said purchase data; said Authorization Center composes said Authorization message; said Authorization Center transmits said Authorization message to said Selling target; and said Selling target decrypts said Authorization message using said Public key of said Authorization Center; and the Buying Target network resource is enabled to display or otherwise indicate to the user:

that authorization has been complete successfully, if Authorization from Authorization Center has been granted; and

that authorization has been denied, if Authorization from Authorization Center has not been granted.

35. A method for wireless or wired network communication between network resources each having a unique telephone number associated therewith, said method comprising:

storing said secondary number file at an internet service provider,

wherein

^■ said switch server is a Certification Authority (CA);

said communication method further comprises providing secure transaction services between Buying Target network resources and Selling Target network resources; said secure transaction includes processing payment between a Buying target and a Selling target, said method further comprising said Buying Target composing a purchase message, said purchase message comprising: a DC of said Selling Target, and Purchase data; said method further comprising said Selling Target composing a charge message, said charge message comprising: a DC of said Buying Target, said Purchase message signed using a Private Key of said Buying target, and said Purchase data;

said method further comprising: establishing wired or wireless connection between said Buying target and said Selling target; displaying or otherwise indicating purchase/transaction data to said Buying and Selling target, said purchase transaction data comprising a purchase description and a value of said purchase; waiting to receive an authorization of said Buying target for said purchase and if said authorization is granted: executing Buyer / Seller cross-authentication; if said Selling Target and said Buying target are authentic, then said Buying target composes said purchase message; said Buying target transmits said purchase message to said Selling target; said Selling target decrypts said purchase message using a Public Key of said Buying target taken from DC of said Buying target, verifies the purchase data, and if applicable to policy and if purchase data is correct then said Selling Target composes said Charge message; said Selling Target connects to said Authorization Center using Primary URL of said Authorization Center; said Selling Target executes cross-authentication with the Authorization Center, and if cross-authentication succeeds: said Selling target transmits said Charge message to said Authorization Center; said Authorization Center decrypts said Charge message using a Public Key of said Selling target and retrieves and decrypts said Purchase message using said Public Key of said Buying target taken from said DC of said Buying target; said Authorization Center verifies the purchase data, and Selling and Buying targets; said Authorization Center composes said Authorization message; said Authorization Center transmits said Authorization message to said Selling target; and said Selling target decrypts said Authorization message using Public key of said Authorization Center. wherein:

the Authorization Center transmits the Authorization Message to the Buying Target network resource;

the Buying target decrypts said Authorization message using Public key of said Authorization Center;

the Buying Target network resource is enabled to display or otherwise indicate to the user that authorization has been complete successfully, if Authorization from Authorization Center has been granted; and

the Buying Target network resource is enabled to display or otherwise indicate to the user that authorization has been denied, if Authorization from Authorization Center has been denied.

36. A method for wireless or wired network communication between network resources each having a unique telephone number associated therewith, said method comprising:

storing said secondary number file at an internet service provider,

wherein

said switch server is a Certification Authority (CA);

.13 said communication method further comprises providing secure transaction services between Buying Target network resources and Selling Target network resources;

said method further comprising: establishing wired or wireless connection between said Buying target and said Selling target; displaying or otherwise indicating purchase/transaction data to said Buying and Selling target, said purchase transaction data comprising a purchase description and a value of said purchase; waiting to receive an authorization of said Buying target for said purchase and if said authorization is granted: executing Buyer / Seller cross-authentication; if said Selling Target and said Buying target are authentic, then said Buying target composes said purchase message; said Buying target transmits said purchase message to said Selling target; said Selling target decrypts said purchase message using a Public Key of said Buying target taken from DC of said Buying target, venfies the purchase data, and if applicable to policy and if purchase data is correct then said Selling Target composes said Charge message, said Selling Target connects to said Authonzation Center using Pnmary URL of said Authoπzation Center; said Selling Target executes cross-authentication with the Authoπzation Center, and if cross-authentication succeeds said Selling target transmits said Charge message to said Authoπzation Center; said Authonzation Center decrypts said Charge message using a Public Key of said Selling target and retneves and decrypts said Purchase message using said Public Key of said Buying target taken from said DC of said Buying target, said Authorization Center venfies the purchase data, and Selling and Buying targets; said Authonzation Center composes said Authonzation message; said Authorization Center transmits said Authonzation message to said Selling target; and said Selling target decrypts said Authorization message using Public key of said Authorization Center; wherein:

the Selling Target network resource transmits the Authorization Message to the Buying Target network resource;

the said Buying target decrypts said Authorization message using Public key of said Authorization Center;

the Buying Target network resource is enabled to display or otherwise indicate to the user that authorization has been granted, if the Authorization from Authorization Center has been granted; and

37. A system comprising:

a secondary number file; and

a default number file, wherein

said default number file is stored at said a switch server,

said secondary number file is stored at said internet service provider,

said switch server is a Certification Authority (CA),

said means for providing secure transaction services comprise:

means for processing payment between a Buying target and a Selling target;

a DC of said Selling Target, and

Purchase data;

a DC of said Buying Target,

said Purchase message signed using a Private Key of said Buying target, and

said Purchase data;

a DC of said Buying Target,

said Purchase message signed using a Private Key of said Buying target, and said Purchase data;

said system further comprising:

means for displaying or otherwise indicating purchase/transaction data to said Buying and Selling target, said purchase transaction data comprising a purchase description and a value of said purchase; and

means for receiving an authorization of said Buying target for said purchase,

wherein, if said authorization is granted:

executing Buyer / Seller cross-authentication;

if said Selling Target and said Buying target are authentic, then

said Buying target composes said purchase message;

said Buying target transmits said purchase message to said Selling target;

said Selling target decrypts said purchase message using a Public Key of said Buying target taken from DC of said Buying target, verifies the purchase data, and if applicable to policy and if purchase data is correct then

said Selling Target composes said Charge message;

said Selling Target connects to said Authorization Center using Primary URL of said Authorization Center;

said Selling Target executes cross-authentication with the Authorization Center, and if cross-authentication succeeds: said Selling target transmits said Charge message to said Authorization Center;

said Authorization Center decrypts said Charge message using a Public Key of said Selling target and retrieves and decrypts said Purchase message using said Public Key of said Buying target taken from said DC of said Buying target;

said Authorization Center verifies the purchase data, and Selling and Buying targets;

said Authorization Center composes said Authorization message;

said Selling target decrypts said Authorization message using Public key of said Authorization Center;

wherein AC comprises credit card payment authorization terminal means, the AC being capable of:

using an existing Credit Card System (CCS) transaction infrastructure;

receiving the Purchase message or Charge message;

decrypting said EAR thus retrieving said CCR; transmitting the retrieved CCR along with purchase data to the credit card payment authorization terminal means, said credit card payment authorization terminal mean transmitting the CCR along with the purchase data to a credit card authorization center for authorization;

granting authorization for the purchase if said credit card authorization center's authorization is granted; and

38. The system as claimed in claim 37, wherein BAR or SPAR is being used instead of CCR; and the particular bank or service provider's payment authorization terminal means and authorization infrastructure is being used instead of CCS authorization means and infrastructure.

39. The method as claimed in claim 17 wherein said issued Authorization Digital Certificate (ADC) is being used to authenticate the network resource UTA, and to authenticate the right of the authenticated network resource UTA to use the particular EAR contained in the ADC.

40. A system comprising:

a switch server which provides connectivity services for said network resources and is itself a network resource; a primary number file (PNF) comprising a uniform telephone address (UTA) which has a telephone number associated with at least one of said network resources;

a secondary number file; and

a default number file,

wherein

said default number file is stored at said a switch server,

said secondary number file is stored at said internet service provider,

said switch server is a Certification Authority (CA),

said means for providing secure transaction services comprise:

means for processing payment between a Buying target and a Selling target;

a DC of said Selling Target, and

Purchase data;

a DC of said Buying Target,

said Purchase message signed using a Private Key of said Buying target, and

said Purchase data; said system further comprising an Authorization Center for composing an authorization message, said authorization message comprising:

a DC of said Buying Target,

said Purchase message signed using a Private Key of said Buying target, and

said Purchase data;

said system further comprising:

means for receiving an authorization of said Buying target for said purchase,

wherein, if said authorization is granted:

executing Buyer / Seller cross-authentication;

if said Selling Target and said Buying target are authentic, then

said Buying target composes said purchase message;

said Buying target transmits said purchase message to said Selling target;

said Selling Target composes said Charge message; said Selling Target connects to said Authorization Center using Primary URL of said Authorization Center;

said Selling Target executes cross-authentication with the Authorization Center, and if cross-authentication succeeds:

said Selling target transmits said Charge message to said Authorization Center;

said Authorization Center composes said Authorization message;

wherein the authorization for purchase is being granted by the Buying Target in a form of an entered credit card PIN code.

41. A system comprising:

a secondary number file; and

a default number file,

wherein

said default number file is stored at said a switch server,

said secondary number file is stored at said internet service provider,

said switch server is a Certification Authority (CA),

said means for providing secure transaction services comprise:

means for processing payment between a Buying target and a Selling target;

a DC of said Selling Target, and

Purchase data; said Selling Target comprises means for composing a charge message, said charge message comprising:

a DC of said Buying Target,

said Purchase message signed using a Private Key of said Buying target, and

said Purchase data;

a DC of said Buying Target,

said Purchase message signed using a Private Key of said Buying target, and

said Purchase data;

said system further comprising:

means for receiving an authorization of said Buying target for said purchase,

wherein, if said authorization is granted:

executing Buyer / Seller cross-authentication;

if said Selling Target and said Buying target are authentic, then

said Buying target composes said purchase message; said Buying target transmits said purchase message to said Selling target;

said Selling Target composes said Charge message;

said Selling target transmits said Charge message to said Authorization Center;

said Authorization Center composes said Authorization message;

said Selling target decrypts said Authorization message using Public key of said Authorization Center; wherein the authorization for purchase is being granted by the said Buying Target by entering a PIN code or password provided by a network or a PIN code or password related to handset or to SIM card or password defined by the user.

42. A method for wireless or wired network communication between network resources each having a unique telephone number associated therewith, said method comprising:

storing said secondary number file at an internet service provider,

wherein

said switch server is a Certification Authority (CA);

said secure transaction includes processing payment between a Buying target and a Selling target, said method further comprising said Buying Target composing a purchase message, said purchase message comprising: a DC of said Selling Target, and

Purchase data; said method further comprising said Selling Target composing a charge message, said charge message comprising: a DC of said Buying Target, said Purchase message signed using a Private Key of said Buying target, and said Purchase data;

said method further comprising: establishing wired or wireless connection between said Buying target and said Selling target; displaying or otherwise indicating purchase/transaction data to said Buying and Selling target, said purchase transaction data comprising a purchase description and a value of said purchase; waiting to receive an authorization of said Buying target for said purchase and if said authorization is granted: executing Buyer / Seller cross-authentication; if said Selling Target and said Buying target are authentic, then said Buying target composes said purchase message; said Buying target transmits said purchase message to said Selling target; said Selling target decrypts said purchase message using a Public Key of said Buying target taken from DC of said Buying target, verifies the purchase data, and if applicable to policy and if purchase data is correct then said Selling Target composes said Charge message; said Selling Target connects to said Authorization Center using Primary URL of said Authorization Center; said Selling Target executes cross-authentication with the Authorization Center, and if cross-authentication succeeds: said Selling target transmits said Charge message to said Authorization Center; said Authorization Center decrypts said Charge message using a Public Key of said Selling target and retrieves and decrypts said Purchase message using said Public Key of said Buying target taken from said DC of said Buying target; said Authorization Center verifies the purchase data, and Selling and Buying targets; said Authorization Center composes said Authorization message; said Authorization Center transmits said Authorization message to said Selling target; and said Selling target decrypts said Authorization message using Public key of said Authorization Center; wherein the authorization for purchase is being granted by the said Buying Target by entering a credit card PIN code.

43. A method for wireless or wired network communication between network resources each having a unique telephone number associated therewith, said method comprising:

storing said secondary number file at an internet service provider,

wherein

said switch server is a Certification Authority (CA);

said method further comprising: establishing wired or wireless connection between said Buying target and said Selling target; displaying or otherwise indicating purchase/transaction data to said Buying and Selling target, said purchase transaction data comprising a purchase description and a value of said purchase; waiting to receive an authorization of said Buying target for said purchase and if said authorization is granted: executing Buyer / Seller cross-authentication; if said Selling Target and said Buying target are authentic, then said Buying target composes said purchase message; said Buying target transmits said purchase message to said Selling target; said Selling target decrypts said purchase message using a Public Key of said Buying target taken from DC of said Buying target, verifies the purchase data, and if applicable to policy and if purchase data is correct then said Selling Target composes said Charge message; said Selling Target connects to said Authorization Center using Primary URL of said Authorization Center; said Selling Target executes cross-authentication with the Authorization Center, and if cross-authentication succeeds: said Selling target transmits said Charge message to said Authorization Center; said Authorization Center decrypts said Charge message using a Public Key of said Selling target and retrieves and decrypts said Purchase message using said Public Key of said Buying target taken from said DC of said Buying target; said Authorization Center verifies the purchase data, and Selling and Buying targets; said Authorization Center composes said Authorization message; said Authorization Center transmits said Authorization message to said Selling target; and said Selling target decrypts said Authorization message using Public key of said Authorization Center; wherein the authorization for purchase is being granted by the said Buying Target by entering a PIN code or password provided by a network or a PIN code or password related to handset or to SIM card or password defined by the user.

44. A method as claimed in claim 43, wherein the PIN code or password is being encrypted by using the Buying Target Public key thus forming an Encrypted Password Record (EPR) and said EPR is being stored in the public or secure area of the Buying Target PNF metadata.

45. The method as claimed in claim 44, wherein when the Buying Target authorizes a purchase by entering a PIN code or password, the Buying Target displays or otherwise indicates to the user an invitation to enter the PIN code or password to authorize the purchase; and PIN code or password is being entered by the user; and in order to verify the entered PIN code or password comprises one of:

the Buying Target comparing the PCR with the EPR;

the Buying Target denying authorization if the PCR is not identical to the EPR;

or:

the Buying Target retrieving the saved EPR from the Buying Target PNF metadata;

the Buying Target granting authorization for the purchase if the PCR is identical to the entered PIN code or password; and the Buying Target denying authorization if the PCR is not identical to the PIN code or password.

46. The method as claimed in claim 13 further comprising selling said EAR, which is valid based on at least one of: a period of time, number of uses thereof, and a fixed money value of services provided.

47. The method as claimed in claim 13, further comprising:

recording at least one of said EAR on a recordable medium; and

selling said recordable medium having said at least one of said EAR recorded thereon.

48. The method as claimed in claim 47, wherein said recordable medium is a recordable memory chip or processor.

49. The method as claimed in claim 14, further comprising selling said EAR and/or said PNF to a third party on per provision charge basis.

50. The method as claimed in claim 14, further comprising selling said EAR and/or PNF authentication services on per authentication charge basis.

51. The method as claimed in claim 14, further comprising selling said EAR and/or PNF charge authorization services on per authorization charge basis.

52. The method as claimed in claim 13, further comprising:

storing, on a recordable medium, an instruction set comprising instructions for executing steps of:

accessing said AC public key; and

forming said EAR.

53. The method as claimed in claim 52, further comprising selling said recordable medium.

54. The method as claimed in claim 16 further comprising selling said ADC, which is valid based on at least one of: a period of time, number of uses thereof, and a fixed money value of services provided.

55. The method as claimed in claim 16, further comprising:

recording at least one of said ADC on a recordable medium; and

selling said recordable medium having said at least one of said ADC recorded thereon.

56. The method as claimed in claim 55, wherein said recordable medium is a recordable memory chip or processor.

57. The method as claimed in claim 16, further comprising selling said ADC and/or EAR to a third party on per provision charge basis.

58. The method as claimed in claim 16, further comprising selling said ADC and/or EAR on per authentication charge basis.

59. The method as claimed in claim 16, further comprising selling said ADC and/or EAR on per authorization charge basis.

60. The method as claimed in claim 16, further comprising:

retrieving said particular network resource Digital Certificate (DC);

decrypting said DC using Certification Authority Public key;

retrieving the particular network resource UTA and Public key from the decrypted DC;

authenticating the network resource in a strong mode; and

if the network resource is authentic, using AC's Private key to encrypt said network resource UTA and said network resource EAR and said network resource Public key thus forming Authorization Digital Certificate (ADC) comprising said UTA, EAR and Public key, the EAR being used by at least Authorization Center for authorization and authentication puφoses

61. The method as claimed in claim 60, further comprising selling said recordable medium.

62. The method as claimed in claim 24, further comprising selling said EPR, which is valid based on at least one of: a period of time, number of uses thereof, and a fixed money value of services provided.

63. The method as claimed in claim 24, further comprising:

recording at least one of said EPR on a recordable medium; and

selling said recordable medium having said at least one of said EPR recorded thereon.

64. The method as claimed in claim 63, wherein said recordable medium is a recordable memory chip or processor.

65. The method as claimed in claim 25, further comprising selling said EPR and/or said PNF to a third party on per provision charge basis.

66. The method as claimed in claim 25, further comprising selling said EPR and/or PNF authentication services on per authentication charge basis.

67. The method as claimed in claim 25, further comprising selling said EPR and/or PNF charge authorization services on per authorization charge basis.

68. The method as claimed in claim 24, further comprising:

encrypting the new password by using a network resource Public key; and

69. The method as claimed in claim 68, further comprising selling said recordable medium.

70. A method for wireless or wired network communication between network resources each having a unique telephone number associated therewith, said method comprising:

storing said secondary number file at an internet service provider, wherein

said Target checking UTA and Digital Certificate validity and privileges of said Target, and

said secure call facilitates purchase, payment and other secure transaction services; and

said communication method further comprises storing the Target UTA into an internal memory of said mover, said Target UTA being associated with said Mover performing pay or charge transaction.

71. The method as claimed in claim 70 further comprising Mover choosing one of pay or charge transactions.

72. The method as claimed in claim 70, wherein one of pay or charge transactions is used as a Mover's default transaction method.

73. The method as claimed in claim 70, wherein the Target UTA is stored into memory by manually typing the UTA number into data input field of the Mover user interface.

74. The method as claimed in claim 70, wherein the Mover is coupled to UTA input device.

75. The method as claimed in claim 74, wherein the input device is at least one of bar code reader, magnetic strip reader, smart card reader, medium reader, optical medium reader, Optical Character Recognition (OCR) scanner, and BlueTooth or IEEE 802.11 or similar transport protocols of sender/receiver or other input device.

76. The method as claimed in claim 70, wherein the Target UTA is being stored into the Mover memory by reading at least one of a bar code record, number, magnetic strip/medium, smart card chip, optical medium, memory chip or processor, carrier wave, and other substance encoding the Target UTA number.

77. The method as claimed in claim 76, wherein said encoding substance is printed on a surface of a physical medium, or stored in a memory chip, or recorded on the magnetic strip or medium, or recorded on the optical medium.

78. The method as claimed in claim 77, wherein the physical medium surface is at least one of networking device surface or display, plastic or paper or other card surface, a business card surface, a stripe, and any other physical medium surface.

79. The method as claimed in claim 70, wherein further comprising storing Transaction Values (TV) into internal memory of the Mover in association with the stored Target UTA and pay or charge transaction identifier.

80. The method as claimed in claim 79, wherein the Transaction Values include at least one of the values of money and currency of the purchase.

81. The method as claimed in claim 80, wherein the Transaction Values comprises a list of items being purchased.

82. The method as claimed in claim 81, wherein each item in the list of items being purchased comprises:

a name of the item; and

at least one of money and currency values of the item, bar code of the item, number of units or pieces of the item to be purchased, weight and/or other unit measurement characteristic of the item, and other applicable descriptive information of the item.

83. The method as claimed in claim 70, comprising:

resolving of the Target UTA stored in the Mover internal memory via Switch; and

receiving from the Switch at least on e of the Target on-line status, the Target Primary URL and the Target identifier.

84. The method as claimed in claim 79, comprising displaying via the Mover device to the Mover end user a transaction information comprising:

the stored Target UTA or/and Target identifier; the stored transaction values;

the pay or charge transaction identifier; and

the prompt to submit the transaction in regard to the Target UTA or /and its identifier and the values displayed.

85. The method as claimed in claim 79, further comprising:

Mover Choosing a Deal or Funds Transfer Agreement type for Mover Transaction Request (TR); and

Storing the chosen Agreement type into TR

86. The method as claimed in claim 79, wherein Mover is set up to use one of Deal or Funds Transfer Agreement type by default.

87. The method as claimed in claim 84, comprising the step of composing a Mover Transaction Request (TR)

88. The method as claimed in claim 86, wherein the TR comprises at least the Mover pay or charge transaction identifier, the Agreement identifier, the Transaction Values (TV), the Target UTA, and the Mover DC or ADC.

89. The method as claimed in claim 87, comprising:

entering the Mover end user password into the password input field and submitting the password;

verifying the entered password;

if the entered password is not correct denying the transaction; and

digitally signing the TR using Mover Private key.

90. The method as claimed in claim 89, wherein if the Funds Transfer Agreement type is used, the TR is a Funds Transfer Agreement (FTA), the method further comprising:

resolving Mover RUTA;

connecting to the RUTA financial institution;

cross-authenticating; and

transmitting the FTA to the financial institution.

91. The method as claimed in claim 89, wherein if the Deal Agreement type is used and the Target is on-line, the method further comprising:

said Mover:

connecting to the Target;

cross-authenticating with the Target;

if authentication succeeds transmitting the TR to the Target;

the Target:

decrypting the TR;

indicating to the Target end user the incoming transaction request;

displaying at least one of the Mover UTA or its associated Mover identifier and the TR values and transaction pay or charge identifier; and

displaying transaction "accept / reject" menu prompt; and

the Target end user:

choosing one of transaction "accept" or "reject" menu prompt; if "reject" was chosen the Target rejecting the transaction;

if "accept" was chosen the Target:

displaying to the Target end user a password input prompt;

Entering Target end user password into the password input field ;

submitting the password;

verifying the password; and

if the entered password is correct Composing a Deal Agreement (DA) which is comprising at least said TR and the Target DC or ADC;

where the DA is being digitally signed by the Target using the Target Private key.

92. The method as claimed in claim 91, wherein if the Mover is the payer under the DA the Target transmitting the signed DA to the Mover.

93. The method as claimed in claim 92, wherein, if the RUTA payment routing procedure and one of Target or Mover is a payer, the method further comprising:

connecting to the payer RUTA bank;

cross authenticating with the payer RUTA bank;

if authentication succeeds, authorizing the transaction with the payer RUTA bank; and

if authorization is granted the payer RUTA bank: transmitting the authorization message to the Mover and to the Target and the Target and Mover networking devices; and

displaying "authorization succeed" message to the Target and Mover end users.

94. The method as claimed in claim 91, wherein the DA comprises the Target pay or charge transaction identifier, the Agreement identifier, and the Transaction Values (TV).

95. The method as claimed in claim 91 wherein, if the Target is off-line or does not respond, the method comprising:

the Mover:

displaying on the Mover display at least one of the transaction values, the Target UTA, the pay or charge Mover transaction identifier, and a transaction authorization prompt for the Target end user comprising at least the Target end user secret password input field;

waiting for the Target end user to authorize the transaction by entering the end user password into the input field of said Mover and submitting the password;

composing said TR;

connecting to the Authorization Center (AC) via SSL;

cross-authenticating the connection;

transmitting TR and the password; and

the AC:

retrieving at least Target Encrypted Account Record (EAR) and the Target Public key and the Encrypted Password Record (EPR) from the PNF or SNF or from the DNF or from AC Encrypted Password Records database of registered Targets; encrypting the received Target end-user password using the Target Public key thus forming Target Password Check Request (PCR);

comparing the PCR with the EPR and if they are identical Granting authorization for the transaction;

charging the Buying Target Account Record and crediting the Selling Target Account Record;

composing Authorization message;

transmitting the Authorization message to the Mover and to the Target; and

displaying the authorization message on the Mover display.

96. The method according to claim 29, wherein, after storing the Encrypted Password Record (EPR) in the secure area of the particular UTA Target PNF metadata, the method further comprising:

securely transmitting the Encrypted Password Record (EPR) to the Authorization Center; and

storing the EPR in a secure database of the Authorization Center in association with the particular UTA Target for authorization puφoses.

97. A method for wireless or wired network communication between network resources each having a unique telephone number associated therewith, said method comprising:

storing said secondary number file at an internet service provider,

wherein

said switch server is a Certification Authority (CA),

said communication method further comprises providing secure transaction services between Buying Target network resources and Selling Target network resources,

Purchase data;

said method further comprising said Selling Target composing a charge message, said charge message comprising: a DC of said Buying Target; said Purchase message signed using a Private Key of said Buying target; said Purchase data; and

an Encrypted Account Record (EAR) of said Selling target or /and the Target RUTA.

98. A method for wireless or wired network communication between network resources each having a unique telephone number associated therewith, said method comprising: forming a primary number file (PNF) comprising a uniform telephone address (UTA) which has a telephone number associated with a network resource;

storing said secondary number file at an internet service provider,

wherein

said switch server is a Certification Authority (CA),

Purchase data;

a Password Check Request (PCR) of said Buying target

99. A method for wireless or wired network communication between network resources each having a unique telephone number associated therewith, said method comprising:

storing said secondary number file at an internet service provider,

wherein particular target UTA is payee or payer account number in a bank or a credit card system and the UTA Number File is the UTA Account File (AF).

100. A method for wireless or wired network communication between network resources each having a unique telephone number associated therewith, said method comprising:

storing said secondary number file at an internet service provider, wherein at least one UTA is assigned to a financial institution and used as a Routing UTA (RUTA) to allow payments for UTA accounts established by said institution for respective networking Targets acting as a payer or/and payee in the network.

101. A method for wireless or wired network communication between network resources each having a unique telephone number associated therewith, said method comprising:

storing said secondary number file at an internet service provider,

wherein

a Certification Authority (CA) creates a Digital Certificate (DC), and

said particular Target is SSL enabled,

said method further comprising: said particular Target providing required fields of Primary Number File and generates Certificate Signature Request (CSR) file, Public key and Private key files, said Private Key being securely stored in a memory of said particular target,

said particular Target providing its CSR and Public key to the UTA CA for signature, said Public key file and said UTA Primary Number File being encrypted by CA with CA Private Key, and the encrypted message representing a UTA Digital Certificate,

said CA encrypting said CSR and returning said CSR to said particular Target as a Digital Certificate (DC) of said particular Target, and

said particular Target storing said DC in the Primary Number file of said particular Target and making said DC available for SSL procedure;

said CSR and/or said DC comprising at least the particular Target UTA; and the particular Target Public key; and the particular Target RUTA.

102. The method as claimed in claim 101, wherein said RUTA is a compound RUTA comprising consecutive RUTA numbers orderly stored to reflect a corresponding relationship of their respective owners.

103. The method as claimed in claim 101, wherein said RUTA is a set of different RUTA belonging to different financial institutions wherein a particular Target UTA is an account number or is associated with an account in each of said institutions.

104. A method for wireless or wired network communication between network resources each having a unique telephone number associated therewith, said method comprising:

storing said secondary number file at an internet service provider,

wherein at least one of UTA is a Zero-based UTA (ZUTA) comprising or/and zero country code or/and zero area code or/and "zero based" telephone number.

105. The method as claimed in claim 104, wherein at least one ZUTA is a RUTA.

106. The method as claimed in claim 104, wherein particular RUTA country code and area code correspond to the location of a particular ZUTA financial institution.

107. The method as claimed in claim 104, wherein particular ZUTA "zero based" number is being issued and used as ordinal number of a particular ZUTA financial institution

108. A method for wireless or wired network communication between network resources each having a unique telephone number associated therewith, said method comprising:

storing said secondary number file at an internet service provider,

wherein each particular RUTA Number File comprising a Routing record field which is comprising SWIFT and/or other specific financial domestic or international routing numbers assigned for this particular financial institution and the appropriate descriptive routing information.

109. The method as claimed in claim 108, wherein Routing record field is being stored in a public or private metadata area of the Number File.

110. The method as claimed in claim 108, wherein the particular RUTA or UTA Number File comprising a Balance field which is being dynamically updated after each clearing operation or transaction.

111. A system comprising:

a secondary number file; and

a default number file,

wherein said secondary and default number files are mirror images of said primary number file,

said default number file is stored at said a switch server, and

said secondary number file is stored at said internet service provider,

said system further comprising bank or a credit card system wherein said bank or a credit card system using UTA numeration as a numeration for the bank or the credit card system accounts or said UTA numeration is mapped to the bank or credit card account numeration.

112. The system as claimed in claim 111, wherein the bank or the credit system is the UTA Subscription authority.

113. The system as claimed in claim 111, wherein the bank or the credit system is the Certification authority.

114. The system as claimed in claim 111, wherein the bank or the credit system is the Authorization Center.

115. The system as claimed in claim 111, wherein the bank or the credit card system is coupled to Authorization Center.

116. A method for wireless or wired network communication between network resources each having a unique telephone number associated therewith, said method comprising:

storing said secondary number file at an internet service provider; and

wherein:

while entering the network, a Switch authenticates said network resource using said DC; said network resource then synchronizes entries of said PNF with SNF and Default Number Files (DNF); and

SyncML is being used for said Primary and Secondary and Default Number Files synchronization puφoses.

117. A method for wireless or wired network communication between network resources each having a unique telephone number associated therewith, said method comprising:

storing said secondary number file at an internet service provider,

wherein

said method further comprises issuing a digital certificate to a network resource to enable use of said primary number file for secure transactions and secure layer protocols, said digital certificate comprising said network resource's telephone number, and

SIM Application Toolkit is being used for implementation of Public key cryptography applications and PKI and Number File management.

118. A method for wireless or wired network communication between network resources each having a unique telephone number associated therewith, said method comprising:

storing said secondary number file at an internet service provider,

wherein

WAP 1.2 or later specification is being used for implementation of Public key cryptography applications and PKI and Number File Management.

119. The method as claimed in claim 78, wherein the physical medium surfaces are the Target or its user belongings.

120. The method as claimed in claim 101, wherein RUTA is assigned to an Automatic Teller Machine (ATM), the method comprising: generating a "Cash Request" using the ATM machine in order to charge any UTA networking device; and after on-line or off-line authorization of the transaction by a particular UTA end user, dispensed cash to the requesting ATM user.

121. The method as claimed in claim 120 wherein the POS terminal is implemented as the ATM.

122. The method as claimed in claim 120, wherein: an ATM client chooses an UTA withdraw operation by typing in the UTA via an ATM interface or inputting the UTA card to be read by the ATM; if the UTA is OFF-line, the ATM requires ATM client to enter a password; and when authorization is given the ATM provides cash to the ATM user.

123. The method as claimed in claim 120, wherein: the ATM is equipped with a telephone or videophone to provide live authentication by voice and/or picture; the Target is enabled to communicate with the Mover when authorizing a payment; and the Mover receives cash from the ATM in an ON-line mode if Target has provided authorization.

124. The method as claimed in claim 108, wherein RUTA number is assigned to an Automatic Clearing House (ACH) institution, and represents a corresponding account for all ACH member institutions.

125. The method as claimed in claim 124, wherein the ACH member institutions are members of RUTA infrastructure and each of the ACH members is assigned a RUTA-B number.

126. The method as claimed in claim 125, wherein SWIFT has a RUTA-SW number, and each SWIFT number associated with a particular SWIFT-member bank is addressable via RUTA infrastructure as RUTA-SW/RUTA-B.

127. The method as claimed in claim 126, wherein client accounts of said particular SWIFT-member back have RUTA-SW/RUTA-B/UTA for global reach via SWIFT.