WO2005025177A1

WO2005025177A1 - Global village communication protocol (gvcp)

Info

Publication number: WO2005025177A1
Application number: PCT/IB2003/004017
Authority: WO
Inventors: Ali Movahedian Attar; Ghazal Abadi Naeini; Ali Hassani; Hamid Mohavedian Attar
Original assignee: Ali Movahedian Attar; Ghazal Abadi Naeini; Ali Hassani; Hamid Mohavedian Attar
Priority date: 2003-09-09
Filing date: 2003-09-09
Publication date: 2005-03-17
Also published as: AU2003269292A1

Abstract

GVCP is a set of new related protocols working based on TCP/IP model, which aim to create global unique reliable, electronic human identification. This new identification named GVC {Global Village Communication Identifier) and has a friendly format of email address, but with much additional functionality. For this new identification being reliable and secure, GVCP protocols are based on new authentication and authorization methods named Trilateral Authentication and Connect-Back Authentication. GVCID can replace all of a human': contact information; because GVCID is unique and it is routable to different communication networks e.g. telephone network, by its GVCP Provider. A part of GVCP is NMTP or Negotiable Mail Transfer Protocol, which provides a new reliable credible email system. NMTP is also based on Connect-Back and Trilateral Authenticati systems. NMTP makes it impossible to send spams, faked or even undesired emails.

Description

Global Village Communication Protocol (GVCP)

SUMMARY OF THE INVENTION

[001] Today, the Internet suffers from unreliability and lack of credit that makes it an unreliable media for important communications. You can never fully trust the identification of entities that you encounter in the cyber-space. The present invention or GVCP is a set of small protocols based on Connect-back Authentication inquiry methods (like Back Sessions and Disconnect/Reconnect) and Distributed Sessions System. GVCP can resolve many present problems in the Internet that stems from unreliability, like spam, faked emails, credit card fraudulences and so on.

[002] Global Village Communication Identifier or GVCID is global unique identifier that is used in the GVCP environment. Each GVCID is associated with a real human or human related identity. GVCID uses email format because each email address is global unique address that has a friendly format. Beside this, email addresses are compatible with other Internet protocols and softwares. Therefore, the email format is the best format that can be used as GVCID. But GVCID functionalities are not limited to just email use. GVCID is a real human identifier and can be used to access every resource in the Internet and GVCP environment. It also can be used as a single point of access to every human being in the world, because GVCP is able to connect all of the communication networks and routes all the communication requests through the GVCP environment to their final destination. Each communication request can be in the format of GVCID, because all these requests will be routed through GVCP environment. For example, for having a phone call to John, you can simply request a phone call to John@company.com. The request will be routed in the GVCP environment and GVCP will route this request to the final GVCP-telephone network gateway, which will connect you to John by telephone. There is not even necessary for you to know the John's phone number. And as an advantage, there is no need for John to have a constant telephone number for being sure that everyone can reach him.

[003] Connect-back authentication is a new authentication method used in GVCP and it is a kind of inquiry authentication. In this method, the destination connects back to source after receiving a request, for inquiry purposes. On the other words, the destination does this job in order to be sure about the source validation. This connecting back can be done in two ways:

Disconnection of the primary request session and then connecting back to the sender. (Secure connections can also be used.)

Keeping the primary session and connecting to the sender by another session named Back-Session.

(Secure connections can also be used.)

In each case, the connecting back action is based on DNS information and as a result, the security of the DNS is an important issue in this method. Negotiable Mail Transfer Protocol (NMTP) is based on Connect-back Authentication, in order to prevent faked emails and identities. ***Another important benefit of this connecting back, is informing the sender server that it is sending an email from for example user@senderserver.com. This matter prevents a sender from sending thousands of emails per day from its NMTP server.

[004] Trilateral Authentication Method is a method based on inquiry about a client from its home server. This method is used when a client wants to access an external resource in the net. Three entities take part in this authentication method. The method works as follows: Client A requests service 1 from Server 1 by sending some information about its home server and its originality(or a server that have the right for confirming, authenticating or authorizing that user) to Server 1. (The request is sent directly to Server 1 or by client A's gateway.) Serverl connects to the client A's home server and inquiries about the client A. In case that everything is Ok, Serverl confirms the client A's identification. Client A enters the password for servicel.

[005] GVCID Trilateral Authentication Method produces a new generation of high-secure authentication and authorization method without needing security coding systems. Trilateral Authentication Method is used for authenticating and authorizing a GVCID 's identity for accessing external Internet resources. This way the external resource provider checks the user's identity by asking from the GVCP Provider of that user. For example, you are going to access an Ftp resource and you provide your identification like user@company.com and your Ftp password. The Ftp provider, in the first level, checks user@company. corn's identity by referencing to company.com which is the GVCP Provider of the user@company.com and knows this identity. On the other words, in the first level, Ftp provider checks the username's identity and in the second level, it checks the ftp password, or vise versa. The biggest difference between usual authentication systems and Trilateral Authentication method is that in usual authentication systems, it is just the password that is checked but in this method both password and the username's identity is checked. Another benefit for this system is that your main password for your GVCID will just be transferred between you and your GVCP Provider once and after that, your authentication/authorization handler is your provider, company.com.

[006] The present invention, GVCP is a communication protocol working on application layer of the

TCP/IP model, which provides enhanced communication facilities by the help of GVCID Terminals.

There are five types of nodes in the GVCP environment, as follows:

1- GVCID Terminals that are end user terminals.

GVCID Gateways that are the most end-point connection between the Internet and GVCP environment and service the GVCID Terminals.

GVCP Providers, which are the mothers of each online GVCID and firstly authenticates and authorized their GVCIDs and after that, the load of further authentication and authorization for external services is their duty.

GVCP Servers, which are servers that provide different kinds of GVCP services for online GVCIDs in the Internet.

Ordinary Servers in the Internet that provide ordinary services on different ports.

[007] There are two kinds of GVCID Terminals, IP-based Terminals and fully functional IPless Terminals. IP-based Terminals work like ordinary terminals with normal ports. IPless Terminals work with their gateways based on GVCP (Please note that these terminals may have invalid IPs just for providing a communication infrastructure with their gateways.) and it is their gateways that act on their behalf in the Internet. One big difference between IPless Terminals and NAT/Proxy is that every GVCID Terminal has an online, accessible, routable address in the Internet. This address is GVCID Address like user@company.com. As a result, in case that the two sides and the gateway support GVCP, all point-to-point connections are possible by the use of this address. IPless Terminals provide many enhancements and facilities as follows: Because the server that provide a service in the Internet supports GVCP, it can deliver the data with compression in communications made through GVCID Terminals. (This is holds true about IP-based

GVCID Terminals too. This facility should be supported by the service server.)

GVCID IPless Terminals resolve the lack of IP problems in the Internet.

GVCID Terminals provide a very high secure communication environment, because every connection through these terminals are defined, confirmed and authenticated with GVCP Providers and GVCID gateways before establishment.

In case that IP-based GVCID terminal is used, there is no need for gateway to support GVCP. In addition, if IP-based Terminals want to benefit from enhanced security features of IPless Terminals, they can make use of a GVCID Provider. (GVCID Provider is a gateway, which service the GVCID

Terminals and act on their behalf in the Internet.)

[008] Reverse GVCP/NMTP gateways are gateways that are responsible for the distribution of GVCP NMTP requests to their final destination. In fact, these gateways act as one-directional interfaces from Internet to a local zone of servers. Mostly these gateways are used in most of negotiations, which u se Connect-Back Authentication S ystem. For example, a s erver in the 1 ocal zone sends the first request to connect to another server in the Internet. The second server tries to connect back to the first server with respect to Connect-Back Authentication protocol. Therefore, it asks the first mapped IP address of that domain from a trusted DNS and connects to it. The reverse GVCP/NMTP gateway must be located on this IP address and must reply to the requests of the second server and direct that server to the primary requester. The DNS inquiry phase can be optimized by adding a special record for defining reverse GVCP/NMTP gateways in the DNS system.

[009] Routing Key is a number that is used for specifying what type of connection service, is desired for accessing a specific GVCID. Routing Key is a filed in the GVCP request packet. In each request for accessing a GVCID, the Routing Key must be set to a value that maps to the desired type of communication mean. Routing Key number has 6 segments. Each segment has a specific meaning. Segmentl is used for specifying the type of physical service, for example voice, video, fax, email, online massaging, online sharing, human networking services, and other services. Segment2 specifies the sub-service. For example voice service has sub-services like telephone network, GSM network, VOIP service and so on. Segment3 specifies the destination contact in a multi-contact GVCID. For example for contacting John that works in support section of company.com by telephone, your connection request must specifies John in segment3 by a number. There is another option for this purpose that John.Support@company.com specifies John. Segment4 is used for subject routing of the request. There is a difference between subject routing and filtering systems used in email folders. In the subject routing, the sender defines the path and destination sub-address. Another advantage of subject routing system is that it makes the use of multi-user email addresses easier. For example, the technical support team of the large company can use a single email address for answering their clients. When a new email arrives, each person can answer this email. All further email correspondence regard the previous email, will be routed to the folder of the first person who has answered the primary email. Segments 0 and 5 are reserved.

[010] As its name reveals, GVCID provides a unique global identification, which is routable too for everyone who uses the Internet. This routablility adds very special features to GVCTD and as a result to GVCID Terminals, which makes them an ideal mean for communicational purposes. GVCID Terminal can be used as a static multi-purpose communication mean, because GVCP is able to convert all the variable human interfaces to a portable static one, which is the GVCID Terminal. GVCID Terminal can be used instead of the entire dynamic human interfaces, like telephone, cellular phone, fax, email, physical address, etc. In other words, when someone wants to access to you, knowmg your GVCID will be enough for you to being accessible. For example, suppose client A is on trip and you want to send him a fax. You can simply request sending a fax to clientA@company.com. Company.com knows the fax interface address of client A and will route your fax request to its actual destination.

[011] Negotiable Mail Transfer Protocol or NMTP is a new mail transfer protocol based on inquiry. NMTP h as many a dvantages o ver SMTP b ecause o f i ts a dvanced n egotiating s ystem. In N MTP, when the sender sends its request to the receiver, the receiver disconnects the session and connects back to the sender for being sure about the server identity. It is also possible to keep the primary session and make a connect-back through Back-Sessions to the sender server. The connecting-back action is done by querying from a trusted DNS server, retrieving the sender domain IP and then connecting to that IP. If the sender is the actual previous sender, then the session can be continued to send the reminder of data or email. This way, it will not be possible for sending faked emails, because the real identity of the sender server will be checked. NMTP has many other advantages, like preventing spam & faked emails, Protected Emails, point-to-point email delivery system, email expiry date, absolute receipt issuing, GVCP licenses for NMTP servers, sender & NMTP server credit/priority, GVSTAMP, multi-user email addresses and valid Email Numbers.

[012] Protected Emails are emails that need high security majors but they don't commonly use security-coding systems. Actually, Protected Emails aren't sent in the time of sending request, but the sender server just sends a header indicating some information about the existence of a Protected Email, the sender name, the expiry date of the email and the address of the remaining data of the email. The actual and important body or attachment of the email will be kept on the sender server in a secure password-protected area. When the receiver reads the header, he/she can refer to the address provided in the header and enters the receiver address and the predefined password (agreed between the sender and the receiver) for downloading the remaining data of the email. The download process can be done in a point-to-point secure connection.

[013] Absolute Receipt Issuing of an email benefits from the same method as Protected Email. A part of the email will be kept on the sender server and a header including the sender information, the remaining data address and a password will be sent to the receiver. A part of the email body can also be sent for informing the receiver about the subject of the email. Then the receiver will refer to the sender server for receiving the remainder email data and he/she will enter the password that has been provided in the email header. This way the sender server absolutely will be notified that the email has been received and read by the receiver and then it will issue the receipt of the email for the sender.

[014] Email Expiry Date is another benefit of the method used for Protected Emails. If it is desired to make use of the Email Expiry Date, the actual part of the email or an important attachment should be kept on the sender server like before and a header or a part of the email should be sent. Then if the date expires before the receiver referral, then the receiver will not have any access to the remaining data.

[015] GVCP has a complicated but effective licensing system. GVCP Licenses is necessary for every domain that wants to interact in the GVCP environment. GVCP License has many advantages that make it unavoidable. These advantages will be counted in the coming paragraphs. GVCP offers a Confederation to contribute the decision-making about the GVCP Licensing System to a number of trusted Internet communities and companies. The GVCP Confederation will grant a high level of credit and right to some entities called GVCP License Providers or LPs. LPs are responsible for granting a lower level of credits to different GVCP/NMTP parties in the Internet, for example NMTP servers. As a result, for each entity being functional in the GVCP environment, it is necessary to get a GVCP License from a License Provider. Each time it is necessary for an entity to show or spent its credit, the related License Provider will support that action. License Providers will assign a number to each GVCP Licenses that they grant. This number affects further activities of the GVCP License owner in the Internet like the number of emails it can send per day on the Internet, etc.

[016] GVSTAMP is an Internet stamp system for emails and is used for adding credit to emails. This additional credit can be referred by the receiver for deciding weather to accept an email or not, or when the receiver wants to sort his/her emails by their credit. Today a person can send thousands of emails per day and overflows the inbox of hundreds of people. If people don't accept emails without credit or GVSTAMP, this person cannot afford paying hundreds of dollars for sending spams. The amount of GVSTAMP can be even one cent or it can be just credit-based. But this money or credit- based system can prevent spamers from continuing their act. GVSTAMPs can also be used for paying small amounts of money to other people. For example, it is possible to pay for a email-based consultation service by the means of GVSTAMPs. GVSTAMP System is based on the GVCP Licensing System. Each NMTP server has to buy or get a specific credit from License Providers for issuing GVSTAMPS. For example, a NMTP server buys a 100$ License from LP1. Now, based on the confederation decision, this NMTP server can issue totally 100$ GVSTAMPS per day or a defined period.

[017] The Sender Credit is another credit-based system for showing the credit of the sender person. Some people have higher credits because of the amount of money the pay for the service; because of their clear records and the number of the years their accounts have been active. Another factor that affects the Sender Credit is the credit of the Sender Server, which is based on its GVCP License. The Sender Credit can be referred when the receiver person wants to make a decision upon reading the email or not. Or when a server wants to decide about giving a specific service to a requester or not.

[018] The global unique Email Number is another big advantage of the GVCP Licenses. A part of this number is the GVCP License number of the sender and the other parts are the email number of the sender, date and time of the sending plus the same information on the receiver side. Absolutely the sender doesn't know about the email number of the receiver, so the receiver places its email number in the global unique Email Number and also, informs the sender about this number. The advantage of this system is the creation of an automatic email secretariat for both the sending and receiving parties. This global unique number is reliable and can be referred in any situation as an evidence of an email has been sent. In addition, with respect to the GVCP License Number, each NMTP server can send a limited number of emails per day, month or year. In another words, the GVCP License Number can limit the senders or sender severs from sending thousands of emails per day. This major is another way for preventing spams.

[019] The Credit Coefficient is a number that is calculated based on other credit factors like Sender Credit, GVCP License, Invoicing System and GVSTAMP. The Credit Coefficient is a very useful factor for decision making about emails.

[020] Handling Mailing Lists and advertising emails are another issues covered by NMTP. In fact, NMTP does not prevent good features of Mailing Lists and advertising emails, but it makes them under control, because they are the roots of spam today. To control mailing lists and advertising emails, the receiver issues and assigns Routing Keys to distinguish between these kinds of emails and ordinary emails, so that there will be no need for License checking and credit, hi this way, companies can offer free/low price services in the event that their customers let them to send a number of advertising emails per day (week, month, year). All that the customers need to do, is issuing a special Routing Key to the service provider.

[021] In the GVCP environment, it is possible to take advantage of an invoicing system too. When A requests a service (like chat, video conferencing and so on) to B, it is possible for them, their providers or even another third party to agree upon the covering of the costs of that service. This provides a flexible invoicing system for each service being requested over GVCP environment. The communicating parties can negotiate and agree upon an invoice and then their bank/credit companies can confirm their having credit for paying the costs. After finishing the service, the money will be transferred to the bank account of the party that is eligible. For example, John@companyl.com requests a voice connection with Jane@company2.com. Company2.com GVCP server shows all the possible voice ways to Jane along with their price and QoS. Suppose that John chooses the GSM connection, and he notes that companyl.com will cover the costs of the connection. Then company2.com informs companyl.com from this issue and about the connection information. Company2.com routes/establishes the request/connection after receiving the confirmation from companyl.com and the companyl. corn's credit company. The process of companyl .com and its bank confirmation can be based on claim 34.

[022] In usual authentication systems, just a username and password are used for authenticating. In these systems, for extra security a secure connection or coding system can be used in order to protect the username and password on the line. The pitfall of such systems is that in case of password disclosure, all these extra security majors are of no use. If a second (third, etc.) level of authentication is done, the possibility of a security breakdown will tend to zero. As a result, a new extra level authentication system is invented that works based on sending a randomized code from the resource/service provider to the user's preferred communication device, for example mobile, palm, SMS device, an online status messenger, etc. and waiting for the primary requester/user to enters the randomized code into his/her terminal station. This way the resource/service provider can be sure about the user's real identity. The contact information of the user, for example his mobile phone number, will be kept in a secure password protected place in the service provider system or in the GVCP Provider of the user. The password for accessing and changing these information is different from the ordinary password that is used here and there.

[023] A new method for credit/money transactions is invented based on the Trilateral Authentication. This method makes it unnecessary for the people to enter their credit card information in insecure Internet sites or other insecure places. In this method, when user@company.com wants to buy something, he/she puts his/her GVCID and/or bank name instead of the credit card information in the site store.com. Then the store.com refers to the GVCP Provider of that user to check the bank/credit company information of that particular user. After thr GVCP Provider confirmation, store.com connects to the credit/bank company and request a money transaction for that GVCID into its account. The bank/credit company will check this request with the GVCP Provider of the GVCID and with the GVCID Terminal itself. After confirmation of both sides, it will do the money transaction. The confirmation can also be done by claim 33 for extra security. The obvious benefit of this method is that the user will not enter his/her sensitive information anywhere.

[024] The above credit c ard transaction method c an also b e used for physical shopping too. The credit cards can have just the GVCID of the holder along with a password/code (magnetic or not). This password code has no critical role in the transaction authentication process, but adds an extra level of security to the credit card itself. In this system, the cashier system have to be connected to the credit card company and have to pass the GVCID, password and the amount of money to the credit card company. The credit card company will check the information and will send a confirmation request to the shopper's preferred device, for example SMS device or mobile phone. The shopper will confirm the request by sending an Ok, and then the transaction will be done. Also the credit card company can send a randomized code to the shopper's for example mobile phone and waits for the shopper to enter that code to the cashier system for confirmation.

BRIEF DESCRIPTION OF THE DRAWINGS

[025] Fig.l shows the simplified process of Connect-Back Authentication Method.

[026] Fig.2 shows the Trilateral Authentication process.

[027] Fig.3 shows the process of a GVCID logging in to its GVCP Provider. In case of being connected to the Internet directly (IP-based) the gateway steps will be omitted.

[028] Fig.4 shows a GVCID login method for accessing an external service in the internet. This process takes place after the login process of the GVCID into its GVCP Provider.

[029] Fig.5 show the process of checking the emails number and the license provider of an email by inquiry from the sender's license provider.

[030] Fig.6 shows the process of sending a Password Protected email.

[031] Fig.7 shows the License Providers and their relation to the GVCP confederation. [032] Fig.8 shows the process of issuing and inquiring a GVSTAMP by the help of License Providers.

[033] Fig.9 shows the new credit card transaction method using the Trilateral Authentication system.

[034] Fig.10 shows the relationship of the GVCP Network with other communication networks.

DETAILED DESCRIPTION OF THE INVENTION

[035] Connect-back Authentication method is a new authentication method based on inquiry. When a sender sends a request to a receiver, it also sends some information about itself indicating that who is it. The receiver won't trust to the request because it may be a faked request, like when a relay smtp server introduces itself with a faked identity. For preventing faked requests being trusted, the receiver gathers some information about the sender from a trusted resource, for example its own

DNS and connects back t o the s ender and queries that i f the p revious r equest w as from the real sender or not. When the receiver decides to query about the sender, it can either disconnect the current session and reconnects to the actual sender. This method is called Disconnect/Reconnect. Or it can make its connection through a back session to the actual sender without disconnecting the current session. This method is called Back-Session Support. The Connect-back Authentication method works in this way:

The sender sends a request for service to the receiver. The request includes these data: Routing Key

(RK), caller (sender), receiver, IP, max. Sessions, Confirmation Number 1 (CNl).

In case that there is a main gateway in the sender's domain, the sender sends some information about its request to the gateway, like CNl, sender and receiver addresses.

The receiver sends CN2 to the sender.

The sender sends back CN2 to the receiver. (Steps 3 and 4 is done for preventing IP spoofing and

Denial of Service or DOS attacks.)

After the reception of CN2 request, in Disconnect/Reconnect method the receiver disconnects the session.

The receiver connects to its database for checking the receiver address and its availability and finding the responsible server for handling that specific receiver address. This responsible server is called Instead Server. The receiver can also pass the request to an Instead Server in case of high traffic or other reasons. Instead-Servers are not mandatory.

In case of Instead Server existence, the receiver server passes the whole request to the Instead

Server. From now on, the Instead Server will do all further communications.

The Instead Server inquiries a trusted DNS for finding the IP address of the sender's domain name.

The trusted DNS sends the requested IP address to the Instead Server.

The Instead Server connects back to the sender, based on the IP they have received from the trusted

DNS server.

The Instead Server sends CNl, the IP of the received request and sender and receiver address to that

IP address. This IP address can be a gateway or the actual sender.

In case that the IP address is belong to a gateway, the gateway checks the CNl and the IP address of the primary request. (The IP is checked with an internal database, which keeps a record of all active

IPs in the domain.) hi case that everything is Ok, the gateway points the Receiver Instead Server to the Sender Instead, based on the CNl (specific for each email) and the IP address of the primary request.

The session will be disconnected

The Receiver Instead Server connects to the Sender Instead Server and provides the CNl. The Sender Instead Server sends the CN2, or response with a "CNl Invalid" statement to the

Receiver Instead Server. CNl may be invalid because of time-out or other reasons. hi case of providing the CN2 by the Sender Instead Server, the Receiver Instead Server checks the

CN2.

In case of CN2 is Ok, the session will be continued for data transfer.

Note: Distributed sessions, secure connections and coding systems is also supported.

[036] Trilateral Authentication Method is a method based on inquiry about a client from its home server. The first party in this authentication method is the client, which somehow reveals its origin or home server to the server. The second party is the server who receives a request for a service from the client. The third party is the home server or origin server of the client. There are three methods for Trilateral Authentication, which are described in the next paragraphs respectively.

[037] Methodl of Trilateral Authentication is based on Confirmation Number (CN) generation. CN is a randomized number used for being sure of the identity of the client. CN has a vital role in this method because no hacker can intercepts the session between the client and Serverl . Serverl only trusts the session when the client sends the right CN to Serverl. CN can be generated by each of the three authentication parties.

It can be generated at the beginning of the request by the client and be passed to the Serverl and home server respectively. Then the home server sends the received CN to the Serverl and after that in step 5 below, the Serverl checks the two CNs.

It can be generated by the home server after confinning the received information from Serverl and be passed to the Serverl and the client. Then the client sends the received CN to Serverl and after that in step 5 below, the Serverl checks the two CNs.

It can be generated by the Serverl and be passed to the home server. The home server knows the client and passes the CN to it. After that, the client sends the received CN to Serverl. This way

Serverl will be sure about the identity of the client, hi step 5 below, Server checks the received CN and the CN that it had sent to the home server of the client.

Note: Please note that in b and c steps, CN will be generated only if the information is confirmed by either the home server or Serverl .

Another use of CN is in the beginning of a session for preventing IP spoofing and DoS attacks. For this purpose, the receiver sends a CN to the sender right after receiving a service request. Then it waits for receiving back the same CN from the sender. This way, if the IP address is faked, the CN, which has been sent by the receiver will be lost in the Internet, and as a result the faked sender cannot m ake D oS attacks, because it will not be able to have the CN (sent by the receiver) and cannot start the real procedure.

[038] Methodl of the Trilateral Authentication method works in this way(fig.2):

Client A requests service 1 from Serverl. (Along with the request some information like client's network address and client's originality is sent to the Serverl .)

Serverl refuses the service because of any of the factors, like Accessibility, Time, Network Address and so on. If the request is not refused, step 3 begins.

Serverl connects to the client A's home/origin server and provide it with the information that it has received from client A.

Home/Origin server checks the information and confirms/refuses the request/information because of the client online status, identification, time, Network Address and so on. Serverl or home server checks the two CNs. In case that home server is the one who compares the two CNs, it sends an Ok to Serverl .

In case that everything is Ok, Serverl confirms the client A's identification.

Client A enters the password for servicel .

[039] Method2 of the Trilateral Authentication method is based on network address and status checking. In this method, either the home server or Serverl collects the network information of the client from each other, and then checks this information with the information, which it has had before. The method works in this way:

Client A requests servicel from Serverl. (Along with the request some information like client's network address and client's originality is sent to the Serverl.)

Serverl connects to the client A's home/origin server and provide it with the information that it has received from client A. (Or collects the network information of the client from its home server.)

Home/Origin server checks the information and confirms/refuses the request/information because of the client online status, identification, time, Network Address and so on. If the two information are equal, the home server sends a positive signal to Serverl indicating everything is Ok. (In case that

Serverl collects the information in the previous step, Serverl checks the information instead of the home server.)

In case that everything is Ok, Serverl confirms the client A's identification.

Client A enters the password for servicel .

[040] MethocB of the Trilateral Authentication Method is a combination of methods one and two, where both CN and network information will be checked and confirmed.

[041] GVCID Terminal is a software working on application layer of TCP/IP model. There are two phases for GVCID Terminals being functional in the Internet. Phase 1 is when a user wants to use his/her GVCID Terminal. In this case, he/she must enter his/her GVCID (like user@company.com) and password in the terminal to login to it. The login process is done in this way:

The user enters his/her login information in the GVCID Terminal.(GVCID: user@company.com)

The terminal passes the information to GVCID Gateway.(Gateway may not have a role when the

GVCID Terminal is IP-based and has a valid IP.)

The GVCID Gateway passes the information to company.com .

Company.com authenticates the user and sends a randomized Confirmation Number (CN) to both

GVCID Gateway and GVCID Terminal.

The GVCID Terminal sends its CN to the GVCID Gateway.

The GVCID Gateway compares the two CNs that received from company.com and the GVCID

Terminal.

In case that the two CNs are equal, GVCID Gateway confirms the user and sends a confirmation to the company.com too.

Now company.com knows that the user@company.com is online and also knows its gateway IP address and Terminal IP address (In case that the terminal is IP-based). On the other hand, the user@company.com is also authenticated for the GVCID Gateway. [042] Phase 2 is when user@company.com wants to use an external Internet resource or service resides in Serverl and Serverl wants to check the user's identity and authenticates and authorizes user@company.com. The process is done by the Trilateral Authentication methods, methodl, 2 or 3. Methodl:

User@company.com requests servicel from Serverl. (Along with the request some information like user's network address and user's originality (like company.com, which is the GVCP Provider of that user) is sent to the Serverl.)

Serverl connects to company.com and provide it with the information that it has received from client A.

Compahy.com checks the information and confirms/refuses the request/information because of the client online status, identification, time, Network Address and so on.

Serverl or company.com checks the two CNs. In case that company.com is the one who compares the two CNs, it sends an Ok to Serverl .

In case that everything is Ok, Serverl confirms user@company. corn's identification. User@company.com enters the password for servicel. Note: Step 7 can also be before step 2.

Method2:

User@company.com requests servicel from Serverl. (Along with the request some information like client's network address and client's originality is sent to the Serverl.)

Serverl connects to the company.com and provide it with the information that it has received from user@company.com (Or collects the network information of the user@company.com from its home server company.com.)

Company.com checks the information and confirms/refuses the request/information because of the client online status, identification, time, Network Address and so on. If the two information are equal, company.com sends a positive signal to Serverl indicating everything is Ok.(In case that

Serverl collects the information in the previous step, Serverl checks the information instead of company.com.)

In case that everything is Ok, Serverl confirms the user@company.com' s identification.

Client A enters the password for servicel .

Notel : step 6 can also be put before step 2.

[043] Reverse GVCP/NMTP gateways are usable in situations where a specific domain contains a number of peer independent servers having same roles in the domain. In this case, when one of these servers, for example server A, connects to server B in the Internet, server B tries to connect back to server A. This connecting back is based on the DNS information which server B receives from a trusted DNS server. The DNS server returns an IP, that this IP must be the IP of the reverse gateway. Server B connects to the reverse gateway and provides some information about the primary request that it has received from server A. The reverse gateway has been informed about the primary request by server A, so it knows the situation and returns the IP address of the primary requester that is server A. As a result server B will connect to server A and the procedure will continue. [044] Routing Key is a number that is used for specifying what type of connection service, is desired for accessing a specific GVCID. Routing Key is a filed in the GVCP request data packet. In each request for accessing a GVCID, the Routing Key must be set to a value that maps to the desired type of communication mean. Routing Key number has 6 segments. Each segment has a specific meaning. Segmentl is used for specifying the type of physical service. Segment2 specifies the sub- service. Segment3 specifies the destination contact in a multi-contact GVCID. Segment4 is used for subject routing of the request and segments 0 and 5 are reserved. In each segment, the 0 value is used for requesting all available channels, prices and QoS of the specific type of request. For example, you want to make a voice connection to John, but you can't decide which medium you choose. Therefore, you set the value of segment 2 to 0 and send the request to John's GVCP Provider. John's GVCP Provider knows all the available communication channels to John and by noticing the 0 value, it sends the channel details to you. The details include the type of channel, the charges of each channel and the Quality of Service of each channel. Now you can make your final decision on how to contact John. The QoS option is also useful when there are more than one available backbone with different costs and QoS. The requester can easily decide which backbone to use.

[045] The GVCP Providers can also use Routing Key to route the requested services, in case that another server handles the services. For example, when company.com receives a request for GSM voice connection to John@company.com, it routes the request to gateway.gsm.com and this server will handle the request. The availability of John in the GSM network will be reported to the requester.

[046] It is possible to define an access-list for each Routing Key for preventing or granting access to the mapped service by other GVCIDs. For example, manager@company.com wants to answer phone calls from a specific group and deny others from bothering him. It is possible to define the access-lists by date & time. This method is called request-authorization for accessing a service.

[047] A GVCID Terminal is a communication device supporting GVCP, which is able to login a user's GVCID into its GVCP Provider. At this point, the GVCID Terminal holds the identity of its user and can be used as a communication mean with its user. This terminal can be a computer, mobile phone, watch, etc. When a user logins into a GVCID Terminal, he/she can freely move here and there, being sure that everyone is able to access him/her without knowing anything else more than his/her GVCID. This is true, because when a user logins to its GVCID, its GVCP Provider will be informed about all the user's status, like his/her location, telephone number, fax number, etc. Therefore, all the dynamic information of a user will be mapped to his/her static GVCID and the role of the GVCID Terminal is to provide the communication and information infrastructure for both sides, the user and the rest of the world. The role of the GVCP Provider is to route all the access requests to the user. Please note that the big difference between this system and other systems that provide online information about a user and also the retrieval of this information is that in the present system, the GVCP Provider routes the requests based on the Global Village Communication Protocol. In the present system (GVCP), the contactor can be never informed about the real information of the user, like his telephone number. In addition, the contactor can be denied to contact the GVCID owner, b ased on the user's settings. The process of routing the request i s as follows: Suppose that John@companyl.com wants to talk to user Jane@company2.com. Both of them are login into their GVCID Terminals.

John makes a request through his GVCID Terminal to talk to Jane with her mobile phone. He just put Jane@company.com instead of her mobile phone number in the address/number field.

The request will be routed to Jane's GVCP Provider (Company2.com's GVCP Provider).

Jane's GVCP Provider will check the request by authorizing the requester that is

John@companyl .com .

If the authorization were successful, Jane's GVCP Provider will try to authenticate John's identity with his GVCP Provider that is Company2.com' s GVCP Provider. (Trilateral Authentication)

Jane's GVCP Provider will add the routing information to John's request and will send the request to its final destination.

Note: Steps 3 and 4 are not mandatory and depend on Jane's preference.

[048] Negotiable Mail Transfer Protocol or NMTP is a new mail transfer protocol based on inquiry about the sender's identity. So NMTP is very reliable in comparison to present SMTP. Because of

NMTP inquiry nature, nearly it is not possible to fake an identity. There are many add-on features in this protocol, which make it very reliable, credible and useful. NMTP works as follows:

Phasel: Handshaking

The sender sends a request for sending an email to receiver. The request includes CNl, Routing

Key, sender address, receiver address, GVCP License number and IP.

The sender server sends a copy of CNl and sender address to its NMTP gateway, if the gateway is another machine.

The receiver server sends CN2, without processing the send request.

The sender server must sends back CN2 to the receiver. (This method prevents IP spoofing and DoS attacks.)

The Receiver server inquiries about the sender GVCP License number and email number and if it is ok, it will go to the next step. (This step will be described in more details later, in section [053])

The receiver processes the primary send request, after receiving back the CN2 and responses in one of the three ways:

Refuse-> Disconnect (Refusal reason by code: IP, sender address, receiver address, GVCP License problem, incorrect CN2, expired CN2)

Ok-Trusted- Waiting for actual email transmission. (This trust is because of trusting to one of the above parameters.)

Ok-Not Trusted-^ Disconnection/Reconnection or Back Session Supported. Phase2-1 : Disconnection/Reconnection The receiver server disconnects the session.

The receiver server connects to a trusted DNS server and queries about the sender domain name. The receiver connects to the IP provided by the DNS server. (This IP is the IP of the sender's NMTP gateway.)

The receiver server sends CNl and sender address to the NMTP gateway.

The NMTP gateway processes the CNl and sender address and responses to the receiver server in one of the 3 ways:

Refuse-^ Disconnect (expired CNl, sender address or IP problems.) Ok- starts sending the email. (If the NMTP gateway and the sender server are the same.) Ok- Returns the actual sender server IP to the receiver. The NMTP gateway disconnects the session. In the case that the NMTP gateway returns another IP to the receiver, the receiver server connects to that IP and sends CNl and sender address to the sender server. The sender server responses in one of the 2 way:

Refuse- Disconnects (reasons: expired/wrong CNl, sender address problems.) Ok- Starts sending the email. 15- Disconnecting. Phase 2-2: Back Session Supported In this method, the whole process is like the previous process, except that steps 8 through 13 is done in a back-session without disconnecting the primary session and then the actual email transfer will be done in the primary session.

[049] Protected Emails and Absolute Receipt Issuing are based on the same methods. In this method the actual email, a part of it or the attachment of it, will not be sent at the time of sending request.

But a header and/or a part of the body and/or other information will be sent to the receiver and the remainder data will be kept on the sender server in a password-protected area. Now the receiver is forced to refer to the sender server for getting all of the data and as a result, the receipt for that email will be issued certainly. This method also adds a very high level of security to sensitive and confidential emails and attachments, because the confidential part will not be sent and remained n the receiver server for a while, till the receiver comes and reads the email. On the other hand, the sensitive data can be transferred to the receiver in a secure point-to-point connection which is much more secure and reliable than ordinary data transfer methods. The process is different from the ordinary NMTP in just data/email transfer section and is as follows:

In the sending email step, instead of the whole email, a header including information about the sender, subject, password, the address of the remainder data on the sender server, and/or a part of body will be send to the receiver. (If the not-sent part is confidential, the password will not be sent to the receiver and it must be predefined between the two sides. If this method is being used just for receipt issuing, a default password can be sent along with other header information to the receiver.)

The s ender sends the confidential part of the email to the server and server keeps this part, in a password-protected area.

The receiver reads the header and refers to the address of the remainder data.

The receiver connects to the sender server and enters the password.

The sender server can refuse the connection because of the wrong receiver address or the wrong password or because the email has expired. (Refer to Email Expiry Date.)

The sender server immediately issues the receipt.

The remainder data will be transferred to the receiver machine or server. (The data transfer can be done by a secure point-to-point connection.)

[050] The GVCP Licenses will be assigned by a number of GVCP License Providers, which are approved by the GVCP Confederation itself. Each GVCP License is associated with a number. Each time a requester sends a GVCP request, it must send its GVCP License name, number and GVCP License Provider to the service provider. The service provider can check the GVCP License of the requester by referring to the GVCP License Provider of that request. If the service server doesn't trust to the identity of the GVCP License Provider, it can query about that License Provider from a trusted License Provider. [051] Generation, distribution and confirmation of GVSTAMPs is done by the cooperation of GVCP

Confederation, GVCP License Providers and NMTP servers. These processes are also based on

Trilateral Authentication System. GVSTAMPs are generated by NMTP servers. For being able to generate GVSTAMPs, NMTP servers have to deposit an amount of money or credit in License

Providers to get a GVCP License. Then, based on this license, the NMTP s erver is p ermitted t o generate and distribute GVSTAMPs. The process is done as follows:

A user applies for a x$ GVSTAMP from its NMTP server.

The s erver checks the r emainder v alue o f i ts credit to see ifit is p ossible t o i ssue the r equested

GVSTAMP or not. (If not, a separate process will be done to acquire the required credit for issuing a

GVSTAMP.)

If there is enough credit, the NMTP server issues a GVSTAMP. This GVSTAMP contains x dollar amount, the License Number and License Provider of the NMTP server.

The user attaches this GVSTAMP to his/her email.

The sender NMTP server informs its License Provider about the issuance of the GVSTAMP.

The sender sends the email.

The Confirmation process is as follows:

The receiver NMTP server refers to the sender's License Provider to check the validity of the

GVSTAMP. (If the receiver NMTP server doesn't trust the sender's License Provider, it can inquiry about that LP from a trusted LP.)

If it is Ok, the receiver NMTP server will receive the email.

The receiver NMTP server informs the sender's License Provider about the acceptance of the email.

The sender's License Provider decreases the sender's NMTP server credit with regard to the value of the issued GVSTAMP.

[052] GVCP License number and its checking is especially important in NMTP email transfers. As it mentioned before each email in NMTP environment has a unique global email number and this number is strictly associated with the GVCP License number of the NMTP server. In fact, the email number includes the GVCP License number and other factors like date/time and the actual email numbers of both sides (sender and receiver). The GVCP License number is fixed in length, for example, it has 32 digits, in the format of ABCD...G00...00. The underlined part must be a character from A-Z and is the actual GVCP License number. This part it is not fixed in length. The second part contains a series of zeros and these two parts forms the GVCP License number together. The shorter the first part is, the more credible is the GVCP License number. Because the number of zero's specially affects the number of emails that a server can send in a defined period of time (daily, weekly, monthly, yearly). For example a NMTP server with license number ABCDEF00000000000000000000000000 can send 10 powered by 26 minus 1 number of emails per day (or week, month, year) and a NMTP server with License number ABCDEFGHIJKLMNOPQRSTUVWOOOOOOOOO can send 10 powered by 9 minus 1 number of emails per day (or week, month, year). Therefore, the GVCP License number can limit the number of emails that a mail server can send, and this limitation prevents sending thousands of spams.

[053] Each time a NMTP server wants to send an email, a special procedure should be done for evaluating the Email Number. This procedure prevents a sender from sending more emails than its quote per a defined period. The procedure is as follows(fig.6): i the normal NMTP procedure for transferring an email, the sender sends the Email Number plus its GVCP License to the receiver NMTP sever. After the sending process, the sender NMTP server sends the Email Number that it has just sent, to its License Provider.

The License Provider checks to see if the Email Number is right or wrong.

The receiver NMTP server checks the received email number with the sender's License Provider.

(The License Provider is known from the License Number, because each License Provider assigns a pre-defined range of License Numbers to their clients.) ^•

If the receiver NMTP server doesn't trust the sender's License Provider, it can inquiry about that from a trusted License Provider.

[054] NMTP handles Mailing Lists and Advertising Emails in a controlled manner. In fact when subscription to a mailing list or advertising email is desired, a Routing Key must been issued and assigned in order to let the mailing list to send emails without credit to the receiver. For this purpose, the receiver request a Routing Key from the its NMTP server by giving it the information about the mailing list and the characteristics of the mails which the mailing list is permitted to send. For example, the receiver set restrictions on the number of emails per day (week, month or year), the size of the emails and the format of the emails that the mailing list is permitted to send. Then the receiver's NMTP server issues the Routing Key for this request and sends it to the receiver. The receiver sends the RK to the mailing list. At this point, the mailing list can check and confirm the RK by the receiver's NMTP server or not. All further emails to this particular receiver should be sent by this Routing Key to the receiver. In addition, for Mailing List being known to the NMTP servers, a constant License Number will be reserved for all the Mailing Lists in the world. As a result, the NMTP servers can distinguish between a normal email and a Mailing List email. NMTP servers don't check the License of the Mailing Lists with a License Provider, but they just check the Routing Key.

[055] Advertising Emails are sent like Mailing List emails. You can permit a company to send you a number of advertising emails per day by assigning a Routing Key to that company. This assignment is because you use one or more services provided by that company free of charge or by discount.

[056] GVCP offers a very useful and flexible invoicing system to its users. Suppose John@companyl.com is on a trip in Africa and he wants to make a video connection to jane@company2.com. Because he has limitations for spending money, he requests from Jane to cover 50 percent of the connection fee. Jane agrees on this invoice. Africa.com will charge both of John and Jane for this connection. The system works as follows:

1- John logins into his GVCID John@companyl.com.

2- John requests a video connection to Jane@company2.com from his local provide named Africa.com.

3- Africa.com sends John's request to both companyl.com and company2.com and announce its charge to the service, for example $1 per minute.

4-company2.com informs Jane and Jane's present video provider of this request, for example Europe.com.

5- Europe.com announces its charges to the service.

6- John defines the invoice, for example 30% John and 70% Jane.

7- companyl.com confirms the request and announces the maximum John's payable charges for this connection, the Max Trust Value (MTV) and also it informs its bank/credit company of the request. MTV is the maximum amount of money which a paying party can trust to the service providers (because it is the service providers that have to report the duration of the service to the paying parties.). For example, companyl.com announces that it and its bank/credit company need to receive a packet showing the continuation of the service. If the cost per minute is $1, and the MTV is 50 cents then the service providers have to send a packet showing the continuation of the service every 30 seconds.

8- Jane confirms the request.

9- company2.com confirms the request and announces the maximum Jane's payable charges for this connection and the MTV and informs its bank/credit company.

10- MTV will be set to the lower MTV for both parties.

11 - The bank/credit company of both sides sends confirmation to both Africa.com and Europe.com.

12- The connection will be established and with respect to the MTV both communicating parts will report to the companyl and company2 and their bank/credit company.

13- John, Jane, Africa.com and Europe.com report regard the ending of the service to companyl ,company2 and their bank/credit companies.

14- The bank/credit companies transfer the amount of the service cost to the bank/credit company of Africa.com and Europe.com.

[057] The new method for credit card money transactions is a Trilateral Authentication system between the client, the store and the client's bank or GVCP Provider. The method is as follows:

User@company.com wants to buy a x$ good from store.com. He sends this request by providing his

GVCID and bank account number to the store.com.

Store.com sends a confirmation number to the GVCID Terminal.

GVCID Terminal sends the received confirmation number from store.com to its GVCP Provider and requests from it to confirm the payment.

Store.com queries about the GVCID and its bank from the GVCP Provider. (This level avoids DoS attacks to a special bank.)

After the GVCP Provider's confirmation, store.com requests the transaction from the user's bank, by providing the GVCID and amount of money that should be paid.

The user's bank checks this matter with the GVCP Provider of the user and gathers the online status and information of the GVCID from the GVCP Provider. In addition, it gets the confirmation number of the transaction (generated by store.com at first)

User's bank sends the said confirmation number and amount of money to the GVCID Terminal and requests the final confirmation.

The user confirms the transaction by sending a password to the bank.

User's bank sends the money to the store. corn's bank account.

The store.com' s bank notifies it about the money transaction.

Claims

What is claimed is:

1- The invention of a new protocol named GVCP (Global Village Communication Protocol), which is a combination of smaller related protocols that facilitates and broadens the use of Internet and its resources.

2- The invention of a global unique identity named GVCID (Global Village Communication Identifier) that uses email address format.

3- A method of utilizing cliam2 as a communication terminal named GVCID Terminal.

4- A method as claimed in claim 3 including supporting fully functional IPless GVCID Terminals. These IPless terminals have routable global unique addresses that are GVCID addresses. With this IPless Terminals the use of point-to-point services are possible.

5- A method as claimed in claims 3 and 4 that makes a portable GVCID Terminal, which can be used as a GVCID access point. This portable GVCID Terminal can be mounted on various communication devices like cellular phone, telephones, laptops and so on.

6- A method for authentication named Connect-back Authentication. This method is based on the disconnection of the p rimary s ession (sender-to- receiver) and then making a reverse connection by the receiver (receiver- to-sender).

7- A method as claimed in claim 6 including supporting Back-Sessions instead of disconnect/reconnect.

8- A method as claimed in claim 6, including supporting secure connections.

9- A method as claimed in claim 7, including supporting secure connections.

10- A method as claimed in claim 6, including supporting Distributed Session System.

11- A method as claimed in claim 10, including supporting secure connections.

12- A m ethod for a uthentication n amed T rilateral A uthentication m ethod. In this method, the service provider inquiries about a client/request's identity and its access level from its home server.

13- A method as claimed in claim 12 used for authenticating and authorizing a GVCID or a GVCID Terminal named GVCID Trilateral Authentication Method. This method is used in case of requesting an external Internet resource or a GVCP service.- A method of confirmation named Confirmation Number (CN), which is a randomized number generated by a communication party in a communication process (involving two or more communicating parties) for confirming and validating a c ommunication cycle. A communication cycle means a sequence of TCP/IP sessions that form a single desired networking act.- A method as claimed in claim 14 used for preventing LP spoofing and DoS (Denial of Service) attacks.- A Reverse GVCP Gateway for every domain using GVCP or NMTP, which replies to the reverse connections from receiver to the sender.- A method named Routing Key (RK) for specifying the kind of service being requested on every GVCLD in application layer, like telephone, mobile phone, VOIP, Video conferencing, fax, mail, email and so on (every e-connections).- A method as claimed in claim 17 for automatic routing of emails inside the mailboxes to different folders.- A method as claimed in claim 17 and 18 for multi user email addresses.- A new Mail Transfer Protocol named Negotiable Mail Transfer Protocol (NMTP) based on Connect-back and Trilateral authentication methods.- A method as claimed in claim 20 including Protected-emails.- A method as claimed in claim 21 including point-to-point email transfers.- A method as claimed in claim 20 including Email Expiry Date.- A method as claimed in claim 20 including Absolute Email Receipt Issuing.- A method for making GVCP connections and NMTP emails reliable and credible, named GVCP Licensing System.- A m ethod b ased o n claim 25 for p roviding a global u nique v alid E mail Number.- An invention based on claim 25, named GVSTAMP for adding credit to emails sent by NMTP.- A method based on claims 20,25 and 27 for preventing spams and faked emails. - A new concept named GVCP Sender Credit used for making GVCP communications credible.- A new concept named Credit Coefficient for sorting emails/requests and knowing the real priority of each of them.- A method based on claims 17,20 and 25, named Mailing List License for allowing the reception of a pre-defined number of zero-credit emails/requests from mailing lists and advertising companies.- A method for financial sponsorship of some of the activities of a GVCLD by its company/home server or another third party, for covering some of the expenses and costs of that activity.- A new method for high-secure authentications in which a random confirmation number (CN) will be sent to one of the user's preferred communication device, for example SMS device. Then the user sends back this randomized number to the CN's provider. This method is used for confirming an authentication request.- A new secure method based on claim 12 for credit/money transaction without using security codes. In this method the seller inquiry the GVCP Provider/Bank of a GVCID for available credit. Then the GVCP Provider/Bank checks the availability, also checks the request with the GVCID owner, and then confirms the requested transaction. So it is not necessary to enter the valuable information of a credit card in the seller's website.- A credit card system as claimed in claim 34 named GVCard including physical shopping, ATM systems and so on.