RU2376635C2 - Method and system for carrying out transactions in network using network identifiers - Google Patents

Abstract

FIELD: physics; computer engineering.

SUBSTANCE: invention relates to architecture for transactions through the internet. There is control of price and route for making payments with through processing of payments. In the proposed method payments are addressed without need for knowing bank account details of the receiver, which makes easier making payments and their clearing. The process of making payments is turned into a process of rendering communication services. Use of attribute certificates with a network identifier of the payer and corresponding identifiers of main clearing organisations prevents disclosure of confidential information by opening actual bank information to an unlimited circle of individuals.

EFFECT: possibility of making transactions in which there is provision for conformity of a single telephone number of a subscriber to the position indicator of the subscriber, network identifier, as well as distribution of files of said numbers on a central communication switch and internet server.

6 cl, 24 dwg

Description

Field of Invention

The present invention generally relates to data processing. More specifically, the present invention relates to a system and method for facilitating the exchange of information and communication between various communication devices using a telephone number.

Description of related technologies

US patent No. 6151624 (hereinafter "patent b24") of the author K. Theage and others, which is included in the present invention in its entirety, which is also considered by the author as the closest prototype of the present application for the invention and describes a system and method that facilitate the search and access to network resources, such as a web page using their natural language names. In the case of a web page, the patent system and method 624 naturally link the language name (hereinafter “name”) with the so-called Uniform Resource Locator (“URL”) in the metadata file, which also contains additional descriptive information about the web page. After entering and confirming the natural language name in the data entry line of the web browser, the system and method turn to the index database containing metadata to find the corresponding URL associated with the specified natural language name. The system and method 624 of the patent then send the user a web page corresponding to the request indicated by the corresponding URL. This method frees the user from the need to know the full URL of the desired web page before the user gains access to the web page.

Nevertheless, there are some flaws and limitations associated with the system and method of the described patent 624. As indicated in patent 624, of course, language names are not unique and any specific name specified by the user can correspond to more than one web page, of which the user is forced to choose. Accordingly, 624 patent provides additional data and network processing to resolve this kind of conflict.

Moreover, names may be protected by trademark copyrights or by registering a domain name and therefore may be prohibited for use by the administrator of a website who wishes to name his website by that specific name, even if it is registered in the manner prescribed by law.

Moreover, patent 624 does not declare the possibility of communicating with other communication resources and methods, namely, email, voice mail and PDA devices (personal digital assistant).

Therefore, what was lacking and therefore not accessible is the system and method that allows the user to use unique descriptive information to identify and access and interact with websites or other network resources using information that is unique and known.

Public key encryption allows you to protect the exchange using key pairs. Each key pair includes public and private keys. The public key and the private key are connected in such a way that data encrypted with one key of a pair can only be decrypted with another key of one pair, and it is almost impossible to determine the private key with a public key. The private key is usually created and kept secret by the owner, while the public key is usually provided to everyone. Secure communication between the parties can then be established using key pairs belonging to the parties.

Using public key cryptography solves many problems in open networks such as the Internet. Nevertheless, two significant problems remain unresolved. First, parties must have effective access to the public keys of other parties. Second, since in many exchange protocols the parties are identified with their public keys, a reliable way must be found for such parties to verify that the corresponding public key belongs to the corresponding person.

The Public Key Management Infrastructure-PKI framework addresses these two issues. In one approach, PKI is based on digital certificates that associate public keys with relevant individuals with a degree of integrity. PKI usually includes a database of digital certificates with the ability to conduct operations on them in order to operate on such data and maintain the database. For example, the requirements for a new digital certificate, revocation of existing certificates are processed, the status of existing certificates is checked.

Nearest prototypes and their differences

US Patent No. 6151624, issued by RealNames, does not provide interconnectivity between communication networks and the Internet; checking on-line status; secure connection; support for 3rd generation communication standards such as MMS / I-mode / FOMA and unified communication and messaging services.

US patent No. 6324645, owned by VeriSign, proposes the use of digital certificates, but does not detail the use of certificates for communication network devices connected to the Internet; secure online shopping and transaction services based on ETA and dynamic URLs (Uniform Resource Locators).

US patent No. 5793762, entitled "System and method for providing packet data and voice services to mobile subscribers", and US patent No. 5457736, called "System and method for providing microcellular personal communications services (PCS) utilizing embedded switches". The main difference between these patents and the present invention is that in addition to making calls and communications, the wired network-mobile network, mobile network-wired network, mobile network-mobile network, the present invention also offers the possibility of connections such as browser-wired network, browser- a mobile network, a mobile browser network, and a wired browser network, thus providing connectivity (cross-connectivity) not only between all mobile via the Internet, but also between mobile, wired networks and users of the Internet and thus, the user anywhere on the network or the Internet can make a call without being a mobile subscriber.

US patent No. 5732359, called "Mobile terminal apparatus and method having network inter-operability", offers cross-connectivity between mobile and satellite networks, but does not protect cross-connectivity between any telephone network and the Internet.

US patent No. 6353621, entitled "Method to allow seamless service to mobile subscribers across various mobile switching centers supporting multiple intersystem standards", describes telephone connections and cross-connectivity for mobile networks at the installation level of many switches that support different communication protocols (TCP / IP for the Internet is included). However, this patent does not provide a connection for the purpose of exchange between the device and the program or program and the hardware.

US patent No. 5521962, entitled "Temporary storage of authentication information throughout a personal communication system", describes a method of managing information for authentication for users of mobile networks, reducing the number of copies of such information placed in the infrastructure of a particular wireless communication network.

Known inventions do not imply a central Internet Repository of a switch (switch) containing a database of Number Files providing cross-connectivity between mobile, wired and Internet networks.

The limitations and disadvantages of the known systems and methods described above can be removed and eliminated by various embodiments of the present invention, in particular, offering methods, systems, computer data streams, recordings on business model media, including but not limited to creating the Primary Number File or PPS ( primary number file (PNF) containing a single ETA telephone address having a telephone number belonging to a network resource.

One of the advantages of the invention is the method of creating the Secondary Number or VFN file (secondary number file), as well as the Main Number or GFN file (default number file), and the VFN and GFN are mirror copies of the VFN; GFN is hosted on a central switch (switch server), which provides connection services to network devices and is itself a network resource, while GFSF is hosted on the Internet provider's server.

Another specific proposed advantage is a method that includes the issuance of a temporary digital certificate containing ETA for use by at least one Temporary Subscriber - Temporary Target (TT), and VA can act as a temporary subscriber to the recipient or initiator of calls on the network, while The Administrator of Digital Certification - ACC (preferably a switch server) issues ETA and CA ETA (digital ETA certificate); places ETA and CA ETA immediately in the Subscriber Number File or transfers them to the sales representative (reseller); the reseller assigns the ETA / CA to a specific temporary Subscriber, placing them in the PFN of such a Subscriber.

Another application of the invention is encryption during an exchange session in which Subscribers use shorter key pairs to accelerate encryption of video and audio streams in real time, with each Subscriber issuing short public and private keys; places the private key in the internal protected memory of the Subscriber, and the private key is used only for one session; encrypts a new short public key using the original long private key or using the long public key of the second Subscriber (second side in exchange); transmits an encrypted message over the network to the second Subscriber; the second Subscriber decrypts the received message containing the new short public key of the first Subscriber, and uses the received public key of the first Subscriber to encrypt and / or decrypt the exchange with the first Subscriber.

The foregoing description is an abstract of only certain aspects of the most interesting applications of the invention. Detailed descriptions of various uses of the invention are described below, while the scope of the invention is defined in its claims.

The aforementioned needs and other needs and objects are implemented by the present invention, which, on the one hand, comprises a method of finding a network (hereinafter “localization") and establishing communication with network resources using a telephone number and a network location identifier, and includes location steps the first telephone number of the resource in conjunction with the identifier of the network location (hereinafter “network location indicator” or “index”) of this resource; receiving a request to establish a network resource location containing the first telephone number; retrieving a pointer associated with the first telephone number; and communicating with the resource using the resulting pointer.

One of the features of this perspective involves the placement of at least a second telephone number for the same resource in conjunction with a pointer; receiving a request for localization of a resource based on the first or second telephone numbers; retrieving a pointer associated with the first or second telephone number; and communicating with the resource using the resulting pointer. Another feature includes steps for placing the first and second telephone numbers in conjunction with a pointer to the number file in the storage device associated with the resource.

Another feature includes steps to extract a number file containing a phone number and associated resource; number file analysis; creating an index entry based on the values found in the number file; placing an index entry in an index that is separate from the storage device. And another feature includes steps to transfer the number file over the network to the client associated with the resource; placing the number file on the storage device on the server associated with the client. Another feature includes periodically polling a number file associated with a client; checking for the coincidence of one of the phone numbers located in the number file with the third phone number located in the index database; updating the index database when changes are detected in the number file. Another feature is the step of synchronizing the index with the database.

In accordance with another feature, the method includes steps to obtain a client identifier associated with a resource; generating a set of metadata describing the resource, pointer, and client identifier; hosting a metadata set in a persistent storage device associated with a client. Another feature is the assignment of a randomly generated name to a set of metadata. Another feature is instructing the client to place metadata at a specific specified location in the permanent storage device. Another feature is the registration of a set of metadata and a randomly generated name in the database.

The foregoing is merely a brief description of various features of the invention. The invention predetermines many other aspects set forth in the claims.

Brief Description of the Drawings

The present invention is only illustrated as examples and not as limitations of use, the accompanying drawings, in which the numbering refers to similar elements, among which:

1A is a diagram of a number file.

FIG. 1B is an embodiment of a system for navigating network resources based on metadata.

FIG. 2A is a flow diagram for a registration services method in the system of FIG. 1B.

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

FIG. 3 is a flow diagram for a polling “spider” method of operation in the system of FIG. 1B.

FIG. 4 is a block diagram of index building services in the system of FIG. 1B.

FIG. 5 is a flow diagram for a method of operating resolution services in the system of FIG. 1B.

6 is a flowchart for a service operation method.

number search in the system depicted in Figv.

Fig. 7A is an example of a statistical report page generated by the system of Fig. 1B.

Fig. 7B is another example of a statistical report page generated by the system of Fig. 1B.

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

9 is a simplified block diagram of a resolution and navigation system.

Detailed description of an embodiment of the invention

Here we describe the mechanism for linking a network resource with a phone number, as well as determining the location on the network and establishing communication with network resources using the associated phone numbers. In the present description, for purposes of explanation, some distinctive details are set forth in order to provide a thorough understanding of the invention. However, it will be apparent to a sophisticated person that the present invention can be used without such distinctive details. In other cases, well-known constructions and devices are shown in the form of diagrams or explained in another way, in a manner that avoids slurring with respect to the present invention.

Number File Format

In one implementation of the present invention, metadata is interconnected with a network resource, such as web pages, network computers, web capable devices, wireless or other communication devices. In general, metadata is data describing other data. The metadata defined by the present invention provides information that describes a web page or other communication network resource in a manner similar to that in which a library catalog card describes a book. For example, metadata includes information relating to the connection of a telephone number with a web page or other network resource, a description of this resource, a description of the language supported by the resource, the geographical location of the resource, and other information related to the resource. Referring to the given example of a web page, metadata is determined by the administrator of the server containing this page, which is described in the metadata, and a copy of the metadata is placed and linked to this server so that this metadata is accessible via the Web. Using the librarian program, this copy of the metadata is registered in the database, which, in turn, is associated with the index. In this spirit, a web site can be named by printing a known phone number (it is placed in the metadata with related information) in a web browser. The metadata information is then used to resolve phone numbers to web site addresses associated with that phone number in metadata.

As indicated, in addition to web pages, metadata can link other network resources to a phone number. For example, metadata can associate a phone number with an instant messaging tool of a user, a mobile phone number (when the phone number on which the metadata file is based is a landline phone number), or even an Internet video conferencing tool. In this vein, the telephone number and associated metadata can be used to detect a myriad of communication tools associated with the telephone number in addition to the web page.

While the further description of the various implementations of the present invention mainly relates to the resolution of web page resources using a telephone number, it is understood that a person skilled in the technology will be able to easily modify the concept proposed here to perform resolution of other network resources using a telephone number as described below.

Preferably, the metadata is prepared and originally posted in the form of File Number 64, which is a text file with an Extensible Markup Language (XML) grammar. XML is a language definition promoted by Microsoft® Corporation and Netscape® Communications Corporation. Further information on 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 file number 64 is compatible with the Resource Definition Format ("RDF") and Composite Capabilities / Preference Profiles based on RDF for managing device description information as well as other web-based XML description initiatives and mobile metadata. RDF is an XML syntax developed by the World Wide Web Consortium to express semantics. The text file for metadata described here is also called an MLS file. An example MLS file is presented further in FIG. 1A.

The MLS file 900 is defined according to the grammar in which the elements are surrounded by their accompanying tags. For example, "<resource>" and "</resource>" are complementary tags. The MLS file 900 has two main parts, namely the circuit section 902 and the data section 904. The circuit section 902 and the data section 904 are embedded in accompanying tags ("<xml>, </xml>") that indicate that the MLS file 900 uses XML grammar.

Schema section 902 is marked with <schema> and </schema> tags. A schema section defines a schema that is used to organize data in a data section. In the example of FIG. 1A, the “href” link in the circuit section refers to a file, “MLS-schema”, located on a web server that contains the circuit definition. The schema is named "MLS". Tags in the MLS file 900, which is part of MLSschema, are prefixed with "MLS". Using this prefix, an XML parser that reads the MLS file 900 can identify tags that are part of the MLS schema.

Data section 904 is marked with <xml: data> and </ xml: data> tags. The data section contains one or more MLS records 905. Each MLS record 905 is tagged with <assertions> and </assertions>. Conceptually, each MLS record 905 is a set of claims about a network resource that is specified inside the <assertions> tag. In the example of FIG. 1A, one MLS record 905 creates claims about the home.acme.com network resource, which, as an example, is the homepage fictitious by Acme Corporation. Of course, in accordance with the present invention, the <assertions> tag can create claims about a network resource other than a web page. For example, the <assertions> tag can define a user’s nickname for an instant messenger.

In further embodiments of the present invention, more than one type of resource may be associated with a telephone number, and various resources may be available based on the availability of one particular resource. For example, a user's landline phone number may be associated with a user’s nickname used for instant messaging, with a user's SMS identifier, and real-time video conferencing tools such as Microsoft NetMeeting. The number file defines a list of these various resources in a hierarchical order, for example, instant messages, then video conferencing, then SMS messages, and is preferably updated depending on the availability of each of the resources in real time in accordance with known methods. Thus, when an attempt is made to establish contact with the user using his landline phone number, the resource helps to establish such a contact, as determined by the established hierarchy and the availability of a specific resource in real time for the various cases described. Continuing to consider the given example, the connection will be established through the instant messenger, if the user is available in real time (on-line or online) through his instant messenger, otherwise an attempt will be made to establish communication via video conferencing. If the user is not available on-line via video conferencing, there will be an attempt to establish communication using SMS. Other means of communication may also be offered, for example voice or video messages may be placed for later delivery to the user.

The metadata file of the present invention provides a single addressing scheme based on the use of a telephone number. The metadata file in combination with a single addressing scheme makes it possible to establish communication between and among devices of various types operating in different networks. In another example, a metadata file can be used to facilitate addressing between an online video conferencing system and a mobile phone equipped with video conferencing tools, such as a 3rd generation mobile phone with video conferencing capabilities. In this context, the establishment of communication can be initiated by the user of video conferencing via the Internet by dialing in the address bar of the Internet browser a phone number that was resolved by the metadata file into the videophone resource.

RDF provides a general mechanism for describing many types of resources. RDF by its nature does not provide a means to describe web pages. Accordingly, File Number 64 is expressed in RDF terminology specific to web pages that describes the main attributes of a web page. Attributes include the phone number associated with the web page, and preferably also include a pointer or URL, description, language attribute, region attribute, and registry attribute. Of course, a professional will appreciate the fact that the concept allows the use of other relevant attributes for resources other than web pages.

Each MLS record 905 has a set of metadata 906. In the case of the example of FIG. 1A, metadata 906 contains a value that means a phone number associated with a resource. The phone number value "212-555-1234" is between the <telnumber> and <telnumber> tags. Metadata 906 also includes a description value, a language identifier value, and a region identifier value. A pair of tags highlights 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 a network resource that is associated with a real phone number, which in the example can be the main corporate telephone of Acme Corporation. In accordance with the present invention, a telephone number may include a city code or a country code and may contain alphanumeric or mixed prefixes or extensions, for example 1-800-USA-RAIL, or any other type of character commonly used with phone numbers.

When multiple resources are defined in one MLS file, it is preferable for security purposes that each network address advertised for a resource is associated with the shortest network address contained in the MLS file for each resource. In a preferred embodiment, each such network address should be a logical extension or logical root of the network address in the MLS file containing the least number of characters. For example, in the excerpt on FIG. 1A relating to web pages, all subsequent resource declarations would be necessary to identify network addresses that describe files located inside the directory tree for which the address www.medialingua.com is the root. This relationship was verified using the Registration Service 22 at the time the MLS file was first created.

Of course, as described above, any resource other than a web page can be described by the MLS file, for example, the email address or nickname of the user for the instant messaging service ("buddy" identifier from an instant messaging buddy list).

Another key advantage of the described mechanism is that it can be used to provide access to the network with resources using multiple phone numbers. One or more Number 64 Files are created. Number 64 files contain many descriptions. Each of the descriptions contains a telephone number associated with a specific one or more network resources associated with the <telnumber> field. However, each of the descriptions refers to the same network resource associated with the <resource> tag.

For example, one or more Number 64 Files have descriptions that contain the corresponding Acme Corporation phone number, such as the primary number for the legal, marketing, technical, and sales departments. Each description describes the same network resource. Accordingly, these descriptions create many telephone numbers that indicate or resolve to the same network address. When a third party wishes to access a network resource described in this way, such a third party may use any of these telephone numbers of this network resource that is known to such a third party. Resolver 40 will allow you to resolve such a phone number, that is, it will allow you to find the network resource address corresponding to the number, regardless of which phone number of this resource was entered. Accordingly, a user can find and access a network resource using any of a variety of known telephone numbers of the resource.

In an alternative embodiment, the attributes also contain a list attribute highlighted by the <MLS: listings> tag. A list attribute is one or more keywords or other values that describe other properties of a resource. For example, each resource has an item property that indicates the general nature of the product, service, or organization associated with the resource. This allows you to organize the database in a manner similar to that used by the Yellow Pages directory. For example, Acme Corporation has in its File number 64 the line <МLS: listing> containing Anvils (anvils), Rockets (rockets), Slingshots (slingshots), which indicates that the corporation is a manufacturer of anvils, rockets and slingshots.

In an alternative embodiment, the resources described in File Number 64 are subjects, not web pages. A subject-type resource has metadata, including a mailing address, email address, and other personal information. In this design, the system can be used as a service for searching for subjects, and not for navigating web pages or other network resources.

For example, a subject search service resource may contain links to resource web pages where the user can send an email message to the resource owner. Additionally or alternatively, such a resource may contain links that allow you to optionally send an SMS message, to a pager, or otherwise transfer the message to the owner of the resource. Moreover, ftp or other links or data associated with the owner of the resource can be placed on such a web page. Thus, the telephone number in the <telnumber> field of Number 64 File acts as a “Personal Internet Address” or PIA, being a single personal identifier that can be used by others to contact, send and / or receive information about a resource in many ways, namely calling, sending an e-mail message, downloading or “dumping” files using ftp, exchanging messages, participating in a chat, sending an appointment for a task or meeting, leaving a voice message or video message, or checking it on-line status of the PIA owner. The usefulness of a telephone number associated with a subject search service increases when the telephone number is both a stationary telephone and a mobile number, thereby allowing the implementation of one-call services offered by various fixed and mobile telephone operators that allow automatic translation a call to a predefined mobile number if the landline telephone does not answer.

If the resource has the means to send messages, the sender can be identified by extracting data from the settings of its computer and computer operating system. For example, when sending an e-mail message, the presented system may accompany it with information identifying the sender, extracted from the settings of the Window operating system, located in the Settings Start / Settings / Control Panel / Users / Properties. Thus, the resource to which the message is sent will receive the sender ID, which can be further used to respond to the sender's letter.

In accordance with various embodiments of the present invention, the resources described in File Number 64 are wireless devices, web-enabled devices, or other means of communication other than web pages or entities. For example, a device-like resource has metadata that identifies the device, for example, its screen size, memory size, communication type, mailing address associated with the device, its email address, a request for replenishment of resources, such as a request for replenishing paper in a network printer when the printer has detected that the paper is running out, and other information. In this design, the system can be used to provide device search services, determine their availability and status, rather than navigate web pages or other network resources.

In another alternative design, Number 64 File may contain other additional attributes. For example, other attributes include Organization, Subject, Abstract, Type, Audience. The Organization attribute in File number 64 may indicate an organization or company that owns or is associated with a network resource, such as Federated Stores Incorporated. The attribute File Subject Number 64 contains a description of the network resource belonging to the subject area, for example, "dogs" (dogs). The attribute Abstract of File number 64 contains a brief description of the network resource. The File Type attribute of number 64 contains information describing the type of network resource, for example, the file "RealAudio file". Information about the intended audience of a network resource, for example, "Women age 19-34" (women aged 19-34), is placed in the Audience attribute of File Number 64.

Defining metadata for a network resource, linking metadata to a network resource and placing a copy of metadata on a server that contains a network resource implemented in the proposed manner provides significant advantages. For example, metadata support is convenient. Since a copy of the metadata is located locally on the server that contains the network resource, the metadata can be updated at any time without having to contact the main service. As described below, the metadata crawler mechanism periodically visits such a server in order to monitor changes in metadata. If the File number 64 has changed, after confirmation, the changes are automatically applied to the database and index.

In addition, in combination, File Number 64 functions as a distributed metadata database. Support for a distributed database increases scalability, as modifying metadata is independent of the availability of a single central database. Further, the placement of metadata files in conjunction with the server of the device on which the network resource is located, improves data integrity. Only a user who has received authorization to place files on a server can create links between metadata and the corresponding link network resources of such a server.

Of course, someone skilled in technology will properly appreciate the fact that metadata can alternatively or in addition be placed in a central database. The central database may be periodically updated by various respective network servers that contain resources or resource information, or may be manually updated by the central administrator.

Another advantage is multilingual compatibility. XML supports UNICODE character tables. As a result, the attributes placed in File Number 64 can be expressed in any natural national language.

Telephone Number System

Using the metadata located in File No. 64 in combination with a network resource discovery system, network resource attributes can be used to discover and connect to a network resource. For example, as described above, the “phone number” attribute of File number 64 can be used to detect a web page. Figure 1B shows a block diagram of the execution of a network discovery system, consisting of a Register (Registry) 10, a Librarian (Librarian) 20, an Index (Index) 30 and a Resolver (40). An expert in technology will appreciate the fact that variations in execution The presented network resource discovery system allows implementing the system for resources other than web pages.

It is clear that, as shown above and below, the concept of “network address” generally means an unambiguous identifier of the location of a resource on the network, one example of a network address is a URL.

Registry 10 contains database 12 in the form of a commercial database system such as SQL Server or another database. Registry 10 provides a centralized repository for associating phone numbers with network addresses or URLs, as well as descriptive information related to phone numbers. By definition, each phone number is unique throughout the Internet or other communications network and therefore unique within Registry 10. Registry 10 functions as a centralized, highly productive, scalable, continuously running repository of all metadata. The Registry 10 also contains statistics related to the use of metadata in the context of various services that are built on top of the Registry, such as the GO navigation system described in this document.

Phone numbers, network addresses, and descriptive information are uploaded to Registry 10 using Librarian 20. In a preferred implementation, Librarian 20 and Index 30 communicate with database 12 using the ODBC interface. In a preferred embodiment, database 12 has a capacity of the order of several hundred million records. Registry 10 and database 12 help provide the appropriate structure and vocabulary for websites or other resources used.

Librarian 20 has a Registration Service 22 and a Crawler 24, each of which is connected to a database 12 and to a network, such as the Internet 50, or another communication network. Registration Service 22 receives new communications of telephone numbers with network addresses, as well as descriptive information and uploads (“registers”) them to Registry 10. Registration Service 22 receives communications from client 70 via the Internet 50. Crawler 24 navigates the Internet 50 (picks up the Internet) by periodically contacting registered resources that are connected to the Internet in order to detect changes in communications hosted or associated with such 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. 1B, but any number of web servers can be used in this design. The local database 62 is connected 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.

The number file 64 is placed in conjunction with the web server 60 in such a way that the web server can retrieve the number file and send its contents to the Internet 50 in response to requests. In a preferred embodiment, File Number 64 places descriptions of one or more phone numbers. Each description of the telephone number contains the telephone number of the resource of the web server 60, a description of the resource, a network address or other identifier for the location of the resource on the network, as well as other information about the resource, such as the language it uses and the intended geographic region of use. Preferably, File Number 64 also places a grammar identifier that is used to format other information in the Number File. Thus, the information in the Number File is self-sufficient in the sense of description and independent of the language.

As path 29 indicates, Crawler 24 can contact the web server at 60 and retrieve the values located in File number 64 using an Internet connection 50. As indicated in path 28, Crawler 24 can tell Index 30 that Index 34 Files should be updated to reflect changes in the information posted in Number File 64.

Index 30 is associated with Register 10. Index 30 contains the index builder Index Builder 32 and one or more index files Index Files 34, which contain the index of all telephone numbers, records of telephone numbers, as well as resources known to the system. For example, Index Files 34 index files have index entries for values located in File number 64. Index Files 34 is built, administered, and updated by the index builder 32.

In general, in a preferred embodiment, Index Files 34 are more compact than indexes supported by conventional search engines, since the amount of information presented in all Files of Number 64 is significantly less than the content of all network resources available on the Internet. Such compactness is an undeniable advantage, providing greater scaling and sensitivity than conventional search engines. In addition, the compact size of Index Files 34 allows Index 30 to be replicated to many different geographic locations.

Resolver 40 contains one or more resolver processes R1, R2, Rn, each of which is associated with Services, 42, 44, 46. Each resolver process R1, R2, Rn communicates with its respective Service 42, 44, 46 to receive requests containing a telephone number, convert or resolve a telephone number to a network address associated with a telephone number, and send an address and other information related to a telephone number requesting the Service.

Client 70 is connected to the Internet 50. The client is a computer, server, web-capable device, or wireless communications device or network that runs a web browser program 74 running an operating system 72. An example of a web browser 74 is Netscape Communicator. (3TM)., And an example of operating system 72 is Microsoft Windows 95. (3TM). The telephone number system services are available to client 70 via the Internet 50, using a browser 74 in accordance with standard telecommunication protocols or the Internet / Web.

For example, running browser 74 and operating system 72, client 70 can establish an HTTP connection with Registration Service 22 via the Internet 50. Browser 74 retrieves pages or forms from Registration Service 22 that are prepared in HTML markup language format. Browser 74 shows pages or forms. The user of the client 70 reads the pages or enters information into the forms and sends the completed forms back to the Registration Service 22. In this case, the client 70 and the Registration Service 22 perform a dialogue that the user of the client 70 can perform the functions offered to him by the system.

Preferably, Registry Service 22, Spider 24, Index Builder 32, and Resolver 40 are one or more computer programs having the functions and procedures described herein. In one design, each of Registration Services 22, Spider 24, Index Builder 32 and Resolver 40 is an independent process, and one or more instructions of each of these processes can be active and executed at any given time. In a preferred embodiment, computer programs are developed using an object-oriented programming language and programming tools such as the Java language.

Registration Service 22, Crawler 24, Index Builder 32 and Resolver 40 are preferably executed on one or more server computer components that can quickly access, manage and update database 12 and index files 34. Mentioned items may be distributed or separated. For example, it is envisaged that Resolver 40 and its processes Rl, R2, Rn are executed on one server computer, and the Registration Service 22, Spider 24, and Index Builder 32 operate on the same computer or on a cluster of computers separate from the server hosting Resolver 40 In this configuration, Resolver 40 can quickly receive and respond to customer requests for access to network resources that are located in the Index Files index 34 without interfering with or affecting the operation of other elements and their functions.

In one embodiment, the Librarian 20, as well as other system functions, can be accessed by client 70 by establishing a connection to one or more administrative Web pages 80 that provide functions using an HTTP connection. Administrative web pages (Web pages) 80 are hosted on a web server and generated by a program installed on that server, which can communicate with other elements of the system. This program sends the top-level page to the client 70. The client browser 74 displays this top-level page, which presents a menu of options for working with the system. For example, the preferred options menu is shown in Table 1.

TABLE 1 UPPER MENU OPTIONS FILE MLS Create Activate Modify Delete STATISTICS AND PAYMENT OF ACCOUNTS Statistics (Stats) Payment of bills (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 to the name of the required menu option using the input device and “clicking” it on the selected option. The functions that are executed when each of the menu options is selected are presented below in the context of the functioning of the module that performs these functions.

In the previous discussion, system elements were described with respect to the Internet 50 as a connecting element. However, the Internet is just one example of a connecting element that can be used to establish communication between system elements. Other elements, such as a local area network, a regional network, other wired or wireless networks, Intranets and Extranets, can also be used. At the same time, an Internet-related protocol such as the Transmission Control Protocol and Internet Protocol is also optional; other protocols can be used instead.

In this configuration, the system has advantages over other approaches. For example, customer’s 60 websites are isolated from database 12. Index files 34 are separated from database 12 and index files are available only to Resolver 40. This reduces database loading time and increases the ability to respond and also provides scalability. Such an architecture fits well with the concept of distributed replication of Index Files.

Customer Profile Features

In one implementation, the system provides the customer with a set of information management functions that allow you to place, track, update customer information in the system. The information managed for each customer is called the Customer Profile. Customer profiles are located in database 12.

When the CUSTOMER / New customer option is selected, the system generates one or more web pages containing forms that allow the user to enter a new user profile. The form has fields for recording the name, address, phone number, contact person and payment method, such web pages and forms are transmitted to the client 70 and displayed by the browser. The user of the client 70 enters the relevant information into the fields of the entries and “clicks” on the “ACCEPT” button located on the web page. In response, client 70 returns the completed form to the system via HTTP. The system extracts the entered information from the fields and places it in the database table 12.

In a preferred embodiment, the Customer / New Customer registration process is initiated using the web page generated by the system in the form shown in Table 2.

TABLE 2
HOME REGISTRATION Welcome to the website of the Telephone Number registration system. Before you submit your Telephone Number, you should provide us with some information about you and the organization that you can submit. To initiate the registration process, you must first enter your email address as your name (login name), and select a password. You will also need to remember this name and password, as the Telephone Number System uses them to provide you with access privileges. Name Password [BACK] [NEXT]

In Table 2, the designations [BACK] and [NEXT] mean function buttons. The user enters the user's mail address in the Name field, as well as the password chosen by the user in the Password field. When the user (presses) the NEXT function button, the Name and Password are placed in the database 12 in relation to each other.

Preferably, the system then displays a web page containing a form that allows the system to receive further information about the user. The form can have fields for entering a username, address, city, region, zip code, state, as well as a phone number, identifier or nickname from the list of instant messaging services, email address, mobile or wireline operator, equipment type and model number. The user enters the required information and presses the NEXT button. Alternatively, or in addition, certain information can be extracted from information already available on the user's computer, such as setting the preferred language or country, as well as the area code contained in the user's web browser or in the user's Windows® operating system. The system checks each value to ensure that the format of the value matches the requirements for each field. Values are placed in database 12 in association with the username and email address. Together, this information is the Customer Profile. When a customer profile is created, the user can create records of the type “telephone number” and place them in one or more Files number 64.

Selecting the CUSTOMER / Change profile menu option forces the system to generate a web page containing a form that allows the user to modify the profile previously created by the user. To protect operations, the user's IP address is extracted from the HTTP exchange, during which the user used the CUSTOMER / Change profile option. The user is allowed to view and modify only the profile that matches the previously created Number File, located on the server, which has the same IP address as the user. Based on the user's IP address, the system scans the corresponding profile in the database 12 and retrieves the contents of the profile. The content of the profile is shown on the web page.

The user can then move the cursor generated by client 70 to any other value shown on the web page and make changes to the values. When the user selects or clicks the “ACCEPT” button, the completed values contained on the web page are transmitted to the system via HTTP. The system updates database 12 using these values.

Selecting the CUSTOMER / Change Contacts menu option allows the user to change the payment contacts associated with the registered Number File. Selecting the CUSTOMER / Logout option allows the user to end the current session or log in under a different customer name. These functions are provided in the web-program, which receives and loads the corresponding values into the Register.

Registration Service

On figa shows a diagram of the preferred method of functioning of the Registration Service (Registration Service) 22 Librarian (Librarian) 20.

Preferably, the Registration Service 22 has a web interface due to which one or more clients 70 can use the functions offered by the Registration Service by selecting the function buttons located on the web page to activate the functions.

The main function of the Registration Service is to register 22 new phone numbers in the Register 10. In one of the versions, the Registration Service 22 is called up using the Create option on the top-level menu page. As shown in diagram 200, an external user or “customer” of the system identifies itself to the system so that information entered later can be associated with the customer. This information includes the customer’s e-mail address where messages of the Registration Service 22 via the Internet 50 can be sent to the customer. In this context, the terms “customer” and “user” refer to a computer operator remotely connected to the system, for example, to customer 70.

As indicated in diagram 202, the customer then provides information to the Registration Service 22, which identifies the network resource of the web server 60 by its location, telephone number, and descriptive information about the network resource. For example, the customer enters the phone number "212 555 3000" (he is the main number of the company with the name XYZ Corr), http://www.xyzcorp.com in the URL field, as well as a description of the resource. Preferably, such information is entered into the fields of the web page that is designed to obtain such information in the form shown in Table 3.

TABLE 3 TELEPHONE NUMBER RECORDING PAGE Phone Number: 212-555-3000 URL: http://www.xyzcorp.com. Type: company English language Region: North America Description: This is the home page of the fixture manufacturer, XYZ Corp. [BACK] [NEXT]

When the user has entered all the information in order to continue processing the File number 64, the user presses the NEXT function button located at the bottom of the page.

In response, at step 203, the system initiates a review service at which the price of the described permit services is provided. For example, a retention at a fixed price may be established based on the expected number of transitions per month to a specific resource. The expected number of permissions for any particular site may be based on the existing history of the previous activity of this site. For example, MSN provides services for documenting the number of clicks per month to various websites. Turning to this database, the system can determine how many clicks are expected to the website identified by the user, and the system will set the appropriate price for the user with payment in advance or upon execution.

At step 203A, the user is informed of the payment for the permission service provided, and he either rejects the payment and exits the program or accepts the payment conditions and proceeds to step 204.

At step 204, Registration Service 22 creates a Number 64 File based on information entered by the customer. Thus, Number 64 File is hosted on a server accessible for Registration Service 22. Nevertheless. File Number 64 has not yet been placed in conjunction with the web server 60.

In block 205, Registration Service 22 randomly generates a file name for File Number 64. A random file name is used to prevent unauthorized access by programs, processes or users to identify or modify File Number 64 when it is hosted in association with web server 60. If the same name was used on any web server registered with Register 10, an authorized user can change the entry made to Number 64 File, referring to another network resource. As a result, as will be shown later, Spider 24 would detect the change and place the phone number in the Register 10. Accordingly, it is desirable to hide the name of the File number 64 from unauthorized users.

At block 206, Number 64 File is sent to the customer as an email attachment. Object 206 comprises the step of receiving an email message from a user. In a preferred embodiment, the system displays a web page having an email address input field in the form shown in Table 4.

TABLE 4 EMAIL RECORD PAGE Please enter your email address at which we can send you the Phone Number File you just created. joe @ xyzcorp. corn [BACK] [NEXT]

After sending the Number 64 File to the user by e-mail, the system displays a confirmation page on client 70. In a preferred embodiment, the confirmation page has the form shown in Table 5.

TABLE 5 CONFIRMATION PAGE Your Phone Number File has been sent to joe@xyzcorp.com. Now you should save this file on your website in accordance with the instructions in the message you receive. After completing this step, the file must be activated through the activation services of the Phone Number File. (Just follow the previous link or contact User Support, refer to the Activation menu item, which belongs to the MLS file category.). [FINISH]

At step 208, the customer installs the Number 64 File on the web server 60 or in a manner accessible on the web server. Preferably, the Number 64 File is placed in such a place on the web server 60 as described by the Registration Service 22. For example, the email message describes that the Number 64 File should be installed in the root directory of the network resource, which is named in the Number 64 File. This is done, to make sure that the receiving customer is authentic; Registration Service 22 assumes that only an authentic representative of the customer can have access to the root directory of the web server on which the named network resource is located. The root directory is also indicated for customer convenience. When the Number 64 File is located in the root directory of the web server, the customer can change or reorganize the web server without affecting the Number File. Conversely, if the Number 64 file were placed in a subordinate directory of the web server, then there could be a risk of disconnecting the Number File if the directory in which the File was contained was accidentally deleted.

In block 210, the customer confirms to the Registration Service 22 that the Number 64 File has been placed by the customer at the described location. Confirmation of the Customer can be provided in the form of an email sent to the Registration Service 22, or by entering the appropriate command using the web interface of the Registration Service 22.

Then, the user is required to activate the Number File. Activation is the process of verifying that the number file is placed in the right place and by an authorized user. Optionally, the activation process may also include making payments for the privilege for the Number File to be registered and recognized by the system. One embodiment of the activation method is shown in FIG.

In a preferred embodiment, the user activates the Number File after it is created by selecting the MLS FILE / Activation menu option from the list of top-level menu options. In response, as shown in 212, the system creates a page asking the user to enter an activation type, 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 desired service: (*) Live update of a previously registered Number File. (*) Register a new Number File on your website. [BACK] [NEXT]

Preferably, the symbols shown in the “(*)” form in Table 6 above are shown on the display as “radio buttons”, or other graphic elements by which a user can be selected. When the user selects the first option ("Live update of the previously registered Number File"), as shown in 214-216, the system activates the Crawler, which finds the User Number File on the Internet, updates the database 12, as described below. Thus, the "Live update" function provides the user with the opportunity to make the system find the modified Number file and update with new information. Alternatively, as described below in connection with the Crawler, the user can simply wait and the Crawler will eventually find the modified file and update the database.

When the user selects the second option ("Register a new Number File on your website"), as shown in 220-222, in response, the system creates and sends the client 70 a web page from which the user can enter payment information related to the user and to its Number Files in accordance with the total amount and the actions taken in steps 203 and 203A. The steps to pay for the activation process are a completely optional part of the process, and other implementations do not involve any payment mechanism, including those related to steps 203 and 203A. In executions that use payment mechanisms, the web page contains fields for entering information related to payment. For example, record fields such as credit card, card number, expiration date of the card and the name of the card holder. The system receives the values of the payment information fields in block 224.

In block 226, the system prompts the user to enter the network address of the Number File to activate it, as well as a description of the Number File.

In block 228, the Registration Service 22 creates an HTTP connection with the web server 60, requests and downloads a copy of the Number 64 File. This step is performed to verify that the Number 64 File is valid and located in the right place. In block 230, Number 64 File is analyzed and values that identify the network resource are extracted from it. In block 232, the system creates a web page that reflects all the values identified during the analysis from the current File No. 64, and sends the page to client 70. On the web page, the system displays a message with the following contents:

“The number file that we downloaded from your site contains the following entries. Please check the validity of these entries. Click NEXT to continue.

[BACK] [NEXT] "

As shown in block 234, the user views the entries, checking their correctness, and presses the NEXT key. If any of the values is not correct, the user presses the BACK key, which activates the SORRY function described here.

In a preferred embodiment, the system then displays a web page containing a written legal agreement providing for the payment of a registration fee, as well as the resolution of disputes, including legal ones, as shown in blocks 236-238. The agreement is “signed” by clicking on the “ACCEPT” or “DENY” buttons. To accept the terms of the agreement and continue registration, the user clicks the ACCEPT button. To reject the terms of the agreement and terminate the registration process, the user clicks the DECLINE button. The use of a legal agreement is absolutely optional, and enforcement not using such an agreement is also considered here and is the subject of the present invention.

The system then places the values extracted during analysis from File No. 64 into the database 12 of Register 10, as shown in block 240.

For security purposes, the network address or URL of File Number 64 must match the root directory of the web server 60. This prevents the phone numbers from being redirected to unauthorized other network addresses. This also prevents the owners of the web server 60 from redirecting to this web server any other telephone numbers that the server owner does not possess.

In block 242, Registration Service 22 notifies Index Builder 32 that a new entry has been created in database 12. Route 26 in FIG. 1B represents such a notification. The notification includes information sufficient to identify a new record in database 12, for example, the row identifier ("rowid") of the table in which the new record is located. In response, Index Builder 32 performs a live update of the Index 34 Files, as explained below.

Thus, the Number 64 File created by the user is activated and becomes available for use by Resolver 40.

In a preferred embodiment, database 12 may receive requests from registered system members. As a result, the registered member can send queries to the database 12, which prompts the database to show the current registered information about network resources or web pages or other structures. Accordingly, if another registered user was able to register information that falsely contains the content of the network resource of such a user, a distortion can be detected and reported to the Register for corrective actions. Thus, the registration procedure, as well as the open ability to query the database 12, allows the system in question to avoid scam, which is possible through the unintended use of meta tags.

Modifying and Deleting Number File Information

After creating a Number File with 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 this file on the web page in the form shown in Table 7.

TABLE 7 FORM “MLS FILE / EDIT PAGE” The current list of MLS records contained in your MLS File is shown below. To edit an entry, select the corresponding word and click EDIT. To delete an entry, select the corresponding word and press DELETE. To add a new MLS record, click ADD. Click NEXT when you are finished editing the MLS File. [BACK] [EDIT] [DELETE] [ADD] [NEXT] Phone Number: 212-555-3000 URL: http://www.xyzcorp.com Type: Company English language Region: North America Description: Homepage of the fixture manufacturer, XYZ Corp. Selected: Phone Number: 212-555-1234 URL: http://www.acme.com Type: Company English language Region: Global Description: Acme Corp Homepage Selected:

The page consists of sections of text instructions, a set of functional editing buttons, and a list of entries that are now in the Number File. Text instructions explain functions performed by function buttons. In a preferred embodiment, the function buttons of such a page act on all entries in the Number File, and not on the fields individually. For example, to edit an entry, the user selects the appropriate phone number, such as "212-555-1235," and clicks the EDIT button. In response, the system displays a record edit page that contains the selected record. The user can enter the changed text in the record fields on the edit page.

Similarly, to delete an entry, the user selects the corresponding word and clicks the DELETE button. In response, the system creates a new Number File, which contains all previous records, except for the record selected for deletion.

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

To activate the changes made using the EDIT, DELETE and ADD operations, the user clicks the NEXT button. Clicking the NEXT button forces the system to create a new Number File, preferably in the XML format described above. The system sends by email the new Number File to the user in the corresponding explanatory message. For security purposes, the user is required to place the new Number File in the directory prescribed by the system as in the case of creating a new file.

Spider (Crawler)

Figure 3 shows the execution of the method, preferably used by Spider 24. In a preferred embodiment, the system includes a Scheduler process that initiates activation and operation of Spider 24. For example, the Scheduler places an event schedule. The event determines that Spider 24 should be executed every twenty-four hours. After the scheduled event, the Scheduler launches Spider 24.

At block 302, Spider 24 reads the database 12 from Register 10 and retrieves one or more rows or records that identify network resources indexed in Index Files 34. The method for selecting rows or records is not critical and therefore several different schemes can be used. For example, Spider 24 may select all rows or records that have not been updated since the last Spider was turned on. Or Spider 24 can select all rows or records that were created over a certain period of time or that are older than a certain number of days. Or Spider 24 selects a list of recently updated records. In a preferred embodiment, the system also establishes relationships between phone numbers and MLS File names and placements called the File Info table. The spider compares the selected lines with the File Information Table and sets the network address, placement or URL of the Number File associated with each phone number, line or record.

For each of the selected lines or records in block 304, Spider 24 polls the customer’s website, which is represented by a line or record, trying to detect updates in File No. 64, which is located in conjunction with the website. The survey includes steps to open an HTTP connection to a website, request and receive a copy of the Number File. Spider 24 parses the Number File using an XML parser to find the phone number record, as well as the values inside each phone number record that contain the phone number, network address, and descriptive information about the network resource. An XML parser exists and can be purchased from Microsoft® Corporation.

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

In this way, Spider 24 polls web sites on the Internet 50 to find the sites of customers who have undergone an update. Since Number Files are distributed across the network over a large number of customer sites, each customer has the ability to freely change his Number File at any time. The customer should not inform the telephone number system of this, since Spider 24 will eventually detect each change and update the database 12 accordingly. So, Librarian 20 automatically controls the changes to the Number Files distributed on the network, and periodically updates Register 10 in accordance with the changes. Advantageously, customers and end users are not involved in the process of updating the database 12.

Spider 24 updates the database automatically.

In a preferred embodiment, the customer can instruct Librarian 20 to immediately execute the Spider Program 24 in relation to a particular website. In this case, changes to a specific Number File are instantly detected and loaded into the database. The customer activates the instant execution of Spider 24 by selecting the Live Update option from the top-level menu. In a preferred embodiment, the system also performs, once a week, a complete update of the Index 34 Files based on the contents of the database 12. Thus, at least weekly, the Index 34 Files are rebuilt based on the current contents of the database 12.

In an alternative embodiment, Spider 24 also confirms the validity of each location of the network resources that are identified by each of the Number Files. For example, Spider 24 attempts to establish a connection with and download every resource that is identified in the number file entry. If an error occurs, an appropriate Email message is created and sent to the contact person of the organization that registered the Number File. Such a message informs the contact person that the location of the network resource is indicated in the Number File.

Index Builder

Index 30 contains Index Builder 32 and Index 34 Files. Index 32 Builder is a program or process that operates in two modes. In the first mode, the Reconstructive Process of the Index Builder 32 periodically polls the database 12, detects changes in the database and indexes the changed phone number entries in the Index Files 34. In the second mode, the Index Builder 32 updates the Index 34 Files in real time, following the queue of instructions for updating indexes. 4 is a block diagram of a preferred embodiment of Index Builder 32. Computers labeled GO Machines 100, 102, 104 each run an Index Builder 32 program. Each of GO Machines 100, 102, 104 is associated with network interface processes M1, M2, Mn Queue Agent 92a. Queue agent 92a is connected to a network 106, such as a local network, and receives requests for building index entries from Librarian 20. Queue agent 92a distributes a copy of each request to one of the network interfaces M1, M2, Mn, which, in turn, sends the request to the associated with it, GO machine 100, 102, or 104. Such an architecture responds well to external requests and is error resistant.

Inside every GO car. The builder of Index 32 is associated with a pair of queues 90a, 90b and a pair of indexes 34a, 34b. The GO 42 service may have access to any of the indices 34a, 34b, but at any one time it is associated with only one of them. 4 The resolver 40 is not shown in FIG. 4 for clarity, but it should be understood that the GO Service 42 accesses each index 34a, 34b through the Resolver 40 process.

For GO Service 42, it is important to maintain constant communication with one or another index. Accordingly, using the architecture shown in FIG. 4, the Index Builder constructs the indexes using the following process. The GO service is associated with the index 34b and has instructions to transmit telephone number resolution requests only to the index 34b. As soon as a request to build an index arrives from Queue Agent 92a in Index Builder 32, Index Builder 32 adds queries to both queues 90a and 90b. When one of the queues becomes sufficiently complete, for example, queue 90a, Index Builder 32 sequentially deletes entries from that queue in a first-in-first-out (FIFO) order, and updates index 34a with a record of each queue. At the same time, if any new requirements for the construction of the index are received, they are sent to both queues. When the queue 90a is empty and the index 34a is completely updated, the Builder of the Index 32 instructs the GO 42 Service to transmit the request for permission of the phone number only to the index 34a. The index builder 32 then removes entries only from queue 90b and updates only index 34b from this queue. Thus, Index Builder 32 can add index entries to one of the queues 90a, 90b, but always updates only one index per unit of time, using the contents of only one of the queues per unit of time. The queue with which the Builder of Index 32 communicates is always opposite or complementary to the indices 34a, 34b with which the GO 42 Service is currently associated. Thus, the GO 42 Service constantly communicates with the index, and the Index Builder 32 can update the index in real time without interrupting the process of resolving telephone numbers.

Preferably, the build requests contain an identifier called “Fileld” of the file or timeline that is linked to the File Info table or File Info table described above. The Index 32 builder searches for FileID in the TIF and retrieves all database entries whose data matches the FileID. Each database record contains a unique identifier, which is described in the database record. These unique identifiers are generated using the database server sequence generator. Using a unique database record identifier that matches the FileID, Index Builder retrieves the matching index record. Index record information is compared with the information contained in the build request. If the information in the build request is different, the index record is updated. If the information in the build request indicates that the associated network resource is no longer active or unavailable on the network, the index record is deleted.

To ensure scalability, reliability and quick response, each of the GO machines 100, 102, 104 has a similar configuration and functions in parallel with the others. Although only three GO machines 100,102, 104 are shown in FIG. 4 for illustration, the system can use any number of machines. In a preferred embodiment, the Scheduler determines when to begin execution of the Index Builder 32.

Resolver

In general, Resolver 40 functions as an interface to requests for metadata located in the Register 10. Resolver 40 functions by receiving phone numbers as requests from services 42, 44, 46, requests index 30 to determine the network addresses corresponding to the given phone addresses, and responds to services By passing found network addresses. Resolver 40 is built to quickly respond to search operations and serve millions of queries per day. To minimize response time and provide scalability, responding to requests, Resolver 40 does not have direct access to the database 12 of Register 10. Instead, the Resolver communicates with Index 34, which is located in the fast main memory.

In a preferred embodiment, Resolver 40 operates on any number of a plurality of processes R1, R2, Rn, each of which is associated with a service 42, 44, 46 that creates requests to the Resolver. Services 42, 44, 46 communicate with the processes R1, R2, Rn of the Resolver using an HTTP connection. It is also preferred that computers running the Resolver 40 program have a triple redundancy configuration. This configuration provides a quick response to requests from services 42, 44, 46 and provides reliability. Each of the processes R1, R2, Rn is executed in the form of a web application that Resolver executes. Services 42, 44, 46 communicate with the processes R1, R2, Rn of the Resolver using an HTTP connection.

In one embodiment, the process of Resolver 40 is made in the form of a dynamic library of links (dynamically linked library or DLL), which is integrated into services 42, 44, 46. In a preferred embodiment, each of the processes of Resolver 40 is a separate process or program that operates in accordance with by the method shown in FIG. 5. Resolver 40 is implemented with one or more APIs (application programming interface), which allows you to develop 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 client 70, accesses Resolver 40. In one embodiment, client 70 establishes a connection to Resolver 40 using an HTTP connection. In block 502, client 70 creates an HTTP connection with Resolver 40. In block 504, client 70 provides Resolver with a URL, requesting that it return a network address corresponding to a specific telephone number. For example, is the URL in the form http://www.resolver.com/resolve? tn = TELRPHONE NUMBER. In this form of URL, the string “http: //” defines the URL as an HTTP request, “www.resolver.com” is the server domain, and “resolve” is the name of the program executed on the server of the specified domain, which is actually the Resolver. The expression "tn = TELEPHONE NUMBER" passes the value "TELEPHONE NUMBER" to the parameter "mm", which is recognized by the Resolver. In cases where the telephone number is placed together with the city and country codes, the client’s browser is preferably programmed to add the country and city codes to the telephone number that the user enters without one or both of the codes. Such information can be obtained as secondary from the settings of the user's Window operating system.

In another design, client 70 establishes a connection with one of the services 42, 44, 46 associated with the processes of Resolver 40. Services 42, 44, 46 exchange with client 70, requesting and receiving a phone number.

So, in one of the cases, Resolver 40 receives the phone number requested by client 70. In response, Resolver 40 builds a Qualifier object in the main memory that contains the phone number. In block 506, the Resolver establishes a connection with the Index 30 and makes a request to provide it with a network address or URL that corresponds to the phone number in the client’s request 70. In a preferred embodiment, the request is made by sending a message containing the Object- to the Index Store object specifier. The index placement object summarizes or provides a brief explanation of the Index 30. The index placement object performs a query on the index.

At block 508, Resolver 40 receives a response from Index 30 containing a network address or URL that matches the phone number in client request 70. In a preferred embodiment, the Index Placement Object returns an Entry Set object to Resolver 40. The record set object contains or mentions a set of one or more entries from Index 30 that correspond to the requested phone number. Preferably, the Record Set Object is configured to provide a location or URL of a network resource described in the record of the object.

Using the Object Record Set allows the system to function when only part of the telephone number is entered. This is particularly useful when the user of the presented system knows only part of the telephone number by which information is searched. As an example, a user who knows only the last four digits of a telephone number may enter “3421”. The record set object will contain all records of telephone numbers ending in "3421", that is, for example, numbers "212-324-3421", "213-247-3421" and "702-397-3421", and the user can then select the number or the corresponding resource, which from his point of view is the desired resource.

The index placement object also contains logic for organizing records into an Object record set based on the overuse function. If the Record Set Object has only one record, no ordering is required. If the Record Set Object has more than one record, then the records can use any preferred ordering method.

At block 510, Resolver 40 generates an outgoing message based on the response of the index. In a preferred embodiment, Resolver 40 creates an XML file containing information from the response of Index 30. In a preferred embodiment, each of the services 42, 44, 46 is equipped with an XML parser that can convert the XML file created by Resolver 40 into text or other information in the format used by the client 70. In a preferred embodiment, each record mentioned in the Entity record set also contains a value that means the number of times that the record was allowed (searched or used). The number of uses can be used to rank entries during display, or used in another way by one of the services 42-46.

Preferably, after resolving each telephone number, the Resolver 40 will record in a log file 84, which includes the telephone number, the total number of permissions in the past, including the current resolution, IP address and domain name of the client or server that requested the current resolution, and time at which this resolution occurred.

In a preferred embodiment, Index 30 and Resolver 40 are physically executed on the same computer, and Index Files 34 are located in the main memory of this computer. This configuration improves the response time of Resolver 40 by providing quick access to Index 30. It is understood that Resolver 40 answers several tens of millions of phone number resolution requests per day. In a preferred embodiment, Index 30 and Resolver 40 are also implemented as a plurality of software Component Object Models or COMs that communicate with the AltaVista executable library using the AltaVista API. AltaVista Executable Library licenses are sold by Digital Equipment Corporation in the form of the AltaVista SDK (Software Development Kit or SDK).

In an alternative design, Resolver 40 is able to distinguish between addresses related to the Internet, a local area network or an "intranet", as well as external business networks "extranets" accessible from the outside. In an intranet execution, Resolver 40 contacts the Register 10, which is located inside the organization that owns and controls the work of the Resolver. Register 10 contains information that describes intranet resources. In particular, this applies to organizations that have a PBX-based telephone system using internal four- or five-digit extensions of internal telephones. Resolver 40 converts the telephone number or extension entered by the user into the location addresses of the intranet of resources, and navigates users to these resources.

Services

Services 42, 44, 46 can be performed in several ways. In one embodiment, the GO service 42 is a computer program installed or attached to the browser 74 of the client 70. For example, the GO service 42 is installed on the client 70 as a plug-in to the browser 74. A user downloads the GO service 42 from a central distribution site and places service on the client 70. The user installs a program that installs the service on the browser 74. After installing GO, the service 42 intercepts the phone numbers entered by the user in the browser 74 and resolves the phone addresses to the network addresses used by the browser rum 74.

Figure 6 shows a block diagram of a method for the operation of a GO service 42 in this configuration. At block 600, the user invokes the execution of the browser 74.

Browser 74 has a URL entry field in which the user optionally prints the network address of the document for retrieval and display in a browser. At block 602, the user enters a telephone number in the network address input field. At a GO block 604, the service 42 captures the keystrokes made by the user when typing in the input field of the network address of the browser 74, and thus receives the telephone number entered by the user.

Next, control is transferred to block 609. At block 609, service 42 requests Resolver 40 to resolve the phone number received from the browser to the network address. For example, service 42 creates a URL that refers to a predefined location in the system where Resolver 40 is located. This URL contains, as a parameter, passed to Resolver 40 a phone number received from the browser. Service 42 opens an HTTP connection from client 70 to Resolver 40 using this URL containing a phone number. Resolver 40 extracts the phone number value from the URL and performs resolution as described above. Resolver 40 then returns the value of the network resource address with an HTTP message to the browser 74.

If the corresponding value of the network resource address is received from Resolver 40, in block 610, GO service 42 redirects the browser 74 to the network address found by Resolver 40. For example, service 42 extracts the value of the network resource address from the HTTP message received from Resolver 40 and transmits it browser features 74 that can load and display web pages. Browser 74 then loads and displays a file or page located at the network address in the usual manner. Alternatively, if more than one value of the location of the network resource is received from Resolver 40 in response to the receipt by Resolver 40 of only part of the telephone number, then in block 610 the service displays a list of location values (addresses) of network resources. The results are displayed in order from more important to less important permissions, based on the values of the permissions processed and contained in the Statistics Service 82. In another embodiment, the service returns to the client 70 an HTTP response containing XML containing the query results.

In an alternative GO design, service 42 is executed as a web application executable on a dedicated web server. To search for a network resource, client 70 establishes a connection with the GO web server using a predefined address or URL. In response, the GO 42 web application displays a web page containing a form with a data entry field. The user types the telephone number of the network resource in the data entry field. GO server 42 discovers a network resource, as described above.

In another alternative implementation of GO, service 42 is associated with a button or panel embedded in the web page of an external web server. A button or panel is a fixed network address or URL that invokes GO service 42 when the button or panel is selected by a user viewing an external web server. This configuration provides the ability to enter phone numbers that do not require a browser.

In another alternative implementation of GO, service 42 includes a detection and response mechanism in the language used by client 70, which communicates and makes a request to GO, determining the country code in this way. Assume that the computer running the GO 42 Service operates using the UTF-8 character set and English, while client 70 uses Japanese and encoding with a different character set. When the GO Service 42 sends to the client 70 a web page containing a telephone number entry form, the web page includes a hidden field with a predefined text string placed there. Client 70 receives the web page, and its browser or operating system turns the web page into the character set that it uses. The customer user 70 enters the telephone number into the web page and sends it to the GO 42 service. The GO 42 service receives the web page, extracts the value of the hidden field and compares this hidden value with the table or compares the values of the hidden field with different sets of character encodings and languages. The GO 42 service defines the appropriate character set and language. Using the language (country code), the GO service 42 selects a resource having the same language value in the resource metadata section 906. Thus, the system determines the language of the client who sent the request and provides it with a resource corresponding to this language.

In another alternative design, GO 42 and Resolver 40 use File 64 metadata values associated with resources to respond to extended requests. For example, suppose United Airlines is registering File Number 64, which describes resources in several different languages, such as English, French, and Japanese. The user finds a website owned by United Airlines that is located in France or is prepared in French. The user enters into GO Service 42 the telephone number of the United Airlines booking department in the USA with the addition of the word "France" like this: "1-800-241-6522 France". Resolver 40 compares the record with the metadata fields of the Description, Region, and Language section 906 associated with United Airlines Number 64 File.

Resolver 40 and Go service 42 redirect the user's browser to the United Airlines website in French.

In an alternative design, when GO service 42 is executed as a plug-in for a browser installed on client 70, GO, the service provides information on character encoding to Resolver 40. To obtain the character encoding currently used by client 70, GO, service 42 calls the function of the operating system , which runs on client 70. GO service 42 adds information about the character encoding used by the client to the URL in order to transfer the user’s request to Resolver 40. In this case, Resolver receives information specifying the language and coding in characters, currently used by the client 70, and can return the address of the network resource corresponding to a given language.

In an alternative embodiment, the computer system further comprises a microphone connected to an analog-to-digital converter (ADC). This ADC is connected via an appropriate interface to the computer system bus. Under the control of a system driver program or other appropriate program, the ADC receives an analog sound signal from a microphone and converts it into a digital signal. A driver or other program receives a digital signal and converts it into a phoneme, word string, keyword or command for GO service 42. The converted signal is used by GO service 42 as an input signal, replacing it with keyboard or mouse input. Thus, the user can view the user interface 1000 and say the words into the microphone, giving GO commands to the service 42 to search for specific network resources. Thus, the user uses the navigation on the web, using the words (numbers) of the spoken language.

Another alternative embodiment is shown in FIG. 9. The service is in the form of a web server or an intermediate Web application server 60a. The application web server 60a communicates with the client 70 via HTTP messages over the Internet 50. The application web server 60a includes a script processor with a Common Gateway Interface (CGI), an application server such as a Netscape Kiva server, Microsoft Active Server, or Apple WebObjects (ZTM). The software application running on the application web server 60a communicates with Resolver 40 via the Internet 50 via paths 40a, 40b using CGI scripts to generate HTTP requests and responses. The application web server 60a uses function calls provided by the API of Resolver 40 to communicate via paths 40a, 40b. Using such a scheme, the application web server 60a issues a request containing requests to Resolver 40. In response, Resolver 40 evaluates the requests, queries the Index 30, and creates a metadata set for all index entries that reflects the web pages that satisfy the request. The metadata set is packaged in an XML file and delivered by Resolver 40 to the application web server 60a. The application web server 60a has an XML parser (parser) that can parse the XML code from the XML file. Using the parsed XML code, the application web server 60a creates one or more HTML documents and delivers them to the client 70. The client 70 displays the HTML documents to the end user.

Statistics Service

As described above with respect to Resolver 40, each time the Resolver resolves a telephone number, it records this in a log file. The system has a Statistics Service 82, which is responsible for reading the journal and loading information from the journal into Index Files 34.

In a preferred embodiment, Statistics 82 operates periodically based on a schedule. Statistics 82 reads each log entry and creates an index object based on the information contained in the log. Then the Statistics Service 82 sends a message to the Index Builder 32, which asks the Index Builder to constantly place the values in the Index Files 34. In response, the Index Builder 32 places the values in the Index File 34.

The top-level menu page of the system has hyperlinks that allow the user to access statistics and bill payment functions.

When the STATISTICS AND PAYMENT OF ACCOUNTS / 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 of top-level options 702. The set of function buttons 704 allows the user to create other global functions, such as address resolution, entering information about a new customer, receiving user support services and extended information on the telephone number system.

The function buttons for reports 706 allow the user to access the reporting functions of the system. In this design, the buttons for generating reports 706 include the buttons Select Records 712, Select time 714, Report for Record 716, Report on affiliation 718.

The Select Records 712 button is used to determine the list of records within the Number File for which reports should be generated. When the user uses the Select Records 712 button, the system reads the Number File from a server that has an IP address that matches the IP address of the current user domain. The system analyzes the Number File and displays a list of all phone numbers on a new web page that is sent to client 70. This page displays the selection tools - the so-called radio buttons, adjacent to each of the phone numbers in the list. The selection is made by clicking on the radio button, after which the web page is sent to the system, the system provides statistical information for all selected phone numbers in all reports that will be generated later.

The Select Time button 714 is used to set the time period for which statistical reports are to be generated. When the user uses the Select Time button 714, the system generates a new web page and sends it to the client 70. This web page includes a form in which the user enters the start date and end date of the report. When the user sends the completed page to the system, the system receives and places the received date values. Later, when a report is generated, they will contain statistical information for the phone number permissions that occurred between the indicated dates.

The Report button for Record 716 is used to generate a report and graphs that reflect the resolutions of all phone numbers that occurred to record each phone number described in the current Number File. When the Report button for Record 716 is used, the system reads the statistical information that is located in the statistical tables of database 12 for each of the phone numbers that are defined in the current Number File. The system generates graphs and charts of statistical reports and generates a web page containing these graphs and charts.

7A is an example of a web page generated in this way. Chart 708 contains an illustrative histogram. Each bar graph represents a telephone number defined in the current Number File. The vertical axis 720 shows the number of permissions (in thousands) for each phone number. The horizontal axis 722 shows each Number for which statistics are provided in the report. Statistical square 710 contains a description column 730 taken from the Description field from the Number File, a permission number column 732, and a percent column 734. A description column 730 lists each telephone number and its Description, which is defined in the current Number file. The permission number column 732 gives the number of phone number permissions that occurred during the current specified time period. The percent column 734 of each telephone number shows the percentage of all permissions attributable to the permissions of that telephone number.

FIG. 7B shows an example of another type of graph generated by the statistics service. The vertical axis 720 is the number of resolutions of each telephone number. The horizontal axis 722 comprises a plurality of posts 738, each of which is associated with a telephone number. The column represents the number of permissions for such a phone number. The second vertical axis 736 shows the percentage of all permissions issued by the system with respect to the telephone numbers shown on the horizontal axis 722.

In this design, the owner of the telephone number system receives payment from end users who have registered telephone numbers in the Register 10. Librarian 20 creates a payment request for each user’s account when a new entry is made through the Registration Service 22. In another design end users and customers from among those who register phone numbers in the Register 10 pay a fee to the owner of the phone number system for each permission made by Resolver 40 in ie the requirement of third parties. Resolver 40 creates a payment request to each user’s account after each permit. In this version, information about the deduction of remuneration from customer accounts is documented and collected in the tables of the database 12. Periodically, the external accounting program reads the tables of accounts and payments from the database 12 and generates invoices that are sent to users. The menu option STATISTICS AND PAYMENT OF ACCOUNTS / Statistics from the list of menu 702 allows users to observe and examine in real time the account balances and the current payment of users of registered phone number entries, as well as take into account the amount of payment for permit services. When the function Pay bills is selected, the system reads the tables of bills and payments from database 12 and generates a report on the web page summarizing the payment of the system services by the customer. This web page is sent to client 70 and shown to him.

Hardware Overview

FIG. 8 is a block diagram illustrating a computer system 800 on the basis of which the invention can be implemented. The system of FIG. 8 is designed to implement the above applications for web page permissions using phone numbers. An expert in the art will appreciate the fact that the system of FIG. 8 can be modified to use known methods and components for executing resource resolutions other than those described above, for example, mobile phones, PDAs, and so on.

Computer system 800 is comprised of an 802 bus or other information transfer mechanism, and a processor 804 is coupled to an 802 bus for processing information. The computer system 800 also comprises a main memory 806, such as random access memory (RAM) or other storage device connected to the 802 bus to store information and instructions for execution on the processor 804. The main memory 806 can also be used to host temporary variables or other intermediate information during the execution of instructions intended for execution by the processor 804. The computer system 800 further comprises read only memory or ROM 808 or other devices permanent storage associated with the 802 bus for hosting static information and instructions for the processor 804. A storage device 810, such as a magnetic disk or optical disk, is also present and connected to the 802 bus for hosting information and instructions.

Computer system 800 may be coupled via a bus 802 to a display 812, such as a cathode ray tube (CRT), to display information to a computer user. An input device 814, including alphanumeric and other keys, is connected to a bus 802 for exchanging information and commands with a processor 804. Another type of input device is controlling the cursor 816, such as a mouse, trackball, or cursor keys for transmitting guide information and selecting commands processor 804, and also for controlling the movement of the cursor on the display 812. Such an input device usually has two degrees of freedom along two axes, the first axis (x) and the second axis (y), which allow the device to be positioned on a plane.

The invention relates to the use of a computer system 800 to provide an implementation of a system for detecting network resources by their telephone numbers. In accordance with one embodiment of the invention, network resource discovery is provided by computer system 800 in response to execution by processor 804 of one or more sequences of instructions contained in main memory 806. Such instructions can be read into main memory 806 from another computer information medium (computer- readable medium), such as storage device 810. Executing a sequence of instructions contained in main memory 806 causes the processor 804 to perform the process steps described herein. In alternative implementations, a different wiring diagram may be used instead of or in combination with program instructions to implement the invention. Thus, applications of the invention are not limited to any particular combination of hardware and software circuits.

The term “computer-readable medium” is used to mean any medium that is involved in providing instructions to the processor 804. Such a medium, including but not limited to, can be a non-volatile medium, a volatile medium, a transmission medium. Non-volatile media includes, for example, optical and magnetic disks, such as a storage device 810. Volatile media includes dynamic memory, such as a main memory 806. Transmission media includes coaxial cables, copper wires and fiber optics, including the wires that make up the 802 bus. Transmission media can also take the form of acoustic or light / radio waves, such as those created during data exchange in the radio or infrared wavelength ranges of data transmission.

The general form of a computer information medium includes, for example, a floppy disk, floppy disk, hard disk, magnetic tape or any other magnetic medium, a compact disk or any other optical medium, punched cards, punched tapes, any other physical media with holes, RAM, EPROM and EPROM, flash memory, any other memory on a chip or cassette carrying a wave, as described below, or any other medium that can be read by a computer.

Various forms of computer storage media may be used to carry one or more sequences of one or more instructions to processor 804 for execution. For example, instructions may initially be written to the magnetic disk of a remote computer. The remote computer can load instructions into dynamic memory and send instructions via a telephone line using a modem. A modem located adjacent to the computer system 800 can receive data over a telephone line and use an infrared transmitter to convert the data into an infrared signal. An infrared receiver connected to bus 802 can receive data brought by the infrared signal and transmit data to bus 802. Bus 802 transfers data to main memory 806, from which processor 804 extracts and executes instructions. Instructions received by main memory 806 may optionally be located on storage device 810 before or after execution by processor 804.

The computer system 800 also includes a communication interface 818 connected to the bus 802. The communication interface 818 provides two-way communication connected to a network connection 820 that is connected to a local network 822. For example, the communication interface 818 may be a card or a digital network modem with integrated services ( integrated services digital network or ISDN) to provide a data connection to a telephone line of the appropriate type. Another example of a communication interface 818 may be a local area network (LAN) network card providing a connection for exchanging data with a compatible local area network. Wireless communications can also be used. In each such design, the communication interface 818 sends and receives electrical, electromagnetic, or optical signals carrying digital data streams representing various types of information.

Network communication 820 typically provides data transmission through one or more networks or other data devices. For example, network communication 820 may provide communication through a local area network 822 with host computer 824 or equipment. The Internet Service Provider (ISP) 826. The ISP 826 in response provides data services through the global packet data network, often now called the Internet 828. The local network 822 and the Internet 828 both use electrical, electromagnetic or optical signals carrying streams data. Signals in various networks, signals in a network communication 820, and signals in a communication interface 818, carrying digital data from and from a computer system 800, are illustrative forms of information transfer carrier waves.

Computer network 800 can send and receive data, including program code, through a network (s), network connection 820, and communication interface 818. In the Internet example, server 830 can transmit the requested code for a software application via the Internet 828, ISP 826, local area network 822 and communication interface 818. According to the invention, one of such downloaded software applications provides a naming system for language dependent networks, as described herein.

The resulting code can be executed on the processor 804 after receipt, and / or stored for later execution on the storage device 810 or other storage device with indestructible memory when the power is turned off. In the manner described, computer system 800 may receive program code in the form of a carrier wave.

Options; advantages

In the following specification, the invention has been described with respect to specific implementations. However, it is obvious that various modifications and changes can be made to it without deviating from the main idea of the invention in all its breadth and depth. For the invention, therefore, the specification and drawings are illustrative rather than limiting.

Description of Applications

Definitions

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

URL A URL (Uniform Resource Locator) is a unique identifier, such as an IP address. Keyword, phone number or DNS name, as well as any other that uniquely identifies network resources.

IP address IP (Internet Protocol) address is a digital URL and represents the addressing layer under the DNS addressing system; IP addresses are unique by definition; IP addresses can have DNS names assigned to them. The DNS name or Keyword cannot be used if it does not have an IP address.

ETA - Unified Telephone Address. ETA is a telephone number assigned to a network Subscriber, User or Resource (together Subscribers). Each Subscriber has only one assigned ETA and therefore each ETA uniquely identifies a specific Subscriber. Each ETA has at least one Number File assigned to and associated with this ETA. The ETA addressing system is a unique addressing layer (URL) on top of telephone numbers, IP addresses and DNS name systems. ETA is compatible with the RealNames Keyword name system (reference: RealNames ceased to exist in the summer of 2002). ETA can be assigned to any network Subscriber, including Internet resources, as well as telephones with a wired or wireless (mobile, satellite and other) line.

ETA Subscriber. A subscriber has the ability to work on the World Wide Web or web and is a network object of any nature, a device (such as a computer device, storage medium, chip or processor), a program (such as a web browser, instant messenger, electronic messaging program, etc. ), data (such as a website or page, etc.), the frequency of a wave, its modulation or division, or their composition (for example, a specific radio station). The subscriber is able to require the network to assign him a URL. There is only one unique ETA assigned to the Subscriber.

The IP address that determines the exact location of the Subscriber on the Internet is called the Primary IP address and the PFN belongs to the Subscriber and is available at a network location that is uniquely determined by the Primary IP address. All Subscribers have tools for working with the web, such as a web server, web browser, as well as other hardware and software tools that allow the Subscriber to manage PFN data, to connect, communicate and exchange via the Internet. For each Primary Number File, preferably two mirrored copies of the PFN, called the Main and Secondary File of the Number should be created; these copies of the PFN are placed and available in real time on the switch server and the Internet service provider (ISP) server, respectively.

Dynamic and static IP addresses (URLs) and “traveling” mobile identifiers (IDs). Each Subscriber can be accessed on the network using his URL. On the Internet, Subscribers usually have static IP addresses assigned to them using a dedicated Internet line (like DSL, T1, others); the so-called dial-up (dial-up Internet access) or mobile (traveling) subscribers usually have a temporary dynamic IP address assigned to them using DHCP (Dynamic Host Configuration Protocol) and valid for the time when the subscriber is connected to a specific ISP or hundredth mobile network. During the trip, the numbers of mobile devices are remembered and the devices themselves are served using such standards of mobile roaming (travel) as ANSI-41 and GSM-MAP.

ANSI-41

ANSI-41 provides support for travelers who visit your service area, as well as your customers, when they travel outside your service area. When a traveler checks into your service area by

Using the MIN / ESN of the traveler, your mobile switching center (MSC) and the visiting location register (VLR) determine the corresponding MSC of the traveler’s home zone register (HLR) for routing.

Your MSC sends a message through the SS7 network and, if required, through an access gateway to other SS7 networks for transmission to the home zone MSC / HLR for verification.

The caller's MSC / HLR checks the traveler and sends a response allowing the caller to request the connection.

When your customer travels outside your service area, the process repeats, but messages are routed over the network to your MSC / HLR.

GSM-Map

Like ANSI-41, GSM-MAP allows you to transfer important data about MSC / HLR / VLR registrations and discreet movement between you and your roaming partner’s network, and this message protocol provides instant access to advanced SS7 features, such as the ability to preservation of number (Number Portability).

One feature where the GSM-MAP transport differs from the ANSI-41 is the administration of the traveler. GSM-MAP networks use the International Mobile Station Identifier (IMSI), while ANSI-41 uses the Mobile ID Number (MIN).

IMSI is a 15-digit identifier based on the Mobile Country Code (MCC) representing the traveler’s country of origin, the Mobile Network Code (MNC) identifying the user's home network (origin network), and finally , Mobile Station Identification Number (MSIN), which identifies a particular mobile node.

When a traveler checks into your service area by:

The traveler’s phone was turned on in your service area; your VLR launches a HLR traveler registration request. Each HLR is identified using a Mobile Country Code and a Mobile Network Code.

The HLR responds to the host of your VLR, and your VLR, in response, sends the traveling user to the MSC.

Thus, the traveler is now registered in your service area.

When your client travels outside your service area, but is within the coverage area of your GSM roaming partner network, the process repeats exactly the opposite and messages are sent back to the MSC / HLR of your network.

ETA Primary, Primary and Secondary URLs. The ETA primary URL is a URL

determining the placement of the ETA Number Primary File placed on the Internet itself. The ETA Secondary URL is the URL that defines the placement of the ETA Secondary Number File (mirror copy of the Primary Number File) associated with the ISP. The secondary Number File is primarily located at the ISP's location on the Internet. ETA Main URL defines the location of the ETA Number Main File on the Switch server on the Internet. The Secondary URL and the Main URL are mainly used until the Subscriber is available in real time (is offline - off-line), that is, when the Subscriber is unavailable at its Primary URL, and is also used for verification and verification purposes.

ETA Number File. The Number file is described in detail in US Patent Application No. 10 / 085,717, which is the parent to its Partial Continuation (CIP). Such a Number File is assigned to a specific ETA number designating a Network Subscriber.

Primary, Primary and Secondary ETA Number Files. The Number file contains metadata associated with ETA. The Number file is primarily a data file in the RDF format based on XML and CC / PP. The Main Number File is located at the Main URL on the Switch server, which is described above. The Primary Number File is located on the Subscriber itself - a device accessible on the network at the Primary URL, and the Secondary Number File is located at the Secondary URL on the ISP. There may also be a Tertiary, Quaternary, and so on URL, providing different or distributed Internet and communication services; accordingly, there may exist Tertiary, Quaternary, and so on. Number Files. PFN mainly contains three URLs, i.e. Primary, Primary and Secondary URLs. The main URL always matches the Primary URL of the Switch Server. The Secondary URL always matches the Primary URL of the Internet Service Provider (ISP) of the Subscriber. Both the Primary and Secondary URLs are provided to Subscribers when they subscribe to services, both URLs are recorded in the Primary Number File during commissioning or are allocated dynamically by the network and recorded in the PFN when the Subscriber connects to the network. Both the Primary and Secondary Number Files are mirror copies of the Primary Number File.

File metadata content ETA numbers: Metadata mainly uses XML and compatible with it RDF and CC / PP, as well as other formats and may contain the following data related to the Subscriber:

Telephone Number (ETA).

Primary URL The primary URL is defined if the Subscriber is available in real time (lo-line), and is not defined if the Subscriber is not available ("off-line").

Secondary URL

Primary URL

Authorization Center Primary URL

Primary URL of the Digital Certification Administrator (if it does not match the one for the switch server)

Primary Network Security URL

ETA Number of Authorization Center

Digital Certification Administrator ETA Number

ETA Network Security Number

Primary Public Key (public key of the switch server)

Secondary Public Key (public key of the native ISP of the Subscriber)

Authorization Center Public Key

Digital Certification Administrator Public Key (if different from that for the switch server)

Network Security Key

On-line status. On-line status is derived from the Primary URL.

Current status of available and additionally necessary resources of the Subscriber (device)

Purchased resources and current purchase status (delivery / payment, etc.)

Data related to the Network Security policy contains financial and banking data, electronic wallet, permissions (proxies), access rights, data sets for authentication and identification, biometric data and more.

User preferences (ordinary communication services, such as a subscriber identification service, the procedure and conditions for switching to ordering services, such as instant messaging, text mode, SMS mode, etc.).

Verification and authorization methods and protocols for providing access.

Other metadata disclosed in the Parent Application for this Partial Continuation.

Other data provided by third parties, such as Microsoft Passport or VeriSign certificates and more.

Digital Certificate Certificate Administrator Digital Certificates (Switch) (preferably contains all the fields of the Primary Number File with unchanged values).

Authorized privileges for Public Key Encryption (preferably part of a Digital Certificate).

Metadata located in the protected segment of the Subscriber’s internal memory:

** Credit Card Record **

** Bank Account Information **

** Private key file for public key encryption **

** Password for a one-time phone **

Checking the Subscriber's Availability for Online Communication (Online status check): Description of the ping command to check the IP address.

The "ping" command or another similar one checks the availability of a specific Subscriber in the network in real time by his IP address or DNS name. Command execution is possible as in manual mode in Windows using the Start - Programs - Accessories - Command Prompt path. To verify a specific IP address or URL, the command line should be like this:

ping <here you need to specify the IP address>

or

ping <specify the DNS name here>

The following is a specific example of ping command execution:

Microsoft Windows 2000 [Version 5.00.2195]

(C) Copyright 1985-2000 Microsoft Corp.

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

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 (Web server). This is a network device or program installed on a specific Network Subscriber; usually a web server provides an Internet connection, data and script processing, and more. The web server supports SSL (Secure Layer Layer) and therefore supports the PKI public key infrastructure and its procedures, it can create a Certificate Signature Request (CSR), create Public and Private keys, find, retrieve, receive and place in Memory Digital Certificate issued by the CA Administrator. He may also act within the PKI as the Calling or Receiving Infrastructure Subscriber. A web server can be a device - just a chip, such as ACE1101 MT8 or PIC12C509A / SN fhttp: //world.std.com/~fwhite/ace/) or a program. A web server is always part of the Subscriber, but the Subscriber may not have its own Web server (web server).

Web browser (Web browser). This is a network device or program. A web browser can provide different sets, but should have at least the following:

address processing and finding of Subscribers on the Internet and compatible with Web communications networks; connection with selected Subscribers; visualization of static Internet content (HTML, XML, etc.); visualization of the dynamic content of the Internet, video and audio exchange in real time using technologies for transmitting images and voice over an IP connection (dynamic markup languages, streaming data, VoIP and so on). The web browser supports SSL (Secure Protocol Layer) and therefore supports the PKI public key infrastructure and its procedures, it can create a Certificate Signature Request -CSR, create Public and Private keys, find, retrieve, receive and place in memory Digital Certificate issued by the CA Administrator. He may also act within the PKI as the Calling or Receiving Infrastructure Subscriber.

ETA Address Administrator (AA). AA is the central administrator who maintains a central ETA data warehouse, providing ETA registration to applicants, ETA address management services, and resolving ETA addresses on the network and ETA-related Number Files. The switch server is the central software and hardware complex for data management hosted by the Address Administrator.

Digital Certification Administrator (ACC). ACC is the central administrator of PKI, providing Digital Certificates for ETA Number Files and SSL services. Preferably, the ACS is also the Address Administrator (AA).

Switch server The switch is an Internet server, providing switching services for Subscribers with and without ETA addresses. The switch is the Central Subscriber (switch) of the network and contains the Main ETA Number Files, providing the Main URLs for each of them. As a Network Subscriber, the Switch Server itself has its own Primary, Primary and Secondary Number Files.

System Security File. The switch server and ISP can establish and apply the Network Security Policy for selected or all IP connections, exchanges, calls and transactions. The policy information is placed in the System Security File, available both on the Switch server and in the ISP, located in the Main and Secondary Security Files, respectively. The Security File can have its own ETA number and therefore can be accessed online using such an ETA Security Number. Such an ETA Safety Number may be a well-known number, such as 911 used in the USA, or 01, 02 and 03, used in Russia, and so on.

On-line status. This is the status of the Subscriber's availability for real-time communication. For the purposes of this application, the concept of "on-line status" is understood as the availability of a particular Subscriber via the Web at its Primary URL (status of the Subscriber "on-line"), and the concept of "off-line status" is understood as the inaccessibility of the Subscriber by its Primary URL (status Subscriber "off-line").

“Calling” and “Answering” subscribers. The caller is the Subscriber initiating a call through the IP of another - Responding Subscriber using the ETA number of the latter. Calls can be made as apparatus-with-apparatus, apparatus-with-program, program-with-apparatus and program-with-program IP calls. The Caller may provide the Responding Subscriber with his ETA number and other metadata from the Primary Subscriber Number Number File. The caller may also be an anonymous person.

IP call. An IP call is an Internet connection between Callers and Answers, established for data exchange, visual and audio point-to-point exchanges using the Internet and the TCP / IP protocol, image and sound transfer technologies over IP (voice & video over IP technology), and others appropriate tools for working with the Web. It can be implemented as calls of the type wired network - mobile network, mobile network - wired network, mobile network - mobile network, the present invention also offers the possibility of connections such as browser-wired network, browser-mobile network, mobile network browser, and wired network -browser, moreover, a mobile network is understood as a mobile cellular, satellite or any other wireless connection. In protected mode, an IP call can use any known encryption algorithms and methods, such as RSA, Diffie-Hellman and others, SSL, MS SSI and PKI.

The communications provider is ISP (Service Provider). A Telecommunications Operator or ISP in an application means companies that provide telecommunication services with the ability to access the Internet. As a Subscriber, each ISP can have its Main, Primary and Secondary Number Files.

Point of Sales -POS. POS terminals is a network node endowed with an ETA number, which provides data exchange, sales support and transaction services. Each POS can be endowed with an ETA number and therefore can be a Subscriber in networks providing Internet access.

Implementation

Use of preferred standard authentication methods (authentication). Recommendations to the X.501 standard (X.501 recommendations).

X.509 directory services (X.509 directory services); X.519 directory services protocol (X.519 directory services protocol); Preferred use of the IETF Kerberos (http: // www. Ietf. Org / html. Charters / krb-wg-charter.html): Cryptographic Message Syntax -CMS; another.

Digital certificates, encryption issues: X.509 Internet, PKI certificates can be used in accordance with the IETF specification "Use of ECC Algorithms in CMS", located on the Internet at http://search.ietf.org/intemet-drafts/draft-ietf -smime-ecc-06.txt for distributing public keys. The use of ECC algorithms and keys within the framework of X.509 certificates is described in the works:

- 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, February 15, 2000.

- SECG, "Elliptic Curve Cryptography", Standards for Efficient Cryptography Group, 2000. The document is available at www.secg.org/collateral/secl.pdf.

Financial services and transactions: Preferred is 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

Creating a Primary Number File (PNF). When a user first becomes a customer of services based on the use of the ETA number, he provides the Address Administrator and the Digital Certificate Administrator with all the necessary information, including his ETA number, and based on this information, the Primary Number File (PFN) is generated. To use the PFN for transactions and SSL services, the Administrator of Digital Certificates - ACS issues a Digital Certificate (CA) that allows the use of SSL and PKI. The open part of the information for PKI is placed in the ETA PFN and is available to other PKI users, and the closed part is placed in the protected memory segment of the Subscriber. The CA is signed by the ADC Private Key and contains at least the ETA number and the Subscriber's Public Key. The CA conforms to the X.509 format; The ETA number is contained in the X.509 extension.

Providing the Primary URL and synchronization with the Primary Number File: Each time the Subscriber enters the network, the network registers it and assigns it the Primary URL; after providing the Primary URL, this URL is preferably transferred to the Subscriber and placed in the metadata of the Primary Number File; the value of the Primary URL is then preferably located in the Secondary Number File (on the ISP) and in the Main Number File (on the Switch server). During registration on the network, the Switch preferably authenticates (authenticates) the Subscriber using the Subscriber’s CA; Then, the Subscriber synchronizes the fields of the PFN with the corresponding fields of the Main and Secondary Number Files. To do this, the Subscriber extracts the values of the Main and Secondary URL fields from the PFN and, using them, establishes a connection with the Main and Secondary Number Files, respectively; when the connection is established, the Subscriber starts the synchronization of metadata. For authorization and verification by the Subscriber and to prevent access of dummies (imposters) to network resources, the Switch server, ISP or any other Subscriber or network visitor using SSL procedures can retrieve the CA from the PFN, decrypt it using the Public key of the ADC, and obtain at least the ETA number and the Public key owned by the Subscriber; then, exchanging over SSL, the verifier can verify that the Subscriber does not play the role of the real Subscriber, but is one and has the appropriate privileges.

Update Secondary and Main Number Files: ISP constantly and timely updates the Secondary Number File, establishing a connection with the Primary and / or Main Number Files. The Subscriber’s availability in a real number mode (“on-line” status) can also be established by the usual methods through communication service providers and then to the Number File format and placed in the Secondary Number File.

Updating the Main Number File:

Method 1: The switch server constantly and timely updates the Main Number File by extracting data (Switch - pool method) or receiving data (ISP push method) from the Secondary Subscriber Number File; if a call to a specific Subscriber is received from the network, the Switch server retrieves the Primary URL of this Subscriber from the Main Number File and, if the Primary URL is defined, then the Switch establishes a connection with it; If the connection is not established, the Switch disconnects and sets the Primary URL in the Main File of the Number to “zero”, and the value of the status field is set to “off-line”. In another case, the "on-line status" of the Subscriber can be obtained using other ISP's own capabilities, and then extracted from the ISP and placed on the Switch server for each specific Subscriber. Alternatively, the Switch server can constantly check with a command like “ping” all Subscribers, using their Primary URLs and thus checking their “on-line status” constantly. Each time the on-line status check ends, the Switch updates the status field in the Main File of the Number of each Subscriber / ЕТА.

Method 2: Once in the network coverage area, each Subscriber establishes a connection with the Switch server and synchronizes the metadata of his Primary Number File with the Main Number File. The switch constantly and in a timely manner connects to each specific Subscriber and updates the values of the fields of the Main File of the Number with data taken (Switch-pool method) or received (Subscriber push method) from the Primary File of the Subscriber Number; when a call is received from the network for a specific Subscriber, the Switch server retrieves the Subscriber’s Primary URL from the Main Number File and, if the Primary URL is non-zero, the Switch establishes a connection with it. If it is equal to zero or the connection cannot be established, the Switch disconnects the connection and sets the value “zero” in the Primary URL field of the Subscriber, and in the status field the value “off-line”.

Making an Outgoing IP call: when the ETA number of the Calling Subscriber is entered into the address bar of the Internet browser or other Internet program, the Calling Subscriber establishes a connection and exchanges data with the Switch server, as described in the parent Application for this Partial Continuation, and receives the metadata of the Responder Subscriber from his Main Number File; if the ETA Primary URL of the Responding Subscriber is not equal to zero, then the Calling Subscriber tries to establish a connection with the Responding Subscriber using his ETA Primary URL taken from the Main File of the Number of the Responding Subscriber; if the Primary URL is valid (relevant) and the Subscriber answers, then the Calling Subscriber and the Responder provide each other with their CAs and do a check in accordance with the current network security policy; depending on the policy, the Caller can access the Primary Responder Number File and vice versa The Responder can check the Primary Caller Number File; The caller and the Responder process the security data, following the established procedures of the security policy, gaining access to the data and exchanging data with the Responding Subscriber, if permissions are allowed. It mainly uses the IETF Session Initiation Protocol or similar to it for the exchange between the Caller and Answering Subscribers.

When the Primary URL of the Responding Subscriber is valid and the Calling Subscriber connected to the Responding Subscriber, but the latter does not answer (“does not pick up the phone”), the Calling Subscriber tries to leave a message in the memory of the device of the Responding Subscriber;

When the Primary URL is not valid or equal to zero, the Browser retrieves the Secondary URL and tries to find the Secondary Number File on the network and so on, and when the next URL that responded is found, the web browser allows you to compose and leave any type of message there.

Answering an incoming IP call: when an IP call is received, the Answering Subscriber automatically switches to the corresponding “answer” / “refuse to answer” mode or another mode, rings or otherwise informs you of an incoming connection (call);

The responding Subscriber is trying to extract the ETA and CA number from the Primary Subscriber Number Number File; The Responding Subscriber can verify the validity of the ETA and CA, as well as the privileges of the Caller, using the PKI. After verification, the Responding Subscriber decides to grant or refuse the connection to the Caller in accordance with the security and calling policies, privileges and preferences of both parties defined in the metadata of their Number Files and their CA. If it was required to establish a secure connection, then both sides begin to encrypt the data exchange using SSL and PKI, as well as their Public and Private keys. Secure Communications mode allows you to make purchases, pay and use other services and transactions in a secure manner. When verification, verification, authentication is completed, the parties primarily use the IETF Session Initiation Protocol or similar for exchange between the parties.

Turn on and off the lists of subscribers. Each specific Subscriber has a list of other network Subscribers related to this particular Subscriber one way or another (that is, a list of phone numbers of friends, partners, relatives, etc.). The list can be divided at least mainly into the following parts: those Subscribers who are not allowed to see the on-line status of this particular Subscriber; Those Subscribers who are allowed to see the on-line status of this particular Subscriber; Those Callers who are not allowed to connect to this particular Subscriber; those Callers who are allowed to establish a connection with this particular Subscriber, etc. Therefore, each Calling Subscriber can check and receive an "on-line status" only for those Network Subscribers who have allowed this Calling Subscriber to check it. Before making a connection with a specific Subscriber, the Calling Subscriber can check if the Responding (called) Subscriber is available (on-line) in the network, and if the Responding Subscriber is not available (off-line), the Calling Subscriber can refuse to attempt to establish a connection and save time this way.

Issue of digital certificates (CA) for ETA / Subscriber. When the ETA Address Administrator creates and registers the ETA number associated with a particular Subscriber and creates the Primary Number File for the Subscriber, the Digital Certification Administrator (ACC) in turn creates a Digital Certificate (CA); to create a CA, the Subscriber must be able to support work through SSL and

the subscriber fills in all the necessary fields of the Primary Number File (preferably all fields of the PFN with unchanged values), and then generates a Certificate Signature Request -CSR file, as well as Private and Public keys; The private key is stored in the protected memory segment of the Subscriber.

The subscriber provides the CSR and the Public Key for signing the ADC.

The Public Key File and the Primary File ETA Numbers are encrypted (signed) by the ADC Private Key, and this encrypted file is an ETA Digital Certificate.

The ACS signs the CSR and returns it to the Subscriber as a Digital Subscriber Certificate (CA). The CA includes ETA and is digitally signed by the ACS.

The Subscriber places the CA in the Primary Subscriber Number File and makes it available for SSL procedures.

Verification and Authentication are used to prevent imposters from accessing the resources of the network or its specific Subscribers and are implemented using the PFN of a specific Subscriber with the participation of the Digital Certification Administrator, Switch or Subscriber:

Simple authentication in insecure mode (SSL is not used):

ETA is extracted from the Primary Subscriber Number Number File; Extracts the Primary, Primary and Secondary ETA Files of the Caller Number;

ETA, Caller’s number are checked by comparing key data taken from the Secondary and Main Number File with the corresponding taken from the Primary Number File; if the data matches, then the verification (verification) is completed successfully and the calling Subscriber is allowed to use the services requested by him and the Subscriber is provided with the verification of the Switch.

Strong authentication in secure mode (SSL is used) here Subscriber A (A) authenticates Subscriber B (B):

B:

Encrypts Data B using Private Key B, generating Data B1, Creates a verification message containing CA B and Data B1, Transmits a verification message to Subscriber A, and

BUT:

Retrieves CA B and Data B1 from the verification message

Decrypts CA B using the ADC Public Key

Retrieves Data B and Public Key B from decrypted CA B

Decrypts Data B1 using Public Key B and generating Data A

Compares Data A with Data B and, if Data A is identical to Data B, then A concludes that B owns the correct and certified ACS Private Key B, as well as the verified Data B, therefore B is authentic.

Here, Data B is preferably part of CA B and ETA B; or other fields of CA B, or some or all of the fields of CA B; or full CA B.

Other similar relevant authentication procedures can be established based on the use of a particular cryptography method.

Verification, authentication and authorization by the Responding Subscriber. For authorization and verification of the Calling Subscriber and to prevent unauthorized access of imposters to the resources of the Subscriber using a fake Primary Number ETA Number of the Calling Subscriber, a specific Subscriber via SSL

Extracts a Digital Certificate from the Primary Caller Number Number File; decrypts the CA using the ADC Public Key (Switch); checks the validity of the CA; Authenticates the Caller; provides the Calling Subscriber with a connection with the Responding Subscriber taking into account the privileges of the Calling Subscriber, if he passed the verification successfully, and refuses him to connect, if he did not pass the verification.

Verification, authentication and authorization by the Caller. In order to verify that the connection occurred with a real, and not a fake Answering Subscriber, and in order to prevent unauthorized access of imposters to the resources of the Calling Subscriber using his PFN, in the process of establishing a connection with the Responding Subscriber, the Calling Subscriber extracts the CA of the Responding Subscriber from his PFN; decrypts the data of the CA using the Public Key of the ADC (Switch); verifies the ETA Number of the Responding Subscriber and verifies its privileges.

Transaction services through a secure connection between Subscribers representing the Buyer and the Seller.

Services for conducting transactions through an IP connection can be provided based on the corresponding Network Security policy and user privileges using the Secure Socket Layer (SSL) layer, PKI infrastructure and ETA ADC numbers. The Public Key Encryption method allows checking ETA numbers through the Public Key Cryptography Infrastructure (PKI) public key encryption infrastructure. The SSL (secure socket layer) layer allows you to use PKI to conduct secure electronic and mobile commerce transactions, provide banking services, data exchange and real-time exchange services. All of them are based on the use of CAs and the content of Certificates. Payments between the Buyer and the Seller can be made using procedures similar to the authorization of payment by credit card, as described below:

Buyer Message

"Buyer Message" is a message created by the Subscriber by the Buyer. "Buyer Message" preferably contains:

Seller's CA

Merchant primary URL (optional)

Purchase data (monetary unit and purchase amount, purchase time, purchase / transaction number and other necessary purchase information).

"Buyer Message" is a Purchase Agreement certified by a digital signature, that is, encrypted using the Private Key of the Subscriber - Buyer.

Seller Message

"Message of the Seller" is a message created by the Subscriber - Seller. "Seller Message" preferably contains:

Buyer CA

Buyer's primary URL (optional)

"Buyer Message" signed using the Buyer's Private Key. Purchase data (monetary unit and purchase amount, purchase time, purchase / transaction number and other necessary purchase information).

"Message of the Seller" is a Sales Agreement certified by a digital signature, that is, encrypted using the Private Key of the Subscriber - Seller.

Login

"Authorization" is a message compiled by the Authorization Center. “Authorization” preferably contains:

Buyer CA

Buyer's primary URL (optional)

"Buyer Message" signed by the Buyer's Private Key.

Purchase data (monetary unit and purchase amount, purchase time, purchase / transaction number and other necessary purchase information).

"Authorization" is an authorization signed digitally, that is, encrypted using the Private key of the Authorization Center.

Authorization Method "Payment"

Contains steps:

A wired or wireless connection is established between the Buyer and the Seller.

The user is shown on the display or in another way the name of the purchase, its price and other data on the purchase / transaction are reported.

The Subscriber’s device is awaiting receipt of permission (authorization) of the Buyer to make a purchase, and if permission is obtained:

Strict mutual authentication between Buyer / Seller in secure mode is preferred.

If the Seller and the Buyer are authentic. Buyer:

Composes Buyer Message

Establishes a connection to the Authorization Center using the Primary URL

Authorization Center

Performs Strong mutual authentication with the Authorization Center in a secure communication mode, if required

Transmits the "Buyer Message" to the Authorization Center

Authorization Center:

Decrypts the “Buyer Message” using the Buyer's Public Key, taken from the Buyer's CA in the Authentication process and

Authorization Center

Composes the message "Authorization"

Sends an "Authorization" message to the Buyer

The buyer transmits an "authorization message" to the seller

The seller decrypts the message "Authorization" using the Public key of the Authorization Center

Or Authorization Center:

Allows (requests a search) through the Switch Server the Seller’s primary URL using the Seller’s ETA number taken from the Seller’s CA; OR takes the Seller’s Primary URL from "Buyer Message"

Establishes a connection with the Seller using the Seller’s Primary URL

Authenticates the Seller and, if the Seller is authentic:

Checks (verifies) the parties to the transaction and the purchase data

Composes the message "Authorization"

Sends an "Authorization" message to the seller

The seller decrypts the message "Authorization" using the Public key of the Authorization Center

The seller permits the sale (transfer of goods / services to the Buyer) if the payment is authorized by the Authorization Center

Retention Authorization Method

Includes steps:

A wired or wireless connection is established between the Buyer and the Seller

The user is shown on the display or in another way informed the name of the purchase, its price and other data on the purchase / transaction

The Subscriber’s device awaits the receipt of authorization (authorization) of the Buyer to complete the purchase and, if the permission is received:

Strict mutual authentication between Buyer / Seller in secure mode is preferred.

If the Seller and the Buyer are authentic. Buyer:

Composes Buyer Message

Transmits the "Buyer Message" to the Seller; and Seller:

Decrypts the “Message of the Buyer” using the Buyer's Public Key, taken from the Buyer's CA, and verifies the purchase data, if it is prescribed by the policy used, and if the purchase data is correct, then

Composes a "Seller Message"

Establishes a connection to the Authorization Center using the Primary URL of the Authorization Center

Performs Strong mutual authentication with the Authorization Center in a secure mode, if this requires a security policy and if the authenticity of the parties is established:

Transmits the "Seller Message" to the Authorization Center; and Authorization Center:

Decrypts the "Message of the Seller" using the Seller’s Public Key, extracts and decrypts the "Message of the Buyer" using the Buyer's Public Key, taken from the Buyer's CA

Verifies transaction parties and data

Composes the message "Authorization"

Sends an "Authorization" message to the seller

The seller decrypts the message "Authorization" using the Public key of the Authorization Center

Seller permits sale if payment authorization is received

Credit Card Record. A Credit Card Record (CCC) is a typical credit card entry. ZKK is usually written on a magnetic strip of a credit card or is contained in the internal memory of a smart card or in another memory of a credit card.

Credit card payment authorization method. In order to use a credit card for real-time transactions, the CCM must be read from a credit card and recorded in the metadata of the Subscriber’s Protected Memory Area. Then CCC can be used, as described in the Methods of Authorization. If a specific credit card system (such as VISA, MasterCard or others) requires a change in the CCK during the authorization of a particular transaction, the changed CCC by the credit system is returned to the Subscriber encrypted with the Subscriber’s Public Key, then the received CCC is decrypted by the Subscriber with its Private Key and placed in the metadata of the Subscriber’s Protected Memory Area for further usage.

The method of debiting funds from a bank account. Withdrawal from a bank account can be ensured by a method similar to that described in the section Authorization method of payment by credit card.

Temporary ETA. To reduce the cost of calls and increase the flexibility and accessibility of communication services, the ADC (Switch) can produce Temporary CAs containing ETA numbers, the latter are used for disposable handsets with the ability to communicate via the Internet, as well as for Internet browsers and other network objects / Subscribers collectively called Temporary Subscribers (VA); all of them can establish connections as the Calling or Answering Subscribers in the network. ACS (Switch) produces ETA and CA ETA; places the ETA and CA directly in the BA Number File or transfers them to the resellers who assign these ETA / CA to the specific BA, placing them in the Primary BA Number File.

Such disposable handsets can use Transactions, exchange text, voice, image via IP connection, they can be sold and activated for use with or without assigning them a permanent ETA network number. When the purchased handset is first turned on by the user, it prompts the user to manually print or select a specific predefined ETA number, or select temporary ETA numbers automatically offered by the network.

Pseudostatic ETA mode: If the user wants to use a specific ETA number, the handset preferably requires a “Password for temporary ETA number” to verify the user’s rights to use ETA (this password is similar to the use with personal identification numbers for SIM cards of GSM phones); when the password is entered, the handset establishes a connection with the server of the Administrator that issued the ETA number (AA, Switch server, ISP, reseller) through the SSL layer and checks the "Password for temporary ETA number" or compares the password with the encrypted password located in the protected memory of the handset; if the check was successful (the password is correct), the user is granted access to network resources using the selected ETA, and the user is recognized as the legal owner of the ETA; if the check is unsuccessful, the handset may be denied the provision of network resources or it may be declared stolen depending on what is stipulated by the network security policy, or

A specific ETA number and a CA for it can be provided and be valid for a standard set period of time, a set number of connections / transactions for the handset / program and, if assigned, such an ETA number must be entered (it can be programmed so that the ETA itself appears in user interface immediately after turning on the handset / program) and its use is confirmed by the user command.

Dynamic ETA mode: When a user turns it on for the first time after acquiring a handset, the handset establishes a connection to the Switch server via the Internet; The switch server registers the handset in the network and assigns it the Dynamic ETA number and the Main Number File; The Main Number File is a copy of the ETA Primary Number File; Dynamic ETA can only be used during a specific connection, unless the user requires you to assign an ETA number to it for a standard period of time or other standard conditions of use. Dynamic ETA is called back after the connection is completed or assigned to the Temporary Subscriber for a standard period of time at the request of the user. In order to keep the ETA Dynamic Number under standard conditions, the handset must be able to update its Primary Number File with a specific dynamic ETA, and the ADC must release a CA containing ETA and assign the CA to the handset as described above.

Use of PFN as Digital Identity Card data.

PFN can be used as a Digital Identity Card, which includes all the identification information required for the specific purposes of verification, authentication, authorization and transactions.

Encryption of sessions using shortened key pairs. For

real-time acceleration of encryption of the transmission of audio and image streams Subscribers can use Short session Key Pairs. For this, each Subscriber:

- Generates a new pair of short keys (Public and Private)

- The private key is stored in the Protected segment of the internal memory of the Subscriber and is used only for one communication session

- Each Subscriber encrypts a new short Public Key using the Original Private Key, the Sending Subscriber, or using the Original Public Key receiving the Subscriber, and transmits the Short Public Key encrypted in this way to the Receiving Subscriber

- The receiving Subscriber decrypts the message containing the Short Public Key of the opposite Subscriber, and uses it to encrypt / de-encrypt the exchange of data (streaming data) with the Sending Subscriber.

OR alternatively:

Each Subscriber creates a Pair of new short keys in such a way that the Short Public Key of each Subscriber is the simplest number in the account closest to the ETA number (or the number calculated on the basis of ETA established in the network) with a shortage or excess of it, and proximity to the ETA number is determined by the current Network Security Policy, and the Private Short Key by each Subscriber is selected so that it is practically very difficult to calculate.

Thus, using the current Network Security Policy and ETA number of the Subscriber, Network Subscribers can calculate both their own Short Public Key and the Short Public Key of the opposite Subscriber without the need to exchange Public Keys with each other.

Thus, each Subscriber has a Short Public Key

of the opposite Subscriber and uses it to encrypt / decrypt the exchange of data (streaming data) with the opposite Subscriber.

It is clear that in the Public Key Infrastructure, Subscribers can encrypt messages (flows) in two ways:

175. using the Private key of the Sending Subscriber, and the Receiving Subscriber decrypts it with the Public key of the Sending Subscriber. The encrypted message in this case can be decrypted by any Subscriber having the public key of the Sending Subscriber, and the secret of correspondence is NOT guaranteed

176. using the Public key of the Receiving Subscriber, and the Receiving Subscriber decrypts the message using his Private key. The encrypted message in this case can NOT be decrypted by anyone other than the Receiving Subscriber, and the secret of correspondence is GUARANTEED

Business model 1: sale of ETA numbers that are valid for a certain period of time or for the number of services provided or for a certain amount of money and so on.

Business model 2: sale of Digital Certificates, where the ETA number is the main verifiable part of the certificate, privileges contain terms of use that are valid for a certain period of time or for the number of services provided or for a certain amount of money and so on.

Business model 3: Sale of PFN with a permanent ETA number for permanent Subscribers or without a permanent ETA number for Temporary Subscribers.

Business Model 4: Sale of media (SIM cards for GSM and later versions of the 3rd generation communication standards (3G standards), CD, DVD, or other media) with PFN files recorded on such media.

Business model 5: Sale of writable memory chips or processors with PFN files written to memory.

Business Model 6: Sale of PFN as a Digital Identity Card.

Business Model 7: Selling “permissions” to the ETA number and / or Number File (search transactions for the Primary URL from a known ETA number / Number File) with payment for each “permission”.

Business model 8: Sale of ETA number and / or File Number data to third parties with payment for each provision of ETA and / or Number File data.

Business model 9: Sale of authentication services for ETA numbers and / or File Number data with payment for each authentication.

Business model 10: Sale of payment authorization services by ETA number and / or File Number data with payment for each authorization.

Business model 11: Sale of development tools (Software Development Kit-SDK) that implement the functionality of using ETA methods specified in the application.

Professionals and professionals will also appreciate the possibility of using a Credit Card Record (CCC) or a bank account record encrypted using the Private Key of the Authorization Center. Such an implementation provides an opportunity to limit to one the number of parties that can read the CCC, and the only such party is the Authorization Center. Due to this, such an implementation provides sustainable security during transactions and protection against theft with the highest level of security. Another feature is that this implementation allows the use of conventional existing payment authorization devices using the main types of credit cards and therefore makes the implementation of the claimed authorization method very inexpensive. Using Encrypted ETA-ZKK (3-ETA-ZKK) makes authentication twice as reliable, allowing you to compare ETA extracted from 3-ETA-ZKK with ETA extracted from CA.

Professionals and professionals will also appreciate the possibility of using the Encrypted Account Record (ACL) obtained by encrypting the Account Record (AC) using the Public Key of the Authorization Center. This implementation allows you to limit to one the number of parties that can read the AP, and this is the Authorization Center. Due to this, such an implementation provides sustainable security during transactions and protection against theft with the highest level of security. Using the Public key of the Authorization Center to encrypt the ЗЗЗ and ЗКК also allows any third party to encrypt the ЗЗС or ЗКК and thereby allows an unlimited number of parties to reliably and securely protect client account records and join in using the services of the Authorization Center in this way.

Professionals and professionals will also appreciate the fact that, thanks to the issuance of a Digital Account Certificate (DSS) containing an ETA (Unified Transactional Address) of a network resource, as well as a Resource Public Key and an RFA of a resource, CA / CA (Authorization Center and aka Certification Authority - earlier also called the Digital Certification Administrator - ACS) it gets the opportunity to authenticate a specific network resource on the fly and check the rights of this resource to use a specific ZZS, safely and reliably matching the ZZS to such a resource to provide secure transaction services. This, in turn, allows the CA / CA to avoid creating, managing, and safely maintaining a database that establishes a correspondence between the ZZS / ZKK and ETA of a specific network resource, and the latter circumstance, as a result, allows the CA / CA to avoid the costs associated with having such Database. On the other hand, the lack of a database allows the CA / CA to free itself from possible errors in the security system for the content of the financial and personal data of the database.

Another feature is that ЗЗС allows using the usual existing authorization infrastructure of the main credit card systems, and therefore makes the claimed method very inexpensive to implement, practically reducing the needs of the CA / CA to having a single POS (point-of-sales) terminal and using a single account seller (merchant account) system for receiving and processing credit card payments.

The use of ZZS along with the CA allows sharing the responsibility in providing the services of certification and authorization centers, and also creates the conditions for the distribution of various ulsugs without compromising the level of security during transactions.

The independence of the technology for creating an RFA from the subject area, the type of data and the origin of the account (bank, service provider account, credit card account, etc.) makes the method uniquely universal for accounts of any nature, including, but not limited to, bank accounts, credit card systems, accounts customer service providers, biometric accounts and any other accounts.

Another feature is the ability to encrypt the PIN (personal indentification code) of the resource’s code or password using the Public key of this resource, which allows the resource to independently create, change and manage the password as a means of protection against theft, protecting the resource when it is used for transactions.

Transaction Infrastructure

The transaction infrastructure is shown as an example in FIG. 10 and contains network resources 1000, each of which is assigned an ETA identifier (Unified Transaction Address), network resources of financial institutions 1001 and 1002, each of which has an assigned ETA identifier and an authorization and clearing infrastructure 1003. Each network resource represents a Payer or Recipient of payment, and financial institutions are organizations that provide financial accounts (preferably banks) for the indicated Lei payments and payers, and infrastructure is a transaction authorization and settlement system, which is in accordance with the illustration of a settlement (clearing) the financial institution providing clearing accounts given to another 10 financial institutions.

The indicated financial institutions are assigned Route ETA (META). Each META identifier is an ordinary ETA or a specific ETA. META are issued, assigned, placed and indexed in the database of the Switch Server (Central Switch).

The described method involves the creation of specific “zero-based” META system identifiers. This method allows you to assign a zone with a “zero” country code containing 100 billion available numbers and, in particular, a “full zero” number + 0-000-000-0000; as well as a “zero zone”, such as + 7-000-000-0000, containing up to 1 million available numbers for each country; as well as a “zero-based” array of numbers in each region of each country, providing up to 1 million additional ETA numbers for each region code, for example, an array from + 7-095-000-0000 to + 7-095-099-9999 specifically for purposes authorization in the Moscow region, Russia. For example, for the Global Registry of ETA Identifiers or the Global Clearing and Authorization Chamber 1101 transactions, as shown in FIG. 11, ETA can be assigned from among “full zero” identifiers, and for local authorization nodes, for example, ETA with a zero country number, region or a number starting with zero, such as, for example, 000-OOOX.

By analogy with the ETA banking system, a financial account for a specific resource for global addressing and accessibility should include both the ETA of the resource itself and the META number of the financial institution on the network, and therefore the global route number will have a META / ETA format. For example, the record + 7-095-000-0000 / + 7-095-123-4567 could mean that the resource belonging to Russia and the region 095 of the city of Moscow, having the identifier ETA + 7-095-123-4567 assigned to it, is being serviced financial institution located also in Russia, in the 095 region of Moscow and having the assigned route identifier META + 7-095-000-0000.

Correspondent relations between the banks themselves can be designated in the same way, forming “complex” META containing the sequence of META numbers of the respective banks. For example, as shown in FIG. 10, META2 / META1 / ETA will mean that a specific ETA resource is a client of a specific META1 bank, and META1 bank itself has a correspondent account with META2 bank. This allows you to organize a very simple route addressing system by placing the appropriate META route information in the Resource File. It also allows you to create an infrastructure in which, regardless of the location of the resource or its bank, each specific resource can choose any particular bank to service its own account, as well as use many bank and credit card accounts.

In each region code of a particular country, financial institutions can be indexed using conventional ETA, although the META identifier system is preferable and allows sequential numbering, in which the first META assigned within a particular region code has “0” as the value of the rightmost digit, the following “ 1 ”, the next“ 2 ”, and so on, the number being completed to the size of the full telephone number by adding zeros to the left. The last ETA in such an array would start with "0", having only the digits "9". Therefore, for example, the first META assigned in Russia in the region 095 of Moscow would be + 7-095-000-0000, and the second + 7-095-000-0001, the next + 7-095-000-0002 and the last + 7- 095-099-9999.

The described “zero” method for assigning META numbers allows you to use “zero” numbers to provide transaction services and to create a database of META numbers with sequential numbering. This array of available numbers starts from 000-0000 to 099-9999 for 7-digit telephone numbering and provides up to 1 million available route numbers within each region code of each country.

The invention creates the possibility of simple addressing of payments, in which the Payer or the Payee only needs to know the appropriate ETA number to ensure simple routing of the transaction or payment between the bank accounts of the Payee and the Payer. The invention creates a universal approach in which financial institutions are network resources that have ETA identifiers assigned to them, and financial institutions can receive payment orders signed by transaction participants, authenticate the payer using ETA of a specific resource, and make a payment from a bank account belonging to such specific ETA payer resource.

All financial institutions must have META numbers and meet the requirements of transaction gateways in order to ensure the flow of transactions through the ETA / META transaction infrastructure. The gateway should provide an opportunity in real time to compare the internal numbers of financial accounts with the corresponding ETA identifiers of their respective owners, or the internal numbering system should be built on the basis of ETA numbering, which will allow using ETA authentication as the main part of the payment authorization process.

As shown, the invention allows the use of ETA identifiers for routing purposes as well. ETAs represent a higher identification layer, located on top of traditional Internet routing systems and communication networks and for financial infrastructure. Therefore, the ETA layer extends, integrates and unifies addressing on the Internet and telecommunication networks and the addressing of financial exchange and routing, it also creates a universal transport layer ISO / OSI for network resources of any nature.

Clearing and Authorization System Infrastructure

After making a payment from the bank account of a specific Payer, the Payer's bank must transfer funds to the Beneficiary's bank. Therefore, between financial institutions there must be a settlement center (clearing center) that performs interbank settlements.

In one of the designs shown in FIG. 12, the system may use existing infrastructure, such as based on SWIFT numbering or domestic numbering, such as, for example, American Bank Association (ABA) numbering in the United States, or numbering based on Bank Identification Codes (BIC) as in Russia, or on other numbering systems designed for clearing and interbank exchange. In this design, existing EIF identifiers can be associated with existing SWIFT identifiers, or ABA numbers, or BIC numbers, or other route identifiers and the corresponding meaningful information.

Alternatively, the authorization and clearing system can be created as an independent Clearing and Authorization Chamber (PKA), using unified ETA procedures for authentication between the banks of the Payer and the Recipient, using their respective META bank numbers as the main verified part.

Another implementation could not include a PKA and, on the contrary, could be built using bilateral authorization and clearing agreements between banks, in which the Payer's bank can directly establish a connection with the Beneficiary's bank, and after mutual authentication transfer the signed Payment Order to the Beneficiary's bank and clear operations as described here.

Digital Transaction Agreements

Any agreements may be concluded between resources by digitally signing an Agreement of relevant content. The agreements also include Payment orders, invoices and other documents, the authenticity of the creator's signature under which is verifiable. Digital agreements signed using ETA Digital Certificates are preferred in the framework of the described method.

Online transaction services are those in which the Payer and the Recipient are available in real time.

Online transaction services use the Public Key Infrastructure and digital signature to authorize transactions.

The use of META identifiers can be implemented by placing META numbers together with the Encrypted Account Record (ZZS) or without placing the latter in the CA or Attribute CA (ACC). Many accounts can be “resolved” (referring to the technique of network resolution of names / addresses / identifiers) and managed using the ETA infrastructure for each specific network resource called. To create the ability to manage multiple accounts of a particular resource, the corresponding META numbers of specific financial institutions should be placed in the CA or ACC of the resource. Therefore, at least the ETA identifier of a particular resource, its Public Key together with the META identifier of a financial institution serving a specific resource account must be placed in a Digital Certificate or Attribute CA, creating the possibility of making incoming and outgoing payments for specific accounts of such a resource.

There are three types of digitally signed agreements:

Transaction Agreement

The CC contains Digital Certificates and / or ACS of both parties to the transaction and the agreement itself to buy signed by the digital signature of the Buyer and the agreement to sell signed by the digital signature of the Seller, as well as the amount / currency of the transaction.

Payment Agreement (PS)

PS is an agreement to pay, signed by the digital signature of the Payer; The PS contains at least the Payer's CA, its ETA identifier, as well as the amount and currency of the payment. PS may be unconditional or contain the purpose of the payment.

Electronic Payment Agreement

This is an agreement issued and signed by a financial institution for conducting an interbank exchange and containing at least an SS or PS agreement concluded by a client of this financial institution, a CA of the financial institution itself, as well as the value of the payment amount / currency and other necessary information.

The proposed method provides for the provision of at least three types of services:

- A Transaction Agreement is when both parties to an agreement must sign a transaction agreement reflecting their mutual consent to buy and sell;

- A Payment Agreement is when any network resource can make an unconditional or conditional decision to make a payment in favor of another specific network resource;

- An Electronic Payment Agreement is an agreement between two financial institutions that allows them to make counter payments and clear them.

The Transaction Agreement is used for both B2C and B2B transaction types and between individuals.

For example, for e-commerce on the Internet, for ordinary purchases in a supermarket, at gas stations and wherever a cashier receives money by entering the customer’s ETA identifier as a payer in the POS terminal, and the customer will receive a payment invoice on his network device and authorize the payment by entering authorization password to your network device. The Transaction Agreement can greatly simplify the payment for telecommunication services, when the service provider initiates payment by invoicing (payment request) directly to the client’s network device and the end user of the device simply authorizes the payment by entering an authorization password.

The Transaction Agreement can also serve B2B, providing real-time transaction services for network devices of various enterprises dispersed throughout the World.

The Transaction Agreement may also simplify the conduct of transactions between individuals connected by a network and located in different parts of the world at the time of the transaction.

Generally. The Transaction Agreement during the transaction allows the Payer and the Recipient to sign a binding agreement on the delivery of goods, services or information for payment, creating the legal basis for the transaction and, thus, each of the parties receives the necessary legal protection.

The Payment Agreement is used to conduct transactions in which the payer may have an intentional or unconditional intention to transfer funds to the Beneficiary's account. PS is used when the called end user needs to transfer funds to someone else. Such a service can serve as an online replacement, for example, services provided by offices and representatives of Western Union.

Using “ETA ZKK”

To make payments with a credit card, the described method involves the use of ETA identifiers for credit cards and other media containing a readable ETA identifier used for credit card account entries. Payment can be made if a secret PIN code corresponding to the ETA identifier of a specific resource, the Payer, has been entered into the POS terminal and confirmed.

An example of an ETA payment in a supermarket.

When a buyer with a basket of full purchases comes to the store cashier, the cashier calculates the purchase price by reading the barcodes from the purchases either manually or in another way and receives the full purchase price.

Then, if the buyer prefers the ETA payment method, the cashier either enters the ETA customer number into the POS terminal manually, or reads the ETA barcode placed on the surface of the buyer's mobile phone or on the buyer's credit card, or on the buyer's business card, and so on. Buyer's mobile phone may be able to display the ETA barcode on the display. The ETA number barcode is read by a regular POS terminal barcode reader of a store seller.

The cashier then confirms the entry of ETA and then:

Real time mode:

The POS terminal sends a message with a request to pay for the purchase on the buyer's mobile phone, the phone receives a message and shows the authenticated Seller ID, payment amount and the question: “accept” or “reject” the payment.

The buyer selects “accept” and enters his secret password to confirm the payment.

The cashier and the Buyer receive a message - confirmation of payment from the Authorization Center, respectively, to the seller’s POS terminal and to the buyer's mobile phone.

The confirmation is saved and the transaction is completed.

In this example, the phone may also be able to receive a list of purchases from the POS terminal, including their cost, barcode purchases, product images, weight, price per kilogram and other characteristics of each of the purchased goods. The phone may also be able to save the data received for use the next time the buyer wants to repeat the purchase for the items he has chosen from the list.

The phone may also be able to manage multiple bank and credit card accounts, allowing the user to select one from the accounts for a specific transaction. The procedure for using accounts can by default be such that a specific one will always be used, and each subsequent one will be used only when the previous one cannot ensure the payment.

Off line mode

When the buyer’s mobile phone cannot be used to conduct a transaction in real time (for example, the battery is low or the buyer has forgotten the phone at home), after the buyer’s ETA has been entered as an ETA payer into the POS terminal’s memory for conducting an off-line transaction , the terminal offers the buyer to enter the secret password of the ETA user. At the choice of the cashier, the POS terminal can send an ETA number to the Central Switch of the ETA network, receive and show on the POS terminal's personal information the owner of the ETA number, including his photo, name and other descriptive information. Further, the cashier may require the buyer to present a document proving his rights to use the ETA identifier.

The buyer enters the ETA secret code and confirms it. Password verification is carried out through the described authorization system and, if the password is correct and authorization is received, the POS terminal receives an authorization message and displays it on the display to the cashier and the buyer. The same authorization message is sent to the buyer's phone by his ETA number for further use.

Confirmation of the transaction is saved and the transaction ends.

An example of using ETA payment services by a payer

The payer selects a payment operation in the telephone interface. The payer enters the Payee's ETA into the corresponding field on the display.

The payer selects the currency and enters the value of the transaction amount and the purpose of the transaction, if necessary.

The payer confirms the payment.

The payer enters a secret password to confirm the transaction.

Payment is made after checking the password and if the password is correct.

The payer receives an authorization message from the network, and this message is shown on the display to confirm the completion of the transaction.

The recipient receives an authorization message from the network as a notification informing that his account has been credited, and also contains the authenticated ETA payer number and the purpose of the payment, if any.

The confirmation is saved and the transaction is completed.

Clearing and Authorization Procedure

Suppose financial institutions are banks.

When the Payment order is drawn up and sealed with the digital signature of the sender, it is sent by the payer to the payer's META bank. However, it may also be a payment invoice. Such a message (invoice for payment, payment order) may be sent instead to the payee, or to the payer, or to the bank of the payer or recipient, without making significant changes to the authorization and clearing of the transaction. The payer's bank authenticates the digital signature of the payer and, if it is authentic, it extracts the transaction amount and the recipient’s META / ETA, or at least the recipient’s ETA, which is further “resolved” to the full META / ETA number through the Central Switch (Switch Server) , the transaction is completed through META bank to the recipient's ETA account as described above.

Use of an existing clearing system

After receiving the Payment order, the payer's bank can authorize META through the Central Switch (CC) to, for example, the SWIFT number or other route identifier of the beneficiary's bank, and then make the payment using the appropriate international or domestic routing and clearing funds or funds from third parties. This method allows you to use the existing clearing and routing infrastructure and provides a very inexpensive implementation of the META / ETA payment method, as described.

If the existing SWIFT clearing system or another is used, then the corresponding address information of the SWIFT system or other routing and clearing system must be entered in the META File of the corresponding financial institution. During the transaction, the sender and recipient of payment instructions exchange META data taken from their own ETA Files or from their own CA or DSS. Further, the payer provides his bank META / ETA with the recipient’s route and the bank permits META through the Central Committee, receiving from the Central Committee an ordinary SWIFT number or other route identifier defined for the beneficiary’s bank. This allows the payer bank to complete the transaction with the payee bank in the usual way. In this case, the preferred execution of the system assumes that each ETA File and its copies, CA or DSS should include META as the only information for routing payments, so that the Central Committee can charge a fee for transactions, since the absence of ordinary banking details in the Recipient File will force the bank The payer should apply for them to the Central Committee for META permission in the recipient's account details. In this case, the Central Committee may charge a fee for allowing META numbers and may require each payer bank to provide the Central Committee with information about the transaction and its amount in order to set the commission value depending on the amount of the transaction.

Using the META number clearing system

When the payer's bank receives the Payment order, the bank creates its own Payment order of the bank, which is signed with its digital signature. The receipt contains at least the amount, as well as META / ETA payer and payee routes or their ETA numbers. After that, the payer's bank resolves the beneficiary's bank number in the URL of the beneficiary's bank through the META Central Bank. Then, the payer's bank creates and signs the Payment order of the sender’s bank, establishes a connection with META PKA and the payee’s bank. The parties mutually authenticate each other and the payer's bank sends the payment order to the PKA.

The PKA authorizes or rejects the payment order in the form of Authorization signed by the digital signature of the PKA. If the balance of the clearing account of the sender’s bank allows the transaction, then PKA credits the account of the beneficiary’s bank and debits the account of the sender’s bank in the amount of the transaction and commission for clearing the transaction. Authorization is sent by PKA to the address of the beneficiary's bank and the sender's bank. If authorization is granted and authentic, the beneficiary’s bank credits the beneficiary’s account, and the sender’s bank debits the sender’s account for the amount of the transaction and the corresponding commission.

ATM implementation

META can be assigned to an ATM and the “cash request” command can be received from an ATM user in order to debit money from any other network resource to which ETA is also assigned, and after authorization of the transaction by the ETA resource user, cash will be issued to the ATM user. In accordance with the foregoing POS terminal can be performed as described ATM.

An example of a cash withdrawal through an ATM in accordance with the invention may be the following:

The ATM user selects a cash withdrawal transaction using ETA;

Enters ETA from the keyboard or inserts a plastic ETA card into the ATM receiving slot for reading ETA data; the ATM asks the user to enter a password, and if authorization is received, the ATM issues cash.

The ATM can be equipped with a telephone or a videophone, providing the possibility of “live” authentication by voice and image, when the payer (the responding party) can see and speak with the recipient (connection initiator) during payment authorization, after which the recipient receives money from the ATM, if the payer authorized such an extradition. Recipient and Payer may be different persons or one person.

Business models

In the cases described above, the Authorization Center can act as a PKA for the respective registered banks, and may also have a “permit” database that establishes the compliance of each specific META with the relevant details of a certain routing and payment clearing system and information about the balance of the bank’s clearing account.

The registry for remuneration issues a META number for banks and other financial institutions, and the Central Committee charges a fee for services permitting META numbers in routing, authorization and clearing information.

The commission for conducting a transaction may have a percentage or a fixed value, or have a percentage and a fixed component of simultaneously cleared transactions (commission for one transaction and commission depending on the amount of the transaction).

The transaction fee may also depend on the distance between the payer and the payee, by analogy with the payment for long-distance and near-telephony services.

The invention contains a method for creating, issuing and managing Digital Certificates (CAs), providing for a multi-level distribution model and access to multiple accounts based on the use of a CA and Public Key Infrastructure (hereinafter PKI - Public Key Infrastructure). Various embodiments are described below, but are not intended to limit the applicability of the invention, but merely to illustrate.

Distributed certification services distribution architecture. Certification services (CA services) based on the use of a CA and PKI are widely distributed and provided by companies such as VeriSign and others. Typically, such certification service providers do not recognize CAs issued by their competitors. This leads to unjustified market segmentation and a lack of interoperability of certification services on a global scale. The latter circumstance prevents users from using certification services and, as a result, the business of Certification Authorities (CAs) suffers from insufficient penetration of the focus market.

The invention provides a method for distributing certification services through a network in which the Tier One Certification Authority is a trustee for all lower levels, and the lower levels are “reinsurers” for the upper levels with which they are associated. In FIG. 16, the lowest Tier END Certification Authority signs the DC ^END Digital Certificate for its users and accesses the higher Tier Certification Authority Center (END-1) to exchange the issued CA with a new one. CA "Tier (END-1)" uses DC ^END , signed by CA "Tier END" as a request for the issuance of a Digital Certificate (hereinafter Certificate Signature Request or CSR), and CA "Tier (END -1)" extracts data from the CA DC ^END and signs it using his Private Key ^(END-1) , thereby issuing his digital DC certificate ^(END-1) , which is then transferred to the Tier CA (END-2) and processed there in the same way as described above , and so on up the chain of the CA, when the Tier One CA is reached and the last DC ^{Tier One} Digital Certificate will be issued. The issued DC “ ^{Tier One} ” CA is then returned to the user through the chain of participating CAs or directly and placed on the user's device, placed on the card or in another way in the memory of the chip or processor, or printed on the surface or written to media in another way.

Such a distribution model is based on legally established relationships of trust between the upper and lower levels of CAs, creating conditions for acceptance by Certification Authorities of a higher level of CA issued by CAs of a lower level, and each CA issued by CAs of a lower level is perceived by each CA of a higher level as CSR for issuing CAs more high level. This model allows you to delegate responsibility for the inappropriate content of the CA to those who issued the CSR, on the basis of which the corresponding CA was issued, that is, delegate responsibility from the upper levels of the CA hierarchy, starting with “Tier One”, to the lower levels up to “Tier End”, who is responsible to the upper levels for checking user rights to use specific Resource Identifier (IR), Account Record (AP) and Encrypted Account Record (AP) in the user's CSR application. This distribution provides the necessary protection for the upper levels, protecting them from errors and deception associated with the negligence or deliberate actions of the lower levels when checking the rights of users to use specific IR, AP and ZZS.

The distribution model provides an opportunity to participate in the issuance of CAs to an unlimited number of CAs of different levels, while simultaneously allowing different CAs of each level to compete with each other. The model also provides the ability to replace CAs issued by any of the authorized CAs with CAs issued by Tier One first-level CAs, thereby guaranteeing scalable and global interoperability based on the recognition of CAs issued by a single Tier One top-level CA.

This architecture also makes it possible to replace the CA when the new Tier END (N) lower-level service provider can add the field of its services to the existing user CA and request to replace the previous CA with a new one regardless of which CA this user has applied for the release of the CA, for the first time or immediately before.

CA content

Each CA contains subject areas, and each area contains specific fields. The CA preferably uses the XML format and its subject dialects. Subject segments can be associated with communication services, personal data, financial, social, biometric, security, credit rating services and other subject areas. The subject area can also be only one.

Each area preferably contains one of the fields: Resource Identifier (TS) or Account Record (ZC) or Encrypted Account Record (ZZ) or their composition, moreover:

- AP is an account or a name, or an identifier or record of any nature, meaningful for the specific purposes of use by a service provider. AP is not encrypted. In one preferred embodiment, AP is the user's credit rating, which is based on the use of AP of the financial area of the CA. In another embodiment, the AP is the name or other identifier of the user. In another preferred embodiment, the AP can be either a route identifier or / and an account identifier, which is a complete financial account record; or a keyword or code that is meaningful to the provider of a particular type of service.

- IR is a unique alphanumeric identifier that matches a specific phone number or ENUM (http://www.ietf.org/html.charters/enum-charter.html), or ETA (Unified Telephone Address), or DNS by name, or with another known network identifier, providing network interoperability and global access for any type of network device. IR is a subspecies of the AP, it is not encrypted and is used for telecommunication purposes and authentication. IR may contain additional attached information in the form of AP or APA. The IR field can be a combined “complex” IR1 / IR2 / IRZ, thereby reflecting, for example, correspondent relations between banks. In one embodiment, IR is a route identifier and / or account identifier, which together form a complete financial account record, one or both of which can be ETA identifiers.

- ZZS is an AP that has been encrypted using the Public Key belonging to the Service Authorization Center of a particular service provider that created the CA or the service record of the CA containing the ZZS. Therefore, the ZZS can be encrypted by an unlimited number of persons and decrypted by only one Authorization Center that has a Private Key, which is a pair of the specified Public Key.

A preferred embodiment assumes that each CA is structured as shown in FIG.

In this design, each responding resource can be authenticated by the CA Header. The header is the user identifier.

Preferred execution involves the use of either only the values of the IR fields, or AP, or AP, or / and their composition for the Header field and CA areas.

ZS and ZZS are preferably used without IR, if the fields of ZS or ZZS belong to some chosen provider, whose IR is available to the user device in another way. This is usually a local or global service provider that has local, global, or standard means of access.

If AP or AP is used by a service provider that is not known by default, then the IS service provider must be specified in the IR field to provide access to its services. In the latter case, the full filling of the area will require the presence of (IR + ZS) or (IR + ZZS) or (IR + ZS + ZZS).

In a preferred embodiment, the value of the IR field is used as the access address to the gateway of the service provider, and the service provider is able to identify incoming calls by comparing the value of the CA Header of the calling resource with the accounts of the provider's internal account system. The bank’s route number (for example, META or another address) can be used as an IR service provider, and the CA Header is the account number (ETA user number or its other address), which must be mapped to the bank account identifier at the time the user sets connection to the bank's gateway using the bank’s IR address.

An APC is preferably used when the AP contains personal or other information requiring protection, such as, for example, credit card information or other sensitive information that is not intended for public distribution. Assuming that the LES is a Credit Card Record (LCC), the IR address could be the network identifier of the gateway of the Payment Authorization Center using Credit Cards or the bank that issued the card, or the gateway address of another organization associated with it. ZZS can also be a bank account, and IR in this case can be the address of the gateway to access the services of the bank. Otherwise, the ZZS may encode fingerprints or other sensitive information.

In another implementation, the record of each service provider is placed in a separate CA, and all CAs issued for a particular resource have the same CA Header value and contain the same Public Key of this resource. Therefore, each of these CAs individually can serve as a means of authenticating a resource on the network and serve narrowly targeted purposes for which such a specific CA was issued. Such CAs can be located in the subject areas of the device memory and are accessible by the name of the subject area they serve. For example, the Bank subject folder may contain all CAs related to banking services, in the BANKJNAMED folders with the names of banks, and the CARD folder for cards may contain CARD_NAMED folders with the names of specific cards, where, in turn, CAs issued by various banks and card service centers.

This design avoids the replacement of previously issued CAs when adding a new service provider, and thus makes PKI easier to implement and manage. It also allows service providers to exercise better control over their services and account information, which is part of the CA records when it is released and distributed. It also allows you to control access to each specific CA related to a specific subject area at the level of the data warehouse management system of a particular resource.

Execution of smart cards and network devices.

In this case, the implementation provides for a multi-level distribution of the CA, as described above, and allows you to use both smart cards and network devices, providing unified access to distributed transaction services provided by many service nodes of various service providers. In this design, each smart card and network device is endowed with a CA using the described certification service distribution architecture. The data of each CA is segmented, as described above, and contains fields for addressing and identification, facilitating the establishment of connections, authentication, and access to transaction services provided by various banks, organizations engaged in cash management, credit card systems, credit rating agencies, and other organizations. Services using smart cards provide the ability to securely access all financial accounts and cash management tools whose record fields are included in the financial area of the CA. Therefore, these services are independent of service providers and universal. The owner of a smart card can conduct transactions with each or at the same time with all of his accounts included in the CA through ATMs around the world, if the ATMs support work through PKI and telecommunication channels, and / or use their network device for transactions for these purposes. Preferably, the smart cards are ETA cards, and the IR field in the CA is the META address of the particular service provider. Smart cards can be cards with a magnetic stripe or any other storage medium, or a memory chip, or a processor, or a network device containing a DS.

This design provides simultaneous access to multiple accounts held in the CA through any terminal capable of using PKI. This allows you to use smart cards from ATMs and allows you to use personal communication devices as a means of universal access to all existing user accounts. With regard to financial accounts, this allows you to download and manage financial data of an account from any ATM using a smart card, and from any communication device, if the ATM and device support work through PKI. The use of multiple accounts with authentication allows you to organize a global credit rating service, which collects statistics and data on the use of accounts and provides credit ratings for the relevant users of the service. The invention allows the use of smart cards to control immigration. Examples of using smart cards:

Example 1: Assume that the value of financial field 1 (IR + ZZS) is (www.authorizationcenter.com/FREEDOM/gateway.htm + ZZKK VISA). Assume also that the RFL is encrypted with the Public Key of a specific VISA credit card payment authorization center. When the smart card is inserted into the card slot of the ATM, the ATM removes the CA of the smart card, using and checking underneath signature and using the ^{Tier One} public key. The ATM then retrieves and uses the network address www.authorization_center.com/FREEDOM/gateway.htm to establish a connection with the gateway of the Authorization Center to which the address belongs. If the connection is successful, the parties perform mutual authentication by providing their CA. During the exchange, the value of the ZZS field becomes available to the Authorization Center (CA), the ZZS is decrypted by the Authorization Center using the CA Private Key, and as a result, the CA has the decrypted VISA Credit Card Record. The Transaction is then completed by withholding the payment amount from the VISA Credit Card account in the usual way through the VISA International payment authorization infrastructure.

Example 2: Assume the value of financial field 1 (TS + TS) is (ABA 021000089+ “Name”). In this case, ABA021000089 (numbering of the American Banking Association American Bank Association) is the routing number of Citibank in the federal payment system FedWire. Therefore, operations on a specific account are possible after connecting to ABA 021000089, mutual authentication and searching for an account with the name “Name” in the internal system of accounts of CitiBank. If the corresponding internal account is found, then the user of the smart card will be granted access to the account.

Example 3: Suppose the value of financial field 1 (TS) is ETA (+ 1-212-123-4567), which is the telephone gateway of the bank. When the smart card is inserted into the card acceptor of the ATM and this IR address is extracted by the ATM from the CA card, the ATM gets access to the bank by establishing a connection using the specified phone number, and after mutual authentication of the parties between the smart card and the bank, the latter retrieves the CA Header and looks for it in the internal system of accounts. If an account corresponding to the CA Title is found, then the bank provides access to the found account.

Example 4: Suppose a cardholder applies to a bank for a loan; Assume also that the value of financial field 1 (IR) is ETA (+ 1-212-123-4567), which belongs to the telephone line of the Credit Rating Agency (ACP). When a smart card is inserted into the reader's smart card card reader and the IR address is read from the CA, the reader establishes a connection with the ACP using the ETA number, and after mutual authentication between the smart card and the ACP, the last one extracts the CA Title from the CA card and looks for the corresponding account title in the internal system ACP accounts. If the corresponding account is found, then AKP provides the card reader with the credit rating data of the found account; the received credit rating is taken into account by the lending bank and, based on the received value of the Credit rating of the smart card holder, a decision is made on lending to the owner or refusal to issue a loan.

Example 5: Assume that the value of financial field 1 (TS) is ETA (+ 1-212-123-4567), which is the number of the telephone gateway of the Department of Issuing Entry Visas. When a smart card is inserted into the card reader of the border passport and visa control reader and the value of the Department’s gateway address is read from the TS field’s IR, the reader establishes a connection with the Department’s gateway using the number + 1-212-123-4567, and after mutual authentication between the card and the Department the latter retrieves the CA Title and looks for it in the Department’s internal visa database and, if the card holder has a valid and unexpired entry visa, the card holder is given the opportunity to cross the ANRITSU and enter the country.

Example 6: Suppose the value of financial field 1 is ETA (+ 1-212-123-4567), the value of financial field 2 is (+ 1-303-123-4567), and .... the value of financial field N is (+ 1-512-123-4567 + ЗЗЗ), moreover, field 1 and field 2 contain access numbers to bank gateways and field N is the telephone number of access to the VISA credit card authorization center gateway, and the ЗЗС in field N represents an Encrypted Credit Card Record VISA When a smart card is inserted into the card acceptor of the ATM, the IR addresses are extracted by the ATM from the fields 1, 2, ... N of the Digital Certificate, after which the ATM establishes communication with the bank gateways and the VISA CA using the appropriate IR addresses for access to the gateways. After mutual authentication with each of the banks and VISA CA, each bank looks for a CA Header in the internal systems of bank accounts, and VISA CA decrypts the ZZS using its own Private Key, and thus receives the corresponding VISA credit card account. If the accounts matching the CA Header are found, and the VISA CCC exists and is valid, then the ATM displays for the smart card user the balance information for each bank account and VISA card account and allows you to conduct a transaction through any of the accounts in accordance with the rules of the respective bank and cardholder privileges.

Using network devices

The procedures for access, authentication and authorization using network devices are similar to procedures using a smart card and ATM or smart card reader, which act as a network device in the above examples. In this case, instead of the CA of the card, the CA of the network device (network resource) can be used, and instead of the ATM or reader cards, the network device or resource itself is used, which establishes a connection with the gateways of banks and authorization centers using IR identifiers of these gateways.

Business models

The business model involves the sale of the CA itself and the services for its release. The model also involves the sale of a replacement CA.

In the context of the foregoing, the present invention provides an Internet Settlement Architecture (APRI), which may be implemented as described below.

Internet Settlement Architecture (APRI)

Payment Nodes (PU). Payment nodes are nodes (resources) of the network, and the network address (identifier) of each PU is used as the identifier of the account corresponding to the PU. With respect to the payment itself, each payment system can be either one of the Payer nodes, or Intermediary nodes, or nodes - Payees. Each PU has a unique network address associated with the PU; the network address may be in the format of a telephone number and may be ETA or ENUM, or be www or an e-mail address (e-mail), or any other relevant network address that can be resolved using the means of resolving network addresses to the corresponding network address of the Main Clearing Organization or JCE (i.e., the Clearing Organization, which is used by default). Each PU can be both a calling resource and a responding resource in the process of making a payment, with the Calling node being the Payer at the same time, and the Answering node being the Recipient when making Atomic payments. The calling UC can be both the Payer and the Intermediary in conducting the “End-to-End” Payment (hereinafter referred to as the EEP), and the Recipient can act as the Intermediary or Recipient of the EEP.

ETA.

In the context of APRI, ETA is understood as a Single Transactional Address. ETA is a unique identifier for a resource. ETA matches one of the network identifiers, such as a phone number, www address, email address, IP or other unique network address, or a name in natural language. ETA matches or is associated with the identifier of the transactional account of the resource.

Atomic Payment (AP). Atomic Payment is executed as a point-to-point telecommunication connection, that is, it is a transactional connection (hereinafter referred to as transactional call or t-call). A T-call is a point-to-point connection in which a transaction instruction is created by the calling resource in the form of a network connection using a parametric string in namespace string notation (that is, a string containing the ETA address of the Responding resource and a payment instruction containing specific parameters payment and digital signature of the calling resource. Further, for definiteness, we will talk about a transaction as a payment, although it can be a transaction of any other kind. For simplicity, we will also assume that the payment instruction is part of the URN namespace (for example, the ETA namespace), and the payment instruction is located behind the question mark - "?" in the URN, namespace notation (discussed in the example below). The preferred T-CA11 string format in the described case uses the format described as URN Syntax in RFC 2141 and RFC 2396, and can follow the approach outlined in "Resolution of URIs Using the DNS" (RFC 2168), "Architectural Principles of Uniform Resource Name Resolution "(RFC 2276),“ DDDS and Namespace Definition Mechanisms implementations ”(RFC 3401, 3402, 3403, 3404, 3405, 3406). However, despite the requirements set forth in the RFCs mentioned above for simplicity, we will not follow the URL Syntax requirements in the examples below. We also will not specify ports, thereby simplifying the syntax of the namespace, although different ports can be used to separate network connections transmitted for the purpose of transmitting payment instructions from, for example, network calls transmitted for the purpose of navigating the Internet, since the use of the same namespace , but different ports simplifies the separation of data streams intended for payment applications and applications that provide Internet navigation, but in this case makes it difficult to understand the meaning of the proposal invention. For vending machines, using ports in the notation would mean using the same DNS address and, for example, port 80 for accessing the Internet server of the vending machine to view available drinks, for example port 88 for paying for purchased drinks using the vending machine in question.

Regarding the namespace and its administrative domain (meaning authoritative domains, that is, a domain that has administrative rights over the set of domain names of its own zone of ownership), using the analogy with DNS, Atomic payment can be either going back to the root domain (top-level domain ) or downstream to hosts (lower-level domains) inside the authority zone of the current domain.

For payment transactions, the connection parameters can be the amount, value of the payment currency, purpose of payment, and so on. The parameters may also contain the identifier of the clearing method (such as, for example, real-time or offline clearing) and other preferences of the Calling resource in the form of a namespace:

PAYEE_UTA? PAR_1 = VAL1 & PAR_2 = VAL2 & ....... / PAYER_UTA / PAYER_DIG_SIGNATURE.

The content of the payment, for example, for foreign Recipients, the payment method can also be determined, for example, using SWIFT instead of the local settlement bank or clearing house.

For example:

THE DEFAULT CLEARING.com?payee.com/credit/USD/1000/ON/payer.com/Kjnkethab kjdlkcmncv

In the above example:

THE DEFAULT CLEARING.com is an OKO identifier

payee. com is an ETA Recipient identifier (at the same time network address and account identifier)

Credit - means the operation of crediting the account of the Recipient

US - means the currency of payment (US dollars)

1000 - is the amount of payment

ON - means the requirement to clear the operation in real time

payer.com - is an ETA Payer identifier (at the same time network address and account identifier)

Kjnkethabkjdikcmncv - is the intended digital signature of the Payer.

Another example:

credit.THE DEFAULT CLEARING.com?+l-('212H23-4567/USD/1000/+l-(202H23-4567/Kj nkethabkj dikcmncv

in him:

+ 1- (212) -123-4567 is the ETA of the Recipient (telephone number or ENUM) and

+ 1- (202) -123-45b7 is the Payer's ETA identifier (phone number or ENUM).

In the future, we will call the "t-call string" the following notation of the payment instruction:

credit.THE DEFAULT CLEARING.com?payee.com/USD/1000/ON/payer.com/Kjnkethabkjdl kcmncv.

End-to-End Payment (CES). ЕЕП is a payment starting on the resource of the Payer and ending on the resource of the Recipient. The CES can be an Atomic payment, but it is usually understood as a chain of consecutive payments in which the resources of the Payer, Recipient and Intermediaries are involved. The CES flows through the chain of Intermediary resources from the Payer to the Recipient in the form of a sequence of Atomic payments implemented as a chain of t-call point-to-point connections. For each Atomic payment, both resources (nodes) that are parties to the payment must support a trust relationship architecture (that is, use PKI) to enable mutual authentication of the parties to the Atomic payment.

Client. The Client’s resource (node) is a resource, which is the lowest hierarchy level in the multi-level clearing infrastructure, and therefore the Client has only one connection with the parent clearing levels and has no child links. Since the Client does not manage its own Clearing Domain, the client authorization database does not contain any ETA client identifiers and only contains the ETA identifiers of the parent clearing domains. Therefore, all ETAs indicated in the t-call connection of the client are always mapped to the ETA identifier owned by the JCE for any specific ETA identifier of the Called Resource account and then the Client establishes a t-call connection using the corresponding ETA identifier from the JCE.

Clearing Organizations (KOs). Clearing Organizations are clearing and routing organizations for making payments. COs usually serve as Intermediaries during the CES, but can also act as a client, being a resource Payer or Recipient of the CES. In the sense of providing transactional communication services (referring to the scope of transactional telecommunications), each TO is understood as a Switch - a namespace domain that contains a database of address information for ETA identifiers belonging to subsidiary TO and client resources (hosts in the analogy of DNS) for which the current TO is an OKO. As described, the distributed architecture of DNS servers provides services for resolving DNS names into IP addresses, in which the parent DNS server (authoritative DNS server) holds address information for resources registered in the zone of responsibility (meaning “zone of authority”) of this DNS server.

Each JCE can be a subsidiary QoS resource for its respective top-level maternal QoSs, such as Settlement and Clearing Chambers, correspondent banks, and so on, and the subsidiary QoS, as a client for the parent QoS, must use the parent QoS and support communication and clearing methods specific to for this JCE.

MOKO. Each lower-level QoS can, by default, use the services of a specific upper-level QoS, which is therefore the Maternal JCE (MCO).

EYE. Each client resource uses at least one Primary QA (OKO), however, the client can be an account holder (host) for several OKOs (namespace domains) at the same time.

Clearing Infrastructure.

Fig. 18 illustrates a multi-level structure of clearing relationships between participants in name resolution and clearing operations, where

⇒ Client # 1 is the owner of an account in one bank CF # 1, located in the USA; CF # 1 is the Client JCE (COCO) for Client # 1.

⇒ Client # 2 is the owner of an account with CF # 3 bank located in Russia; CF # 3 is COCO for Client Client # 2.

⇒ Client # 3 is the owner of an account with CF # 4 bank located in Russia; CF # 4 and CF # 5 are COCO for Client Client # 3.

⇒ CF # 1 is a bank located in the USA; SWIFT and the American Bank Association (ABA) are MCOs for CF # 1 and have various clearing methods.

⇒ CF # 2 is the international clearing network SWIFT; CF # 1, CF # 3, and CF # 5 are subsidiaries of SWIFTs, and SWIFT, in turn, is MOCO for each of them.

⇒ CF # 3 is a Russian bank; SWIFT is MOCO for CF # 3.

⇒ CF # 4 is a Russian bank; CF # 3 is MOCO (Correspondent Bank) for CF # 4.

=> CF # 5 is a Russian bank; SWIFT and CF # 7 are MOCO for CF # 5.

⇒ CF # 6 is the clearing house of the American Banking Association ABA; CF # 1 and CF # 7 are affiliated to the ABA Clearing Domain.

⇒ CF # 7 is a bank located in the USA; ABA is MOCO for CF # 7.

Fig. 18 shows that Client # 1 can transfer money (make a payment) to Client # 2 using a single route:

(Client # 1 → CF # 1 → CF # 2 → CF # 3 → Client # 2).

If Client # 1 would like to transfer money to Client # 3, it could use one of the alternative routes:

(Client # 1 → CF # 1 → CF # 2 → CF # 3 → CF # 4 → Client # 3) or

(Client # → CF # 1 → CF # 2 → CF # 5 → Client # 3) or

(Client # 1 → CF # 1 → CF # 6 → CF # 7 → CF # 5 → Client # 3).

When conducting operations in accordance with the present invention, APRI may support, for example, the principles set forth in the “Architectural Principles of Uniform Resource Name Resolution” (RFC 2276) or similar, moreover, the network addresses may coincide with the identifiers of the accounts.

Clearing Cycle. The clearing cycle is an Atomic payment procedure executed by one KO. Each KO carries out settlements on atomic payments in accordance with certain arrangements for their implementation, such as a requirement for a positive balance or a requirement for the amount of balances on a client's account or other clearing rules. The clearing cycle contains, as a step, the Address Resolution Cycle, which is an important part of the Clearing Cycle. During the CO Clearing Cycle:

⇒ Receives t-calls from Calling resources (from own clients or subsidiaries),

⇒ Authenticates the Calling Resource by its ETA identifier and digital signature,

⇒ Checks compliance of payment parameters with the current requirements of the payment syntax and other conditions and, if the requirements of the rules are met, produces

○ Resolution cycle. The QO permits the ETA of the Recipient to the ETA identifier of the Next Qo (RMS), which is either the JCE for the Recipient or the MCO for the current Qo.

⇒ Debits the client's account and credits the RMS account within the current clearing domain.

⇒ Creates a string for a t-call call, such as, for example, credit-NEXT_DEFAULT_CLEARING.com7pavee.com/USD/1000/ON/paver.com, in which NEXT_DEFAULT_CLEARING.com is the address for establishing a network connection, and the rest is a copy of the string source t-call connection without digital signature.

⇒ Signs with his own digital signature t-call parameters line of the call credit.NEXT_DEFAULT_CLEARING.com7pavee.com/USD/1000/ON/paver.com/digital_signature_of_CURRENT_CF.

⇒ Establishes a connection with the JCE using the generated t-call call string.

The next clearing cycle uses the clearing rules again and creates the next t-call line, as described above, and so on, until the payment reaches the account of the Payee.

QA database for name resolution loops. Each CO is an Account Domain Administrator (similar to the DNS Name Domain Administrator) and maintains a namespace resolution database in the “zone of authority” of its Clearing Domain. For example, each bank is a namespace clearing domain for accounts of its own clients (similar to hosts for the DNS system), as well as for other banks (similar to sub domain namespace servers in the DNS analogy), which use the bank in question as a correspondent bank to gain access to the services of the parent clearing organization of the bank in question In the latter case, the Russian bank may have a correspondent account with an American bank in order to gain access to the payment system FedWire for clearing payments of banks that are members of the American Bank Association.

The domain database of a specific “administration zone” establishes the correspondence between ETA identifiers of IDs registered in the zone of called META resources. The database of the “administration zone” allows ETA identifiers of called resources to the corresponding OKA META identifiers located in the “administration zone” or allows the identifiers of the subsidiary or parent OKO in META in the same way as the IN-ADDR.ARPA domain is organized on the Internet (see . RFC 1033) and matching matches in its reverse addressing database (see RFC 1034 “Name Server Algorithm” for an example of execution). If the Called ETA cannot be resolved inside the current clearing domain into the JCE identifier (i.e., the search result of the corresponding JCE identifier is negative), then the ETA identifier of the called resource must be enabled by default in the ETA identifier of the ICCO (root namespace server) of the current KO, respectively, with a certain for the parent domain by the payment method. Table 8 shows a simplified example of a database table that performs the resolution <ETA called + method> → <ETA OKO>.

Each KO must contain an authorization database in which each ETA client identifier is assigned a set of ETAs of its OKOs different in the clearing method used, and all ETAs not owned by clients will be allowed in the ETA of the ICCO using the specified clearing method. The clearing method is a parameter in the T-CA11 line, providing a resolution that results in a unique ETA identifier of the OKO or MKO for each unique pair “unique ETA + unique method”. In a database using only one default method, each unique ETA will have a unique unique ETA as the resolution result if the ETA of the called resource is contained in the admin area of the current domain, or will be resolved in the IOCS ETA of the current domain if the ETA of the calling resource is not has a match in the permit database.

Table 8 shows the table of the clearing authorization database, where the ETA of each called resource will be allowed for subsidiary QoS and clients in the JCE taking into account the clearing method, and for all ETA resources that are not clients of the current Qo ETA resources, it will be resolved to a specific ETA of the ICO of the current Qo subject to the specified clearing method. Many clearing methods can be supported, for example, as used for Address-family identifiers (AFIs) for RIP 2 (RFC 1723) or using other known techniques.

Table 8 Inquiry Called up
ETA1 ETA2 Called Called ETA3 ... Called ETAN Any ETA that is not a client or domain of a subsidiary KO Method one 2 7 3 ... N L one 2 3 ... TO Answer OKA ETA1 OKA ETA2 OKA ETA7 OKA ETA3 ... JCE ETAN OKO BTAL MOKO ETA1 MOKO ETA2 MOKO ETA3 ... MOCO ETAC

Using the previous example with Russian, American banks and ABA, the Russian bank only allows ETA identifiers of its customers, and the American bank allows ETA identifiers of its clients and Russian bank clients at the same time, and the ABA clearing database should allow ETA of all clients of both Russian and and American banks. Such an example of resolution is somewhat artificial and in the real world, namespaces are hierarchical and use country and region codes for phone numbers and domain notations for the Internet domain namespace for unambiguous routing of connections.

Since a significant number of Internet URLs and phone numbers are occupied and are no longer available to new Registrants for use, it seems difficult to build a hierarchical namespace for the clearing infrastructure using existing global Internet domains, as well as existing country and region codes for phone numbers. Therefore, it seems useful to create for the clearing infrastructure new URN namespaces: <NID> <NSS> described in RFC 2276 and RFC 3401-3406, or new global Internet domains, such as PAY and Zero ETA (NO) numbers for telephony:

NO: + 0- (123) -123 4567, or + 7- (000) -123-4567, or + 7- (095) -0123456 DNS: 70950123456.PAY

Another implementation for the Internet can be the conversion of NETA identifiers into URN notation, for which, in the URN notation: <NID> <NSS>, the assumed "PAY" domain should become the value of the NID field (namespace ID), and the NETA identifier together with the payment instruction should become the value NSS (Namespace Specific String) in URN notation.

An example of a hierarchical clearing infrastructure based on NETA is shown in FIG.

To convert (for subsequent resolution) the NETA hierarchy to the DNS hierarchy, the Algorithm described in RFC 3402 or another known or new technique can be applied. As an illustration, distributed below, some types of conversions of phone numbers to the notation of DNS, ENUM and other URN names are given:

+ 7- (095) -123-4567 → 70951234567.pay

+ 7- (095) -123-4567 → 7095234567.us.pav

+ 7- (095) -123-4567 → 1234567.washington.us.pav

+ 7- (095) -123-4567 → 1234567.095.7.rau

+ 7- (095) -123-4567 → 4567.AT & T.washmgton.us.pav

+ 7- (095) -123-4567 → 7.6.5.4.3.2.1.0.9.5.7.ABCD.arpa

+ 7- (095) -123-4567 → tel: +70951234567

+ 7- (095) -123-4567 → 70951234567.UTAresolution.com

+ 7- (095) -123-4567 → UTAresolution.com? 70951234567

Another conversion to DNS names might look like this:

+ 7- (095) -123-4567 → 70951234567.12020000001.10000000001.00000000001.com.

+ 7- (095) -123-4567 → 70951234567 (a.bank.clearmghouse.com

and so on.

Fig. 20 shows the same clearing infrastructure as in Fig. 19, where it is assumed that NETs are mapped to a DNS name in the intended domain. RAU DNS in which there are also subdomains US and RU related to the USA and Russia and resolved in a descending order in the intended domain. PAY

Another technique could use a new protocol, for example, some fictitious HTTPSP protocol - "hyper text transfer secure payment protocol", which could be based on the use of the standard HTTPS protocol and is suitable for transferring payment instructions, name resolution and clearing.

Another approach could be to use standard Internet transport (IP) along with a special distributed domain system using DNS and PKI technology, in which all domain owners would be Clearing Organizations (KOs), and the domain system would contain a non-DNS → IP translation table, and from the conversion NETA → IP or DNS → IP, or e-mail → IP, or “Name in natural language” → IP and so on. Being a standalone system based on DNS and PKI technology, the latter solution may be the least costly to implement and the most secure.

To resolve ETA identifiers with separation depending on the clearing method, the resolution database can be executed as a DDDS DNS database in accordance with RFC 3403, using the ORDER and PREF fields to determine the clearing method for determining the clearing priorities. The QoS database in this case can use the DDDS Algorithm described in RFC 3402, in which the First Known Rule (translation of the name “First Well Known Rule”) could be the rule for processing the t-call string, and Clearing and Name Resolution can be performed using the DDDS rules of the database and controlled by “keys” (the so-called “keys”), as described in RFC 3402, and “keys” can be given as values of the parameters of the t-call call string.

Notwithstanding the foregoing, a more practical way could be to use existing DNS namespaces as clearing, for example, Client # 3 (see FIG. 18) could have 3 DNS names defining 3 alternative clearing routes. Assuming CF # 6 is the CF # 6.com domain, CF # 5 is the CF5.com domain and CF # 2 is the CF2.com domain, the clear route could be written in DNS notation of names as follows:

Client3.CF4.CF3.CF2.com for (Client # l → CF # 1 → CF # 2 → CF # 3 → CF # 4 → Client # 3)

Client3.CF5.CF2.com for (Client # l → CF # 1 → CF # 2 → CF # 5 → Client # 3)

Client3.CF5.CF7.CF6.com for (Client # l → CF # 1 → CF # 6 → CF # 7 → CF # 5 → Client # 3).

In the last ETA example, the Client ID of Client # 3 matches three URLs for Client3.CF4.CF3.CF2.com. Client3.CF5.CF2.com and Client3.CF5.CF7.CF6.com inside CF2.com, and CF6.com clearing domains.

Permission cycle. A resolution cycle is a search operation in a clearing database that implements routing of atomic payments.

Permit service. The authorization service refers only to the routing of EEA payments and is implemented as a chain of successive “authorization cycles” - searches in the database of the Domain Name System of Clearing Organizations, as described in RFC 1035, 1034 and 3403 of the network address corresponding to the ETA identifier of the Atomic Payment Recipient. Similarly, in the implementation of the DNS system, the domain of each Credit Organization becomes its “zone of administration” for all its customers and subsidiaries.

Each Recipient identifier can be resolved into the network identifier of its OKO, and the OKO is the “administration zone" of the domain for the Recipient ID, which is therefore a subdomain identifier or host identifier in this case. For example, the Recipient’s identifier = + 1- (212) -123-45b7 may correspond to its OKO identifier = 12121234567.citibank.com, and Citibank-com is the parent domain for the Recipient. This method allows you to seamlessly route t-call calls to transactions through the OKO circuit connecting the Calling and Answering resources. Each of the JCEs may be a bank or a Processing Center for processing credit card payments or a Settlement Center or other clearing organization.

Implementation of search services KO. RIP-2 (Routing Information Protocol), described in RFC 1723, or another similar technique, can be used to detect and investigate a transaction clearing route.

As a route search command, the Tracert command described in the TCP / IP protocol can be used, or a similar command can be used for wired and wireless communication networks.

Below is an example of the result of the "tracert" command:

C: \> tracert www.multilex.ru

Tracing route to multilex.ru [212.24.32.169]

over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms gate.medialingua.ru [192.168.1.3]

2 1ms 1ms lms62.118.27.65

3 20ms 21ms 21 ms 10.4.255.100

4 123ms 211ms 131 ms spd-gw-GE-0-l-20.mtu.ru [195.34.53.97]

5 22ms 21ms 25 ms PTT-Pex.core.mtu.ru [195.34.53.65]

6 22ms 23ms 23ms Pex-M9.core.mtu.ru [195.34.53.10]

7 44ms 43ms 42 ms s-b3-pos0-2.telia.net [213.248.101.57]

8 45ms 45ms 45 ms teliasonera-01843-s-b3.c.telia.net [213.248.78.250]

9 68ms 73ms 75 ms mowl-000.sonera.ru [217.74.128.122]

10 75ms 73ms 74ms vlan30-ge5-l.m9-3.caravan.ru [217.74.128.126]

11 77ms 71ms 77ms vlan615-ge0-0-10.office-l.caravan.ru [217.23.151.78]

…………………………………………

C: \>

As can be seen from the above example, the "tracert" command allows you to find the physical route connecting the Calling and Responding nodes (resources) of the network, including all intermediary resources. The use of such a communication search method for the Architecture of Conducting Settlements via the Internet (APRI) allows us to implement the search services of the payment route.

The search for Clearing Organizations and the search for a route with cost optimization for clearing the CES are considered in the example "Optimization of the clearing route for cost." The Usage Examples section below.

Certification Services. PKI can be used to establish trust relationships between APRI nodes. Each resource can be endowed with a Digital Certificate (CA) containing at least the payment attributes of the resource, as described in RFC 3281. Payment Attributes must include at least two -ETA, that is, the Certified Identifier ETA of the resource and ETA identifier of the Main Clearing Organization specified resource. This method of Digital Certification of routing information provides routing information for placement in the Route Database of the Clearing Organization.

Illustrating the contents of the CA, again using the DNS analogy, such authenticated payment attributes could include information from the entire set of DNS Resource Records contained in the DNS name server master file, or some important part of the display value range (see RFC 1034). After being extracted from the CA and placed in the master zone of the DNS zone, the certified information of the Resource Records will provide reliable DNS resolution services. The compilation of Digital Certificates with a DNS system, for example, is proposed in RFC 2538 "Storing Certificates in the Domain Name System (DNS)" and can be used to create an authenticated DNS database when creating APRI. The specified RFC also provides for the possibility of access to the Public Key of the corresponding resource, creating the necessary conditions for the use of a digital signature and encryption of the t-call string.

The network can use a single root Certification Authority (CA) or several Root CAs, whose certification services can be mutually recognized as valid due to the conclusion of an agreement aimed at supporting cross-operations. Although the architecture under consideration allows the use of many root CAs, some resources, such as mobile phones and other small devices, may not have enough space to store multiple CAs or may not support working with multiple root CAs; therefore, such nodes can use the services of only one root CA , whose services are recognized by all other CAs by agreement of mutual trust. Nevertheless, in some cases, the number of useful trusted CAs may be limited to one CA.

Confidentiality Aspects. Secrecy is solved by using PKI for the Clearing Network as a secure communication network of Electronic Funds Transfer (EFT) and distributed in a secure network of the Clearing Database as described here. Each Clearing Database is a secure network database accessible only to clearing members. Digital Certificates and PKI can be used as a source of reliable information for mapping multiple ETA identifiers of calling resources into a variety of routing information to their accounts, creating conditions of trust and security when providing resolution and clearing services.

Examples of using

An example implementation of an Allow DNS database.

Case 1

Separate APRI can be performed using existing software implementations of DNS resolvers and DNS name servers, as well as using existing protocols, including UDP and TCP / IP. Such DNS software could display and resolve not only DNS addresses, but also any other network address in the IP address, providing various services, as proposed in RFC 3403. Due to this, each ETA identifier of the called resource can be resolved to its corresponding IP address OKO , and for non-customers their ETA identifiers can be resolved in the name of the DNS server of the Maternal QoS, while the DNS system can use the OKO matins domain as the “root” domain and allow all non-client ETA identifiers through non go or using a multi-level resolution model.

RFC 1034, 1035 and 1183 in some part can be used for this design. The ETA resolution of the identifier in the domain name (see “An example of a lending transaction” that explains the permission of payer.com → payer.payerbank.com) in this case can be executed using the INN-ADDR.ARPA domain to search by IP address or using DDDS to search other types of ETA identifiers.

In the case of DDDS execution, the result of the ETA permission of the identifier "rauee.com" may look like this:

rauee.com.

;; order pref flags service regexp replacement

INNAPTR100 50 "a" "httpsp + N2T" "" ray.com

INNAPTR100 50 "a" "https + N2R" "" payee.payeebank.clearing.com.

INNAPTR100 60 "a" "https + N2R" "" payee.payeebankl.clearing 1.com.

INNAPTR100 70 "a" "https + N2R" "" oayee.payeebank2.clearing2.clearing3.com.

INNAPTR100 70 "a" "http + N2B" "" billing.payee.com.

INNAPTR100 50 "a" "wap + N2V" "" wap.payee.com

IN NAPTR 100 80 "a" "sip + N2V" "" payee.com (% sip. Someservice.com

INNAPTR100 80 "a" "http + N2IP" "" 213.248.101.57,

where the service "https + N2T" means "name-to-trace" estimates of the cost of the payment route using the proposed HTTPSP protocol; and the three services “https + N2R” mean “name-to-route” providing alternative clearing domains with preference ranks of 50, 60 and 70 for payment routing; and the last service is "http + N2V", for viewing the contents of the WAP server of the Payee describing the provision of services or consumer products.

Using DDDS, it becomes possible to trace routes using each of the ETA Payer and Recipient identifiers as a request to search for “https + N2R” routing services in the DNS database and comparing the results to search for matching QO domains in them, and when the same Qo domains are found , it becomes possible to request from them the cost and duration of the transaction clearing for the purpose of optimizing the transaction.

Case 2

Suppose that the DDDS DNS database uses NAPRT resource records, allowing you to resolve the address of each payment node to its corresponding JCE address. Suppose also that some Payee recipient (payee.corn) has an account with PayeeBank (PEBank.com) and some Payer (payer.com) has an account with PayerBank (PRBank.com) .

We also accept that the t-call call contains the string "? Payee.com/credit/USD/1000/PayerDigSign". Assume that the Application Unique String or “AUS” described in RFC 3402 is obtained by the application during t-call processing by extracting text placed between the '?' and the first character '/' (First Known Rule, as described in RFC 3402), and a query to the DNS DDDS database is made using the extracted text. In our case, the query will be the substring “rauee.com”.

The result of resolving the DDDS string “Rauee.com” could be this:

Rauee.com

;; order pref flags service regexp replacement IN NAPRT 100 10 "" X2Y "" PEBank.com

Now the application changes the previous AUS value by adding the “payee” value to the search result and rewrites the AUS string into the Payee.PEBank.com string, and the Application searches the database for the string “Payee.PEBank.com”, which the database allows to write :

Payee.PEBank.com

;; order pref flags service regexp replacement

INNAPRT10010 "p" X2Y "" payee.PEbank.DCFl.com

Such an implementation allows sequentially resolving the identifier “payer.com” to the route “payer.PRBank.com” and further to “payer.PRBank.DCFl.com”, and the DNS name received “payee.PEbank.DCFl.com” is final (about this is indicated by the flag “P”) and the Application finishes resolving the name “rauee.ot” by returning the string “payee.PEBank.DCFl.com” as the complete payment clearing route for the Recipient. Domain. COM is not clearing in this example.

The same resolution of the Payer identifier would give consistent results:

Payer.com

;; order pref flags service regexp replacement INNAPRT10010 "" X2Y "" payer.PRBank.com

payer.PRBank.com

;; order pref flags service regexp replacement INNAPRT10010 "p" X2Y "" payer.PRBank.DCFl.com.

The application compares the final clearing routes for the Recipient Rauee.com → PEBank.com; Payee.com → PEBank.com → DCFl.com and Payer Payer, com → PRBank. com; Payer.com → PRBank.com → DCF1.corn in order to find the Route Turn Point (TPM), that is, the first domain name on the left, contained and matching in the Recipient and Payer routes, and this is the clearing domain DCF1 in our case. Both end routes are compared in order to find a matching link, and such a link is considered a Route Turn Point, in which the route becomes from an upward clearing to a downward clearing. Obviously, the clearing route of the Payer-Recipient payment will be Payer.com → PRBank.com → DCFl.com → PEBank.com → Payee.com, and DCF1 is the Turning Point of the Route.

There may be more than one Waypoint for each pair of Payer and Recipient.

Case of providing route search services

Suppose that the Payer and Payee identifiers of the Recipient can be allowed in ETA clearing route identifiers:

Payer

;; order pref flags service regexp replacement

IN NAPTR 100 50 "a" "http + N2T" "" paver.com

INNAPTR100 60 "a" "https + N2R" "" Daver.FOObank.ROOclearing.com.

IN NAPTR 100 50 "a" "https + N2R" "" pavee.GObank.REclearing.com.

and

Payee

;; order pref flags service regexp replacement

INNAPTR100 50 "a" "http + N2T" "" pavee.com

INNAPTR100 50 "a" "https + N2R" "" pavee.ZOObank.ROOclearing.com.

INNAPTR100 60 "a" "https + N2R" "" pavee.GObank.TOclearing.com.

Comparing the results of resolving the “Payee” and “Payer” identifiers for N2R (Name-to-Route) services, we find that the payment can be made using one of two independent routes, namely through the GObank, in which they have accounts and the Payer and the Beneficiary, OR through the ROOclearing Clearing Organization, where there is a correspondent account of the Beneficiary's bank “ZOObank” and the correspondent account of the Payer's bank “FOObank”.

Payer → GObank → Payee Payer → FOObank → ROOclearing → ZOObank → Payee

If Payer wishes to pay from his account at FOObank (this account has a higher priority value in the “pref” field of the NAPTR record), then he must use the second clearing route via ROOclering:

Payer → FOObank → ROOclearmg → ZOObank → Payee.

At the same time, the technique “Optimization of the Clearing Route by Cost” shown in the example below can be used to select the optimal clearing route, which allows real-time assessment of the cost / due date of a payment taking into account the preferences of the Payer.

An example of a lending transaction.

Assume that the APRI infrastructure includes the Recipient, the Recipient's Bank, the Payer, the Payer's Bank and the Automated Clearing House (ACP) “www.CHIPS.com”, shown in Fig. 18. Both banks and ACPs are Clearing Organizations for their own customers, each bank being a Clearing and Routing Organization for its end customers, and AKP is a Clearing and Routing Organization for both banks that are members (clients) of ACP. Assume also that the resolution services are provided by the DNS database in which the ETA of the called resource is displayed in the ETA of the Main Clearing Organization of the called resource. ETA can be either a phone number, a DNS name or IP address, or any other network address or name.

Imagine that the Payer is a web site with the address www.payer.com, and the Recipient is a mobile phone user in the United States, with the number + 1- (212) -123-4567, and has an account with www.TargetBank.com.

As shown in Fig. 21, the task is to transfer payment means from the account www.payer.com to the account + 1- (212) -123-45b7 in the bank www.TargetBank.com;

Payment procedure:

1. payer.com creates t-call 1: credit.PayerBank.com?paver.com/USD/1000/CHIPS/+l-(212)-123-4567/DigitalSignatureOFwww.payer.com;

2. www.payer.com establishes a network connection using the t-call 1 string formatted in accordance with the network rules, for example following Syntax RFC 2396, RFC 3406.

3. www.payerbank.com receives a t-call 1 call and applies the First Known Rule to the call line, then the Payer's bank clears, searches and resolves the Recipient ID using parameters taken from the t-call 1 line as “keys” of the algorithm described in RFC 3402. Since the Recipient's account + 1- (212) -123-45b7 is located outside the clearing domain www.payerbank.com, the result of the resolution will be empty (DNS resolution error), therefore, the result of the search for the Clearing Organization should be the value of the Main Clearing Organization Top Level indicated oh as "THE_UPPER_TIER_DEFAULD_CLEARING_FACILITY" or, for brevity, "UTDCF", which may be one of the chambers clearing SWIFT, ABA or CHIPS, www.payerbank.com bank used as the JCE motherboard. Of these, the CHIPS chamber should be selected, since the name “CHIPS” was indicated as a parameter in the t-call I.

4. bank www.payerbank.com creates a t-call 2 line in the form of credit.chips.com?paverbank.com/payer.com/USD/1000/ON/+1 - (212) -123-4567 / DigitalSignatureOFwww.payerbank .com. It is worth noting that the www.payer.com notation itself can be reversed by using the INN-ADDR operation at payer.paverbank.com inside www.paverbank.com since www.paver.com is the host within the clearing domain www. payerbank.com Payer Bank.

5. Payer Bank www.payerbank.com establishes a network connection using the t-call 2 call string formatted in accordance with the network rules, such as Syntax RFC 2396 and RFC 3406 for example.

6. Automatic transmission www.CHIPS.com receives a t-call 2 call and applies the procedure for extracting parameters, searching and resolving names to the call line. As a result, the identifier + 1- (212) -123-45b7 is resolved to the identifier 12121234567.TargetBank.chips.com, since the Beneficiary's bank is a subdomain inside the CHIPS ACP, and the Beneficiary is a host within the domain of the Beneficiary's bank. The “ON” parameter indicates the real-time mode of clearing execution and transaction notification.

7. Automatic transmission www.CHIPS.com creates a t-call 5 call line in the format credit.TargetBank.com?chips.com/paverbank.com/paver.com/USD/1000/ON/+l-(212)-123- 4567 / DigitalSignatureOfwww.chips.com and establishes a network connection to complete the lending operation. It is worth noting that the notation of the Payer ID www.payer.com can itself be reversed by using the INN-ADDR operation in the name payer, payerbank. chips.corn inside www.chips.com, because www.payer.com is the host in the clearing domain www.payerbank.com, and www.payerbank.com is a sub domain inside the www.chips.com administration area of the CHIPS AKP.

8. www.CHIPS.com creates a t-call 3 call string in the form debit.PayerBank.comPchips.com/payerbank.com/payer.com/USD/1000/ON/+1-(212)-123-4567/DigitalSignatureOfwww .chips.com and establishes a network connection to complete the debit transaction.

9. www.payerbank.com creates a t-call 4 call string in the form debit.paverbank.com?paver.com/USD/1000/ON/+1-(212)-123-4567/DigitalSignatureOFwww.payerbank.com.

10. Bank www.TargetBank.com creates a t-call credit call line. 12121234567? Chips.com/paverbank.com/paver.com/USD/1000/ON/+1- (212) -123-4567 / DigitalSignatureOfwww.TargetBank.com and establishes a network connection to complete the lending operation of the Payee.

Although only the case of crediting the account of the Recipient is considered here, any next or professional can easily apply the described technique for use in debiting, billing and other transactions.

Obviously, the advanced techniques NAPTR RR and DDDS proposed in RFC 2916, 3401-3406 can be used to execute the described examples. In this case, the resolution result can be obtained in the form of NAPTR:

rauee.sot

IN NAPTR 100 80 "a" "pay + N2C" "" pavee.com@credit.payeebank.clearing.com. IN NAPTR 100 80 "a" "pay + N2D" "" Davee.com @ .dedit.paveebankl.clearingi.corn, IN NAPTR 100 80 "a" "pay + N2B" "" pavee.com @, billmg.paveebank2. clearmg2.com.

In the latter case, each type of transaction uses, by default, separate URLs for clearing, debiting, and billing for some conditional payment service.

Optimization of the clearing route at cost.

It is well known that electronic payments have a cost, and the cost may vary depending on the payment method (via ABA, SWIFT or by credit card), while the Payer, Recipient and payment amount remain unchanged. Fig. 18 illustrates various payment chains, including a different number of participants, and this number can also affect the cost of a transaction, as well as its time.

Assume that the API exists and implements a certain “cost” command, we also assume that this “cost” command is similar to the existing Internet “tracert” command, but additionally returns the cost of an atomic point-to-point payment and other characteristics as result parameters. Such a command could be executed using the route search services, as shown in the example “Route search service provision case” above. Assuming this for the infrastructure shown in FIG. 18, the conditional “cost” command applied to the Client Client # 3 would detect the clearing route (Client # l → CF # l → CF # 2 → CF # 3 → Client # 2), returning the following result:

C: \> cost'Client # 2 '.

Tracing route cost to 'Client # 2' [212.24.32.169] over a maximum of 30 hops:

Route 1

1 10ms 10 ms 10 ms USD 0.32 CF # 1 [192.168.1.3]

2 10ms 10 ms 10 ms USD 0,0 CF # 2 [62.118.27.65]

3 10ms 10 ms 10 ms USD 0.5 CF # 3 [10.4.255.100]

4 10ms 10 ms 10 ms USD 0,0 Client # 2 [10.4.255.101]

Route 1 statistics:

Number of CF Nodes = 3 Approximate payment cost USD 0.82 Approximate payment time 30 ms

C: \>

Now suppose that Client # 1 would like to transfer money to Client # 3. To do this, he can use one of the alternative clearing routes:

(Client # 1 → CF # 1 → CF # 2 → CF # 3 → CF # 4 → Client # 3) or

(Client # 1 → CF # 1 → CF # 2 → CF # 5 → Client # 3) or

(Client # 1 → CF # 1 → CF # 6 → CF # 7 → CF # 5 → Client # 3).

Therefore, processing the 'cost' command in relation to payment (Client # 1 → Client # 3) would give the result:

C: \> cost 'Client # 3'.

Tracing route cost to 'Client # 3' [212.24.32.169] over a maximum of 30 hops:

Route 1

1 10 ms 10 ms 10 ms USD 0.32 CF # 1 [192.168.1.3]

2 10 ms 10 ms 10 ms USD 0,0 CF # 2 [62.118.27.65]

3 10 ms 10 ms 10 ms USD 0.5 CF # 3 [10.4.255.100]

4 10 ms 10 ms 10 ms USD 0.5 CF # 4 [10.4.255.101]

5 10 ms 10 ms 10 ms USD 0.5 CF # 3 [10.4.255.102]

Route 2

1 10 ms 10 ms 10 ms USD 0.32 CF # 1 [192.168.1.3]

2 1 day 1 day 1 day USD 0,0 CF # 2 [62.118.27.65]

3 10 ms 10 ms 10 ms USD 0.5 CF # 5 [10.4.255.103]

4 10 ms 10 ms 10 ms USD 0,0 Client # 3 [10.4.255.105]

Route 3

1 10 ms 10 ms 10 ms USD 0.32 CF # 1 [192.168.1.3]

2 10 ms 10 ms 10 ms USDO, 2 CF # 6 [62.118.27.65]

3 10 ms 10 ms 10 ms USD 0.5 CF # 7 [10.4.255.106]

3 10 ms 10 ms 10 ms USD 0.5 CF # 5 [10.4.255.107]

4 10 ms 10 ms 10 ms USD 0,0 Client # 3 [10.4.255.108]

Route 1 statistics:

Number of CF Nodes = 4

Approximate payment cost USD 1.32

Approximate payment time 50 milliseconds Route 2 statistics:

Number of CF Nodes = 3

Approximate payment cost USD 0.82

Approximate payment time 1 day and 30 milliseconds Route 3 statistics:

Number of CFNodes-4

Approximate payment cost USD 1.52

Approximate payment time 50 milliseconds

C: \>

Obviously, the route “Route 2” has the lowest total cost of the CES in the amount of USD 0.82, but at the same time it has the largest clearing duration of 1 day versus 50 milliseconds for the routes “Route 1” and “Route 3”. The technique of the 'cost' team is computational and allows you to control the cost and time of payments in real time.

The above APRI technique provides a unique implementation of the ranking of clearing routes using the “cost” command for CES payments. This ranking, in turn, allows you to manage clearing routes, taking into account the preferences of users regarding the cost and timing of the transaction, and therefore the invention offers a practical solution for financial institutions and their respective clearing using the cost command cost tracing.

Using the payment preferences in the last example with the “cost” command can allow implementing various clearing scenarios, so if the first preference of the user is real-time clearing and the second preference is to minimize the price, then the result of clearing control will be the route “Route 1” with the price cost USD 1.32 and a time of 10 milliseconds as the cheapest way to route with real-time clearing; and if the first preference of the user is the minimum price and the second is the clearing time, the result of clearing management will be the selection of the “Route 2” route with a price of USD 0.82 and 1 day time.

As shown in the application, it remains possible to use the existing Internet technology, its transport resolution and routing techniques, as well as the use of mature PKI technology for payment clearing, providing real-time multi-level and multi-route clearing infrastructure and payment services that facilitate simple cost management and payment processing routes, creating conditions for Straight Through Processing (STP) payments of the CES. Managing the cost of payments in the ARPI infrastructure can significantly reduce or completely avoid the cost of clearing, allowing account holders to manage and control the cost in the timing of their payments.

Network-specific identifiers (such as ETA, META, and others) and network-specific software and user interfaces (a telephone user interface focused on using only the numeric keypad) can be used to navigate and manage ARPIs, allowing you to conveniently address payments and automate their clearing.

ARPI allows users to address payments without the need to know the bank details of the payee and clearing methods, while at the same time providing the CES with the permission of the details of the payee's account and the through processing of payments and their clearing.

The invention of ARPI completely changes the essence of making payments, transferring them to the field of private clearing and banking services in the field of standardized technological solutions; from the field of work with tedious bank details to the field of work with meaningful and easy-to-use network ETA identifiers and names; From the need to know the details of bank accounts to the freedom to use account resolution services from the impossibility of making payments using digital telephone keypads to the freedom of addressing payments using existing telephone contact lists; from 20th-century paper technology to digital real-time technology and full automation.

The active use of PKI certification services solves the problem of trust in account data, allowing you to provide a secure environment for payments and clearing. The use of Attribute Certificates containing only the Payer's network address and the corresponding OKO network addresses allows filling the DNS database of the addressing system with authenticated information and avoiding unwanted disclosure of confidential banking information.

Using the existing DNS technology for resolution in a certified set of displays allows you to discreetly receive the necessary reliable banking information, creating the conditions for the provision of real-time end-to-end processing services.

ARPI widely relies on the use of the existing Internet infrastructure and its technologies, its protocols, therefore, providing a uniquely cheap built-in mechanism for end-to-end payment processing and automatic control, resolution, routing and final settlement. The invention opens the doors of the SID (Shared Information and Data) model for ARPI by providing Technology Neutral Architecture (TNA) for implementing TM Forum's forum (www.tmforum.org) for implementing a business model called New Generation Operations Systems and Software (NGOSS).

While the application describes the creation of a new Architecture for Conducting Settlements via the Internet and describes various methods for creating, issuing and managing Digital Certificates, with the possibility of multi-level distribution of CAs and access to many accounts using the specified CAs and PKI, based on the described, any specialist is able to offer various options for methods and their implementation within the framework of the approach set forth in the application. Therefore, the depth of the invention is defined by the following claims.

Claims (6)

1. The method of conducting transactions in the network, which consists in assigning a network identifier to at least one network resource, which is a unique transaction identifier used in addressing transactions of the specified identifier, while the files of telephone numbers of subscribers of the communication network, including the telephone number of the central switch, providing communications services, are placed on the central switch and in the Resource Files on the server of the Transaction Services Provider, ensuring the interconnection of these numbers in with their network identifiers, transactions are carried out by addressing a network call using a network resource identifier, a network call for transactions is carried out by means of a transaction instruction with a network identifier of the called resource, and upon receipt of a request to establish a network resource location containing the telephone number of the called resource, retrieving the specified network identifier associated with this phone number, and establish a connection by conducting a trans tion with the specified network resource. 2. The method according to claim 1, characterized in that the notation of the unique transactional identifier of the network resource contains identifiers of transaction zones and information about their hierarchy, each of the zones is a server of the Transaction Services Provider for child zones, and the last in the hierarchy is a child zone, by default, it is a Transaction Services Provider for the specified network resource. 3. The method according to claim 1 or 2, characterized in that a digital certificate containing at least a unique transactional identifier and a public key of a network resource is placed in the Resource File. 4. The method according to claim 1, characterized in that for routing the connection from the Network Resource Files, a unique transaction identifier of the calling and called resources is extracted, identifiers and hierarchy of transaction zones for the indicated network resources are determined, the common zone for the called and called resources, which is the Point Turn of the Route, in which the transaction from the ascending in the zone hierarchy of one of the resources becomes descending in the zone hierarchy of the second of the resources. 5. The method according to claim 1, characterized in that when identifying several Turning Points of the Route, alternative routes are laid through them in order to establish communication for the transaction. 6. The method according to claim 1, characterized in that the transaction instruction is a billing instruction or a payment instruction, or a trace instruction, or an instruction for estimating the duration or cost of a payment.

Images