Patent Publication Number: US-11025580-B2

Title: Method, apparatus and product for delivery of electronic messages to electronically un-addressable entities

Description:
CROSS REFERENCE TO RELATED APPLICATIONS 
     This application claims the benefit of U.S. Application No. 62/701,201, filed Jul. 20, 2018, the disclosure of which is incorporated by reference herein. 
    
    
     BACKGROUND 
     Today electronic messages can be delivered to “electronically” addressable entities (i.e., email messages to email addresses, Short Service Messages (SMS) to cell phones, in-app messages to user ID&#39;s in various apps such as Skype, WhatsApp, etc., to name a few). Likewise, physical letters (otherwise called “snail mail” messages) can be delivered to physical postal addresses. 
     It is also not possible today to deliver electronic messages to physical postal addresses. Nor is it possible to deliver messages (electronically or otherwise) to hitherto un-addressable entities such as, for example, tax-payer identification numbers (TINs), Social Security Numbers (SSNs), credit card numbers, bank account numbers, vehicle registration identification numbers, or vehicle identification numbers (VINs), to name a few. 
     A sender may not always know an electronic address, such as an email address, of a receiver to which it may wish to send a message electronically, although it may know one or more non-electronic addresses or un-addressable identifiers associated with the receiver. In such instances, the sender may have no recourse other than to attempt a physical delivery of the message to the receiver. This may be inconvenient, impractical, or untimely to meet a deadline. 
     It is desirable to provide a system and method that addresses this problem by enabling electronic messages to be addressed and delivered electronically in a secure, and verified manner to physical addresses, such as postal addresses, and to otherwise non-addressable entities such as tax payer identification numbers, bank/credit account numbers, vehicle identification numbers, etc. It is to these ends that this invention is directed. 
     SUMMARY OF THE INVENTION 
     This invention affords a system and a method that enable senders to send messages electronically to a receiver for which the senders may have no electronic address for the receiver. In an embodiment this may be accomplished by sending an electronic message to the receiver via a service provider (“SP”) which is configured in accordance with the invention to store one or more addresses of entities associated with the receiver, identify the receiver from an address in the received message, determine one or more addresses associated with the intended receiver and route the message to the receiver using the one or more associated addresses. To facilitate this, senders, service providers and receivers may utilize a system and a software process in accordance with the invention to receive, process and send messages electronically to message receivers. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a diagram illustrating the architecture of a system in accordance with the invention for managing delivery of electronic messages, and illustrates how the components cooperate together; 
         FIG. 2  illustrates an embodiment of a process flow and components of a receiver entity ID creation/update process according to the invention; 
         FIG. 3  illustrates an embodiment of a message sending process according to the invention, showing how sender messages are routed to the appropriate receivers based on the sender&#39;s criteria; and 
         FIG. 4  is a detailed flow-chart of a process according to the invention illustrating an embodiment of how receivers may be identified using one or more entity IDs. 
     
    
    
     DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 
     High Level Overview 
     As will be described, the invention affords a system and process that enables a user (also called a receiver in this document) to associate multiple addresses (called entity IDs in this document) with a user/receiver. Entity IDs may be electronic addresses, such as email addresses or mobile telephone numbers, and non-electronic addresses such as home addresses, phone numbers, passport IDs, etc., to which electronic messages intended for the receiver may be addressed. Entity IDs corresponding to addresses may be associated with particular receivers after verification. Senders can send electronic messages to receivers by choosing one or more entity IDs associated with a receiver. Senders may also specify security criteria that must be adhered to in order for their messages to be viewed by the receivers. 
     In one aspect the invention may operate as follows: Message receivers (also, interchangeably, called “users” herein) may register entities they are associated with in an entity vault database. The entity vault database, which may be a relational database, may be maintained by the service provider. The entities may include electronically addressable entities such as email addresses, mobile phone numbers, etc., and may also include non-electronically addressable entities such as physical postal addresses, and un-addressable entities such as taxpayer identification numbers, etc. Each entity added by the user into the vault may be verified upon addition using various different mechanisms for different types of entities. 
     Message senders can send electronic messages to message receivers using software that is compatible with a protocol defined in accordance with this invention. Senders may specify the message content, including attachments of digitized files to the message, and send messages to one or more entities convenient for the sender with which receivers are identified, and may specify security parameters, if any, governing message delivery. 
     The system may look up specified entities in the entity vault database, and identify one or more receivers to which the message should be delivered. If a receiver meets the security criteria specified by the message sender for message delivery, the receiver will be able to access the message electronically in a system-provided application (using, for example, a mobile application, a desktop application, or other applications on other devices). 
       FIG. 1  is an example of an embodiment of a system in accordance with the invention where a system controller  10  connects with a plurality of n receivers  12  having associated entity IDs stored after verification in an entity vault database  14 , such as a relational database, and may connect with a plurality of m senders  16 . The system controller may comprise a processor and memory embodying executable instructions for performing a method as described herein, and along with the entity vault database may comprise a service provider providing electronic messaging services. The system of  FIG. 1  enables one or more senders  14  to send electronic messages to one or more receivers  12  by addressing the messages to one or more of a receiver&#39;s entity IDs, including, as will be described, entity IDs which are otherwise not capable of being addressed electronically. 
     The system of  FIG. 1  may comprise several components that perform different functions. These may include, in the embodiment shown, receivers  12  that create/update entity IDs (such as, for example, their email addresses, home addresses, card/bank accounts, tax payer ids, etc.) associated with the receivers. In addition, receivers may also create security parameters which may include a security passphrase and also account passwords. Cryptographic key pairs may be associated with each verified entity ID and may be used to decrypt messages or verify cryptographic signatures as the case may be. Each receiver is responsible for carefully safeguarding its password, security passphrase and private keys. 
     Additionally, each entity ID that is associated with a receiver may be verified by an entity verification system, an embodiment of which is shown and described in connection with  FIG. 2 . Verified entity IDs of a receiver  12  may be stored in the receiver entity vault database  14 , which may be a relational database, and associated with that receiver.  FIG. 3  illustrates an embodiment of a message sending process. The processes of  FIGS. 2 and 3  illustrate examples  20  of verified entities and security parameters. The processes may operate together to send messages, as will be described. 
     Senders may communicate electronic messages to receivers using particular predetermined criteria. Considering a sender process, the system and method may comprise different components and functions. These may include, for example, the following. Senders who desire to send messages to receivers may specify the message criteria, such as message content, the receivers (by entity ID) and security criteria, if any, that the receivers must meet to access the message. The receiver criteria may be used by the system controller to identify a set of one or more users/receivers to which messages are to be delivered. Once a receiver/user has been notified of a message by a message delivery system, access to the message by the receiver/user is controlled by the security criteria specified by the sender, examples of which are described below. Receivers who do not meet the security criteria may not be given access to the message.  FIG. 1  illustrates examples of some receiver criteria and parameters  20  that may be used. 
     Receiver Entity ID Registration and Verification 
       FIG. 2  illustrates an embodiment of a receiver entity ID registration and verification process and system according to the invention. A receiver entity registration/update system comprising executable instructions running on the processor of the system controller  10  may handle entity ID creation and updates for the receivers. Receivers may add and/or update, and verify their entity IDs. Each such entity ID is processed by an entity verification system  24  which may perform a variety of different custom verification processes (verifiers) that may vary and be dependent on the type of entity ID. Thus, for example, physical (e.g., postal) addresses may be verified by a physical address verifier, as will be described. A receiver may have many different entity IDs associated with it. Each entity ID type may have one or more verifiers associated with it for verifying the entity ID&#39;s association with the receiver. 
     The addressability of entities, as used herein, may be defined as follows: (1.) electronically addressable: An entity is electronically addressable if the receiver can receive electronically messages addressed to that entity; and (2.) not electronically addressable: This includes all other entities which cannot receive electronic messages addressed to them, e.g., postal address, or bank account or credit card numbers. Such entities cannot receive electronic messages today. 
     The following table shows a list of possible entity IDs and their associated verifiers (there may be many others) which the invention may employ: 
     
       
         
           
               
               
               
             
               
                   
               
               
                 Entity ID 
                 Electronically 
                   
               
               
                 Type 
                 Addressable? 
                 Verification Process 
               
               
                   
               
             
            
               
                 Email 
                 Yes 
                 Verification code may be sent to specified email 
               
               
                 Address 
                   
                 address. Receiver must enter verification code to 
               
               
                   
                   
                 verify said address. 
               
               
                 Mobile Phone 
                 Yes 
                 Verification code may be sent via Short Message 
               
               
                 Number 
                   
                 Service (SMS). Receiver must enter verification 
               
               
                   
                   
                 code to verify said phone number. 
               
               
                 Land Line 
                 No 
                 Verification code may be sent via voice call to a 
               
               
                 Phone 
                   
                 receiver. Receiver must enter verification code to 
               
               
                 Number 
                   
                 verify said phone number. 
               
               
                 Physical 
                 No 
                 Three verification processes for physical 
               
               
                 Postal 
                   
                 addresses (among others not listed) may be used: 
               
               
                 Address 
                   
                 Process 1: Verification code may be sent via a 
               
               
                   
                   
                 physical letter delivered by appropriate 
               
               
                   
                   
                 postal/courier service to specified physical 
               
               
                   
                   
                 address. Receiver enters code upon receipt of 
               
               
                   
                   
                 letter to verify said address. 
               
               
                   
                   
                 Process 2: GPS location of a mobile phone 
               
               
                   
                   
                 matches the geocoded location of specified 
               
               
                   
                   
                 address. 
               
               
                   
                   
                 Process 3: Peer-to-peer delivery of electronic 
               
               
                   
                   
                 code. In this case, a “nearby” receiver - called a 
               
               
                   
                   
                 “neighbor” or “peer” may receive an encrypted 
               
               
                   
                   
                 code electronically on behalf of an intended 
               
               
                   
                   
                 receiver. The “neighbor” then delivers the 
               
               
                   
                   
                 encrypted code either physically or via paired 
               
               
                   
                   
                 Bluetooth connection to mobile device to intended 
               
               
                   
                   
                 receiver, which decrypts (with its private key) the 
               
               
                   
                   
                 code to obtain the actual verification code. 
               
               
                   
                   
                 Receiver enters code upon decryption to verify 
               
               
                   
                   
                 said address. 
               
               
                 Financial 
                 No 
                 Standard account verification mechanisms may be 
               
               
                 Entity IDs 
                   
                 used whereby users are asked to provide account 
               
               
                 (credit card, 
                   
                 information details (known only to an authorized 
               
               
                 bank account 
                   
                 owner of the account) such as account balance, or 
               
               
                 ids, crypto- 
                   
                 specific transaction details (amounts, etc.). Only 
               
               
                 currency 
                   
                 upon providing the correct information is the 
               
               
                 wallet ID) 
                   
                 account number considered to be verified. 
               
               
                 Tax Payer ID 
                 No 
                 A receiver uploads digitized social security or tax 
               
               
                 (Social 
                   
                 payer ID cards. A verification algorithm on the 
               
               
                 Security 
                   
                 uploaded card, along with other system checks, 
               
               
                 Number, etc.) 
                   
                 may be performed to validate that the card 
               
               
                   
                   
                 belongs to this receiver. 
               
               
                 Vehicle 
                 No 
                 Receiver plugs into a system-provided device 
               
               
                 Identification 
                   
                 such as an OBD scanner or the like having an app 
               
               
                 Number (VIN) 
                   
                 to an “on-board diagnostics” (OBD) port of the 
               
               
                   
                   
                 user&#39;s vehicle. System-provided app reads the 
               
               
                   
                   
                 VIN and approves or rejects specified value. 
               
               
                 Driver&#39;s 
                 No 
                 Receiver uploads digitized image of user&#39;s driver&#39;s 
               
               
                 License ID, 
                   
                 license or passport or other government issued 
               
               
                 Passport ID 
                   
                 photo ID. A verification algorithm on the uploaded 
               
               
                   
                   
                 file, along with other checks, may be performed to 
               
               
                   
                   
                 validate that this document belongs to this 
               
               
                   
                   
                 user/receiver. 
               
               
                 System- 
                 No 
                 The system generates unique tokens - at the 
               
               
                 generated 
                   
                 request of the receiver. Tokens may be unique 
               
               
                 token ID 
                   
                 alphanumeric strings. No additional verification is 
               
               
                   
                   
                 necessary because these tokens are generated 
               
               
                   
                   
                 by the system for authenticated receivers only. 
               
               
                   
                   
                 Receivers can affix/attach/stick such tokens to 
               
               
                   
                   
                 physical goods (like passports, physical key 
               
               
                   
                   
                 chains, etc.) 
               
               
                   
               
            
           
         
       
     
     As shown in the table above, each entity ID that the receiver adds for addressing purposes is subject to a verification process (outlined in the third column). Once an entity ID is verified and associated with a user, it then becomes an “addressable” entity ID to which senders can direct messages that may be received by receivers with appropriate software application. Preferred verifiers and their operations are described below. 
     Physical Address Verification or Enforcement Via GPS Geocoding Match 
     A receiver&#39;s physical address must be verified as an authenticated address belonging to the receiver. This may be done during the Entity ID verification step, an example of which is as follows. When a receiver receives a message, if the sender has specified geographic constraints, for example, the system may verify that the receiver is at the specified physical geographical location before allowing the receiver/user to view the message. This may be done, for instance, in a system-provided mobile application that may operate as follows. Assuming A is the physical address of a receiver that must be verified or enforced, a GPS location (G) of the receiver&#39;s mobile device may be obtained. Next, the physical address A may be geocoded to yield latitude/longitude coordinates G′, and G and G′ may be compared. If G matches G′ the physical address can be verified as valid. 
     Physical Address Verification Via Peer-to-Peer Code Delivery 
     Another approach is to verify a physical address by a “peer-to-peer” approach. The following are exemplary steps that may be taken. Assuming A is the physical address that must be verified for a receiver R. The system may identify “nearby” receivers who have been previously authenticated users in the system. One or more of the nearby receivers may be sent an electronic message with an encrypted code, e.g., a number, intended for R. The encrypted code may be created, for example, by encrypting the number using a public key for R. One or more of the nearby receivers may physically deliver the encrypted code to R at the physical address A as a physical representation the encrypted code. Alternatively, the code may be transmitted via a paired Bluetooth connection from the neighbor&#39;s mobile device to R′s mobile device. 
     Tax Payer ID Verification 
     A tax payer ID, such as a Social Security Number, or a Taxpayer Identification Number, may be verified as follows. A user/receiver may upload an image of the user&#39;s government-issued tax payer document and use the image for validation. In addition, for validating the uploaded image, the system may query third party services such as credit bureaus to form a set of challenge questions that would be known only to the user, such as certain account ownership information, previous residence addresses, etc. The receiver would have to successfully respond to the challenge questions to establish that it is indeed the true owner of the specified tax-payer ID. 
     Vehicle Identification Number (VIN) Verification 
     A VIN number associated with a user/receiver may be verified as follows. A receiver may enter a VIN number to be verified. The receiver may then connect an OBD (“On Board Diagnostics”) system-provided mobile scanner device having an embedded application to the vehicle. The application may then read the VIN number and upload it directly from the OBD scanner to the system. The system can read and verify that the uploaded VIN number from the scanner is the same as that entered by the user/receiver. 
     Driver&#39;s License, Passport ID or Government-Issued Photo ID Verification 
     Government issued photo ID&#39;s may be verified as follows. A user/receiver may upload a recent photo of the receiver/user to system. The receiver then may upload one or more images of relevant pages of its government-issued photo ID&#39;s. The uploaded images may be compared by the system for a match with the uploaded photo. If the match is ambiguous (e.g., photos are old, etc.), human intervention may be applied and verification may be done manually by the system provider. If they are available, third-party systems provided by governments may be queried to validate the information provided. 
     Sender Verification Process 
     In an embodiment, senders may also be verified, as when they register with the system. During an on-boarding registration process, a sender&#39;s email address, domain name (if any) and phone number (if any) may be verified by standard means. Two senders cannot have the same email address, domain name or phone number. Messages sent by a sender may be displayed along with message envelop metadata or other information which comprises email address, domain name and/or phone. Business senders may be required to have domain and phone numbers registered, and possibly may provide business registration documents for review and approval. 
     Senders, at their option, may specify Internet Protocol (IP) addresses from which their messages originate as an additional check on the authenticity of messages sent. This is valuable, for example, for financial institutions, or government agencies (such as taxing authorities) because it is very important for receivers to trust the authenticity of the sender. Where such additional IP address constraints are used, the system may enforce message authenticity by ensuring that such requests originate from the specified IP addresses. 
     Sender Message Sending Process 
       FIG. 3  illustrates an embodiment of a message sending process in accordance with the invention. A sender  16  may send messages to one or more receivers  12  within the system via the system controller  10  and a message delivery system  30  which delivers the messages to the intended receivers. To do this, the sender  16  sends messages to the system controller which specify message parameters and criteria, such as message content, receiver information and security criteria (if any). Upon verification of the receiver entity IDs in the messages using the receiver entity vault database, the system controller may send the messages to the message delivery system  30  for delivery to the intended receivers/users in accordance with the message parameters and criteria. The following are examples of parameters and criteria. 
     Message content can be a plain-text digital file, or it can be in Portable Document Format (PDF), or it may be digitized image files in a standard image format. Receiver information supplied for a receiver may comprise one or more entity IDs as a message address. If multiple IDs are provided, then, in an embodiment, all entity IDs supplied must match in order to send a receiver the message. Examples of entity IDs may include the following, among others:
         a) “123 Any Street, Anytown, NY 12345”;   b) “ABA:021000021:123456789”—bank account at J P Morgan Chase NA identified by its ABA routing number.   c) “1234567891234567”—credit card number.   d) “123 One More Ave., PA 01234” and “212-555-1212”. Two entity IDs are specified here—a physical address and a telephone number. In an embodiment, both entity IDs must match the receiver&#39;s verified entity IDs in order to successfully identify the receiver. In another embodiment, fewer than all entity IDs must match,   e) An entity ID may be a system-generated token ID such as “ABC123456789” for example.   f) Alternately, the sender can also specify “wild-card” parameters such as “All receivers in a particular postal code.”       

     Security criteria that may be specified may include, for example whether the message may only be viewed by the receiver at (one of) their registered physical address. For example, a bank may be interested in notifying users of important account changes (such as the addition/deletion of beneficiaries) but specify that such messages must be viewed by the named user/receiver at the home address only. Other security criteria may be whether the receiver should be required to decrypt the message with the receiver&#39;s private key; whether the message is ephemeral, and, if so, how many seconds after viewing or sending will it be automatically deleted; and verifier text comprising a shared secret between sender and receiver/user may also be used. Thus, for example, if the user spent $12.60 using a credit card, verifier text could be a message from a credit card sender with a verifier text such as “Confirm that you spent $12.60 on May 1, 2019 using card ending in x1234.” Only if the user recognizes the verifier text and assents to the actual message content (assuming all other checks have passed successfully) is the user verified. 
     Receiver Identification Process 
       FIG. 4  is an example of an embodiment of a receiver identification system flow and logic process  40  in accordance with the invention. Upon receiving a message from a sender, the system may first validate the sender, and then look through the entity vault database  14  for receivers that match one or more receiver entity IDs specified by the sender. If multiple entity IDs are provided by the sender, then, as noted above in accordance with an embodiment, all entity IDs may be required to match in order to identify a receiver and validate the sender. If an appropriate entity ID is found, it must be one that has been verified. The system may be configured to not deliver messages to unverified entity IDs or from un-validated senders. 
     The receiver identification process of  FIG. 4  checks, in turn, each of one or more entity IDs supplied by the sender of a message, and uses the results to identify the receiver for delivery of the associated message. In an embodiment, the process may be used to validate the sender of the message by requiring the sender to specify multiple entity IDs of the intended recipient that the system can confirm as being associated with the receiver. 
     An advantage of requiring senders to use multiple entity IDs to select a recipient and validate a sender is that this may be used to eliminate phishing and SPAM messages. Phishing messages are those wherein scammers mimic the appearance of legitimate messages from legitimate senders in order to trick the recipient to take an action that leads to them being defrauded, and SPAM messages are unwanted solicitations. Legitimate senders will likely know more information about the user/recipient to which their messages are addressed that was gathered in the normal course of commerce or interaction with the user, and, therefore, will know more than one entity ID associated with the user. For example, a bank will know about the various accounts belonging to their customer at that bank, and other information such as the customer&#39;s email address, phone number, tax payer ID number, etc. Fraudsters, by contrast, will likely not know multiple entity IDs associated with a user. Thus, while a legitimate sender can likely specify multiple entity IDs that must match to identify a recipient, a fraudster will likely specify only one entity ID to identify a recipient. By requiring legitimate senders to specify multiple entity IDs when they send messages, the system may easily validate the sender and classify as “junk” and avoid sending messages that specify only a single entity ID. Alternatively, the system may hold such messages in a “junk” folder, alert the receiver to their presence, and delete the messages after a selected period of time. 
     Message Delivery Process 
     Once a receiver has been identified, the receiver may be sent a notification from a message delivery system  30  to the receiver to access the message. Messages may be accessed by the receiver in a system-provided mobile application, for example, or using other suitable devices and applications such email clients, web browsers, etc. 
     Messages having geographic constraints may only be viewable using supported applications on devices that are enabled with GPS location services, i.e., such devices need to be equipped to connect to networks so that their GPS location can be determined. To enforce this constraint the user/receiver viewing device may transmit (via location services) its GPS location, and the sender must have specified a receiver entity ID physical address having geocoding that matches the specified GPS location. 
     Non-geographically constrained messages or messages for which no additional security criteria are specified may be viewed using applications on computers or other devices that do not have geographic location capability. 
     If the message has geographic constraints attached as part of the security criteria imposed by the sender, e.g., the message must be viewed at a registered physical address. The user may be notified of this and asked to view the message via a provided mobile application while at the specified physical location. If the content of the message has been encrypted, the user will be asked to enter a secure passphrase and/or appropriate private key(s) to decrypt the message contents. 
     Finally, the message delivery system may also enforce any post-message viewing or delivery constraints. For example, messages may be ephemeral and deleted following viewing or delivery after a predetermined number of seconds have elapsed. 
     The foregoing description has been with reference to particular embodiments of the invention. It will be appreciated, however, that these embodiments are merely examples illustrating the invention and that changes to these embodiments may be made with departing from the spirit and principles of the invention.