Patent Application
20070255815
The present invention provides software, systems, and methods for establishing secure and authenticated exchange of electronic information over a computer network. Using the software, systems, and methods provided herein, users can exchange information electronically with greater security that the information will not be compromised, i.e., viewed by those who are note authorized to receive the information or tampered with to mislead the intended recipient, and that the information will be received by the intended receiver.
In a first aspect, an example of which is illustrated in
The system (1000) can include other devices for secure electronic information exchange, including wireless devices communicating with the system, such as, for example, a personal digital assistant (1010) communicating through a base station (1012), or a remote cell phone (1014) by an antenna (1016). Still other devices that can participate in such communication will be apparent to those having ordinary skill in the art. The just described are of standard design and construction, and their operation in accordance with the invention described herein will be understood by those having ordinary skill in the art.
As noted above, the secure electronic communications server computers (1006, 1006′) are of standard construction and operation as will be familiar to those having ordinary skill in the art. In some embodiments, at least one of the secure electronic communications server computers (1006, 1006′) includes one or more databases (1018) in secure electronic communication with the server(s) that provide descriptive information of the sender of the electronic information (1002) and the receiver(s) of the electronic information (1004). In more specific embodiments, the descriptive information is effective to enable the authentication of the sender of the electronic information (1002) and the receiver(s) of electronic information (1004). Examples of information suitable to enable such authentication include, without limitation, address, phone number, personal identifier (such as a photo or symbol) or other information which helps other parties on the system authenticate a user. The registered e-mail address can be the same e-mail address used on publicly accessible email systems, commonly referred to today in common practice as “e-mail” or “Internet e-mail”, a proprietary electronic mail address used on a private email network, or a virtually private email network. Still other types of suitable e-mail address will be apparent to those having ordinary skill in the art. The information can also be arranged in a hierarchal structure such that a user can be identified at various tiers. For example, an identifier could include a company name, a division name, and user name. Thus, if one party in an email exchange wishes to validate the identity of the other party, then the invention provides the means by which the user may do so. Additional information and methods for providing such information to the database will also be apparent to those having ordinary skill in the art. The database may separate from, or integral with (i.e., as a real or virtual data device) the server(s), and such arrangement may be different on different servers in a multiple sever configuration embodiment. Those having ordinary skill in the art will understand how to provid the database(s) just described.
In one embodiment, at least certain aspects of the authenticated ID of the user, such as name and address, at the server must be unchangeable by the user after the user has been authenticated at registration to prevent spoofing. In more particular embodiments all aspects of the authenticated ID are not changeable by the user after authenticated registration. In still more specific embodiments in which either of the foregoing limitations on changing a user's authenticated ID are provided, the only way for the user to effect any such change is to re-register or re-authenticate.
In one embodiment, the server(s) are configured to maintain the identities of individuals or devices such that that their identities can be verified by other individuals sharing the system; thus, the same server(s) facilitate the transmission of a file or document between two or more parties such that a client on the receiving computer can autosort electronic information at the receiver with a degree of certainty of the integrity of the electronic information and the sender's authenticity. As used herein, “autosort” refers to automatically storing received electronic files or messages, and, in some embodiment of the invention automatically storing received electronic files or messages within a hierarchy of electronic folders according to information relevant to the sender, or (sub)class of sender, wherein each folder identified as being associated with the sender or (sub)class of sender (or both). For example and with reference to
In a more specific embodiment of the invention, the above-described autosorting of incoming electronic information in implemented at the client (i.e., the receiver of the electronic information). In such embodiments, the client is configured to accept and process the incoming electronic information in accordance with the hierarchical information contained electronic information, e.g., in a file header or an e-mail header.
In another embodiments, the above-described secure electronic communications server computer is further configured to provide at least one estimation of confidence in said authentication. In some more specific embodiments, this feature is provided in addition to the foregoing autosort feature. In other more specific embodiments, this feature is provided without the above-described autosort feature. Methods for generating such estimations are known among those having skill in the art.
In still more specific embodiments, the estimation of confidence is an Authenticity Quotient, which is defined herein as measure, numerical or non-numerical, of the confidence in the authenticity of the identity of a user on the system. In more specific embodiments, the Authenticity Quotient comprises a Registration AQ factor, i.e., a factor representing how the user in question was registered on the system, and a Signing AQ factor, i.e., a measure of the reliability of the sender's identity. In some more particular embodiments, the Registration AQ system is be used to identify a recipient as well; and the recipient must enter his (or her) Signature Code to access the desired information.
In still more specific embodiments, the Registration AQ measures the certainty that a registrant on the system is who they claim to. In one specific embodiment, the Registration AQ is determined by the method of registration. For example, the system:
In general, C) is stronger than B), and B) is stronger than A); so AQC>AQB>AQA. Still other methods will be apparent to those having ordinary skill in the art.
In other more specific embodiments, the Signing AQ measures the degree of certainty that an individual using a digital signature at the time of a transaction (i.e., the time the user sends electronic information) is indeed the individual registered to use that digital signature, or, more inclusively, that the individual is whom the digital signature is officially meant to represent. In some embodiments, the basis of determining the signing AQ is the method used to identify the user at the time of the transaction. Following are exemplary illustrative methods:
In general, D) is stronger than C), C) is stronger than B), and B) is stronger than A); so AQD>AQC>AQB>AQA. Still other methods will be apparent to those having ordinary skill in the art.
In another embodiment, at least one secure client computer is configured to receive instructions from the secure server computer to establish a secure connection with at least one additional secure server computer and receive secure electronic communications from the additional secure server computer(s). Such a connection can be direct or through intermediate servers and routers. Thus, for example, where the secure communication is an e-mail or file, the recipient's client e-mail application can be dynamically directed to retrieve the e-mail or file from a specific email server and request the delivery of said email or file directly from the that server, in effect generating a dynamic “peer-to-peer (P2P)” transaction.
For example with reference to
In another example, where the sending email is outside of a closed organization or enterprise, where the Sending party can often use and control its own Sending mail server, the Receiving mail server (or any interim servers) is (are) typically unknown and not controlled by the Sending party. This can be troublesome when the sending party considers the contents of an email sensitive material and doesn't wish to trust a third party with the information. It also requires that a third party server “relay” the email which creates unnecessary traffic for the Receiving mail server, as well as the network, where a direct send between the Sending mail server and User B email application would be more efficient. In some embodiments in which a “relay” transaction as just described is used, the receiving mail server can be part of the secure server. The methods and systems of the present invention provide two exemplary solutions:
Referring to
Referring now to
A combination of the two illustrative methods also allows the Sending mail server X to perform a local lookup (at Server X) to see if it has stored the address of User B's Receiving mail server; and, if so, to utilize Method 2 to send the email, and, if not, utilize Method 1 to send the email.
In each of the foregoing cases, the term “server” refers to a logical reference to either a single device or computer or a group of devices that together act logically as a server.
User registration can be accomplished using one of several modes: Active, Passive, Enterprise, Dynamic, or by Dynamic Credential Acquisition.
Referring to
Referring now to
Enterprises can be registered using either active or passive registration (just described), or through a manual process (e.g., by a sales person). When an enterprise is registered, the assumption is that there will typically be multiple individual users under the enterprise account. The enterprise itself has a top tier ID while each of these users can also represent different divisions of the enterprise, thus establishing a need for hierarchal identifiers. Enterprises can register secure mail servers which are meant to route mass mail, such as account statements, from the enterprise, or can allow individuals to register. When either type of entity is registered within the enterprise, that entity can be assigned a sub-tier ID within the hierarchy of the enterprises account. The combination of top tier IDs plus the lower tier IDs for any user account forms the identifier.
In some embodiments, registration is also accomplished using Dynamic Registration (DR). Dynamic registration leverages a preexisting internet account relationship to identify and authenticate a new user X on the system and to establish a trusted electronic relationship (TER) between two parties. Thus, for Dynamic Registration, user X already has a prior business relationship with business Y such that user X has a means by which to electronically authenticate user X's identity to business Y such as by logging into business Y's website. For example, a user X logs into an account management of a website (web or other computer interface). Once a user X is logged in, user X identified and user X can download software to enable exchange sensitive documents/files with the business Y which operates said site (as well exchange documents with other entities) and is pre-configured with user X's identity embedded in the code from within the user account management area of that site. When installed, user X's software will perform a handshake with the software installed at business Y (could be same or different server as used in previous steps). Then software at both business Y and user X will notify the secure sever that the other is now a credentialed exchange partner. The Secure server adds a record of the credentials to each said entities' accounts, noting the credentialed partner status. At any point after user X has logged into his account at Business Y, and during the setup session described above, the system may optionally prompt user X to choose an electronic signature (in the form or a secret pass code, signature code or other method). This can be through an exchange with Business Y or through an exchange with the server. In either case, the electronic signature is stored in the customer record at the CS and/or at Business Y and can be used to identity the user (as opposed to just the PC) in future file/document exchanges between the two parties.
Thus, when said user uses the software to exchange documents and files with business Y where the preexisting account relationship existed, the software can exchange credentials, effectively communicating the identity of user X to said business Y; and business Y is provided a high level of confidence that the identity of user X when exchanging files or documents with user X using the system. In addition, user X will also be provided a high level of confidence of the identity of business Y when receiving or exchanging documents with business Y. This can be done with a direct exchange of credentials by exchanging ID tokens where those tokens are cross referenced to an account on a database at Business Y (or user X) or by exchanging tokens and performing an identification lookup at the server (where the server has maintained a cross-referenced record of the user X account number at business Y), or a combination of both.
In another embodiment, DCA allows a user X who has previously installed the UDXSC software, but has not yet authenticated at business Z, to authenticate with business Z such that a TER is established between the two parties, i.e. business Z can now trust the identity of user X when communicating with user X using the system and so that user X can trust the identity of business Z when communicating with business Z.
Using DCA, a user X, who already has installed the above-described software, already has a prior business relationship with business Z such that user X has a means by which to electronically authenticate user X's identity to business Z such as by logging into business Z's website. User X logs into an account management area of a website (web or other computer interface). Once a user X is logged in, user X identified by business Z (i.e. because the user has authenticated when logging into business Z's website), UDXSC software on both sides (internet account server and user X side) can exchange IDs (or a cross-referenced version such as an email address or a combination thereof). Both applications send a secure electronic message to the UDX CS (central server) requesting that the other entity be added as a credentialed entity for that user's account. The CS records this in the appropriate customer records. Business Z then associates this ID with user X's existing user account at Business Z and stores this association as a record at the CS (this association can also be communicated and kept at the business Z, however, if user X's ID changes, then the association will no longer be valid thus a separate identifier, such as the email address can be used for the local association). Thus, when user X receives a document or file from business Z, software on user X's computer can display a visible icon or message stating that business Z is a credentialed exchange partner with user X and vice versa by performing a simple lookup at the server. Thus, both user X and Business Z are authenticated when exchanging files and documents in the same way as with Dynamic Registration above, but without downloading software.
In another embodiment, once a user is registered on the system as described above, that user has established some degree (depending on the method used) of a trusted electronic relationship (TER) on the system. This TER is between two parties where one user has used Dynamic Registration or DCA (both above) to establish that relationship. With both Dynamic Registration and DCA above, the two parties had prior TER, such as between a customer and that customer's online account at his bank, which was then leveraged to create TER on the described system of the invention.
The established TER in the system can also be leveraged in reverse to establish TER between two entities that does not exists at the time communication is established. For example, once a users identity is established on the system, that identity can be used to identify that user electronically to another entity where a prior TER did not exist.
Thus, using LATER, one entity can effectively act as a trusted authority for another entity on the system to establish the identity of new customers or simply to establish TER between the two parties.
When LATER is used between a business and a customer, the system can typically be used in two ways:
With LATER, two parties, User A and User B, would typically be enabled on the system, but have not established a TER. If one user entity using the system, for example, User A, has an established TER with a third party user, say User C, then User B could utilize the LATER system as follows. (Users described below have installed the above-described software and have records on the secure server. The following describes the logical communications and relationships among the parties using the installed software. Any one of the parties can be an individual or a business, however, typically user A would be an individual setting up an account with user B (a business) and leveraging a business relationship between user C (another business). User A and user C do not have established a TER (trusted electronic relationship) with each other, but do have a TER directly with the server (or the secure server) or another entity via the server.
User A requests to establish a TER with user B and forwards a unique identifier, which can be used to identify user A at the server, to user B along with other inputted (by the user) identifying information, such as name address, etc (7002). User B forwards the unique identifier and other identifying information to the server requesting authentication (7004). The server performs a lookup to determine if the information provided matches the identification information at the server, and then sends a verification (positive or negative) to user B (7006). Upon request by user B, the server can record user A as a trusted exchange partner (7008) and user X's email address, and other identifying information returned to user B by the server, is stored at user B associating user A with any account setup or other business relationship at user B. Note that technically, only one of either steps at the client or server is needed to establish the relationship (TER).
Using Method 1, the quality of the AQ established is the same between user B and user A as it was for whatever method user A initially established an identity with the server. This could be through a direct registration process with the server, or could be through a registration with another user, such as user C and user C has provided the server with personally identifiable information about user A which user C needs authenticated, such as physical address or possibly a social security number.
Using Authentication Partners as described above, user A has established an authentication partner, user C. The authentication partner would typically be a trusted institution, such as a bank, which has the capability of authenticating a user at a high confidence level, i.e., providing a high registration AQ and has done so to establish a registration AQ (or simply the identity of) user A. While typically a trusted institution, the authentication partner could be any other user on the system. The authentication partner, in effect, acts as a reference or witness to user A's identity when user A is establishing a new TER with another entity in this case, user B. User A could choose other users, where a TER has been established, on the system to serve as secondary, or tertiary authentication partners and so on.
Referring now to
Optionally an electronic signature can be requested (8006). User A pings the server regularly. Because a transaction is active and user B has requested authentication (8008), the server responds to the regular ping of User A with a request to input an electronic signature (pass code or other) (8010). User A does so.
The server performs a lookup in user A's account and responds to user B with the address of user A's authentication partner (8012), user C and a unique registration transaction number. User B then directs a request, the message include the unique registration transaction number (8014), to User C requesting identification credentials such as address, telephone number etc (8016). User C. (using this method, user personal information is not stored at the server) runs a check against the server to make sure the transaction is legitimate using the unique registration transaction number. Upon a positive response, user C responds to user B with the requested information (8018) and can setup an account for user X, and notfies the server that at TER has been established between user A and user B (8020). The server records the relationship in the records for both user A and user B.
Using Method 2, the quality the AQ established (confidence level of the identification) is the same between user B and user A as it is between user A and user C.
The software, systems, and methods described herein can be implanted on a standard general purpose computer using methods known to those of ordinary skill in the art. A representative computer includes a central processing unit (CPU) which is coupled bidirectionally with random access memory (RAM) and unidirectionally with read only memory (ROM). Typically, RAM is used as a “scratch pad” memory and includes programming instructions and data, including distributed objects and their associated code and state, for processes currently operating on CPU. ROM typically includes basic operating instructions, data and objects used by the computer to perform its functions. In addition, a mass storage device, such as a hard disk, CD ROM, magneto-optical (floptical) drive, tape drive or the like, is coupled bidirectionally with CPU. Mass storage device generally includes additional programming instructions, data and objects that typically are not in active use by the CPU, although the address space may be accessed by the CPU, e.g., for virtual memory or the like. Each of the above described computers optionally includes an input/output source that typically includes input media such as a keyboard, pointer devices (e.g., a mouse or stylus) and/or network connections. Additional mass storage devices (not shown) may also be connected to CPU 32 through a network connection. It will be appreciated by those skilled in the art that the above described hardware and software elements, as well as networking devices, are of standard design and construction, and will be well familiar to those skilled in the art.
The present invention will be seen to provide systems, methods, and software for the exchange of electronic information securely and with confirmation of authenticity. Although various specific embodiments and examples have been described herein, those having ordinary skill in the art will understand that many different implementations of the invention can be achieved without departing from the spirit or scope of this disclosure. For example, encryption and decryption can be performed using a single software module or more than two software modules. The modules described herein can be implemented using a variety of techniques and can be part of the operating system as well as plug-ins. Still other variations will be clear to those having ordinary skill in the art.
This application claims priority under 35 U.S.C. § 119(e) to provisional U.S. Patent Application Ser. No. 60/791,792, filed 12 Apr. 2006; and U.S. Patent Application Ser. No. 60/795,479, filed 26 Apr. 2006. The disclosure of each of these provisional U.S. patent applications is incorporated herein by reference in its entirety and for all purposes.
| Number | Date | Country | |
|---|---|---|---|
| 60795479 | Apr 2006 | US |
