WO2011057139A2

WO2011057139A2 - Financial instrument processing via secure e-mail

Info

Publication number: WO2011057139A2
Application number: PCT/US2010/055722
Authority: WO
Inventors: Scott Moeller; John Eric Buchbinder; Alan Finke; Jeffrey Chen; Robert Renzulli
Original assignee: Mshift Inc.
Priority date: 2009-11-05
Filing date: 2010-11-05
Publication date: 2011-05-12
Also published as: WO2011057139A3

Abstract

The invention provides systems and methods for financial image/document processing via a secure communication, such as a secured e-mail. An intermediate entity may be provided between a remote device and a financial institution and/or back-end processor. The remote device may be registered with the intermediate server, which may set up the security/authentication protocols for securely transmitting a document/image from the remote device through the intermediate server to a financial institution and/or back-end processor. In some embodiments, the secure transmission may be in the form a secured e-mail, which may utilize S/MIME, TLS over ESMTP, or SSL over ESTMP.

Description

FINANCIAL INSTRUMENT PROCESSING VIA SECURE E-MAIL

CROSS-REFERENCE

[0001] This application claims the benefit of U.S. Provisional Application No.

61/258,573, filed November 5, 2009 and U.S. Provisional Application No. 61/264,637, filed November 25, 2009, which applications are incorporated herein by reference in their entirety.

BACKGROUND OF THE INVENTION

[0002] Remote deposit capture (RDC) is a convenient and efficient way to deposit checks and is becoming a critical component of an integrated payments platform. Banks and corporations and end users are now leveraging RDC for capturing payments made by checks as well as card transactions with coupon or invoice remittances. Corporations are depending more and more on RDC for updating billing and accounting systems with information extracted during the RDC process. At the same time corporations are evaluating ISO 20022 Financial Services - Universal financial industry message schemes for electronic payments via ACH and SWIFT.

[0003] A need exists for an application which enables RDC on mobile platforms using a format of secure communication.

SUMMARY OF THE INVENTION

[0004] The invention provides systems and methods for financial image/document processing via a secure communication, such as e-mail. Various aspects of the invention described herein may be applied to any of the particular applications set forth below or for other types of financial transactions or transactions involving sensitive or personal information. The invention may be applied as a standalone system or method, or as part of an application, such as an online banking system. It shall be understood that different aspects of the invention can be appreciated individually, collectively, or in combination with each other.

1. What is Remote Deposit Capture?

[0005] Remote deposit capture (RDC) is a service that allows a user to scan checks and transmit the scanned images and / or clearing data (e.g., bank routing number and account number) to a bank for posting and clearing. The basic requirements for an RDC service currently include a PC, an Internet connection, a check scanner and a service provider such as a user's current bank. Checks that a user may receive at the user's corporate or bank location can be scanned to create a digital deposit. This digital deposit may then be transmitted (over an encrypted Internet connection) to the user's RDC bank or service provider who then accepts the deposit, posts the deposit to the user's account and assigns availability based upon the user's availability schedule

[0006] Remote deposit capture may have different names depending upon how the service is applied within a particular environment. These names may include but are not limited to "Corporate Capture," "Merchant Capture," "Image Deposits," and "Image Cash Letters." In general, the term "remote deposit capture" may be increasingly used as the catch-all phrase for a family of related products and services. Each of these service family members may be related in a common way: The service may allow for checks to be truncated and cleared electronically.

[0007] Recent legislation in the USA commonly referred to as "Industry standard (e.g. Check-21)" makes this entire process possible. Passed in October 2003 and implemented in October 2004, this legislation allows banks to clear checks based upon images of the original items; instead of having to transport the original physical check all the way back to the paying bank for clearing. The benefits of RDC can be substantial: convenience, reduced transportation risk & cost, better availability, processing efficiencies, the ability to consolidate banking relationships and more.

2. The Standard Remote Deposit Capture Process

[0008] Depending upon functionality and degree of incorporation into corporate or bank operations, the RDC process can range from extremely basic to becoming a part of an automated receivables processing platform. In a basic application, an example of RDC process from a corporate perspective may be provided as follows:

1. ABC Corporation receives payments by check in the mail or at their office.

2. ABC Corp. performs their normal Remittance Processing process. This process includes opening the mail, data entry from the payment coupon / control document (application, form, invoice, etc.), data entry from the check (dollar amount, date, account number, etc.), and information uploads to the Accounts Receivables, Customer, and other databases.

3. Checks are then typically provided to the corporation's treasury area where ABC Corp. prepares a deposit (deposit ticket with total and accompanying checks). This process typically includes counting the number of checks and adding the value of checks at least twice to ensure the deposit is accurate and balanced.

4. With Remote Deposit Capture, instead of physically going to the bank to deposit the checks, ABC Corp. can now scan the deposit ticket and checks using a desktop scanner.

5. Once the check images are captured, a file (for eligible items) and/or an image-based deposit may be prepared. The RDC system can then transmit the deposit to ABC Corp's bank or a Industry standard (e.g. Check-21) intermediary. Typically, the transmission may be via FTP over the Internet as a strongly encrypted file (e.g., 1024 bit encryption), although other network transmission techniques can be used.

6. The Bank or the Industry standard (e.g. Check-21) intermediary receives the file and/or image deposit, posts to ABC Corp's account and assigns availability based upon an agreed upon availability schedule.

[0009] Behind the scenes, the bank has a few different options on how to clear the items. Checks converted to ACH transactions may be processed electronically. It is important to note, however, that for any and/or all checks converted to an ACH, National Automated Clearing House Association (NACHA) Rules are preferably adhered to. Effectively, there are two main issues to consider: 1) the writer / depositor of the check being converted may preferably be notified the check is being converted to an ACH transaction, and 2) not all checks are necessarily eligible for conversion.

[0010] For the non-ACH converted items the process can be a bit more complex. Unlike what most of the press has scared the public into believing (that checks now clear almost immediately), usually less than 25% of checks are cleared as images. The bank typically clears items captured via remote deposit capture by re-printing the images and clearing those re -printed paper documents. These re-printed checks are called Image Replacement Documents (IRDs).

[0011] While printing IRDs is not the ideal solution for any of the parties involved, until image clearing is widely adopted, this is a bank's only option. The Industry standard (e.g.

Check-21) law only mandates that a bank must accept an IRD in the clearing process if they are presented with one. The Check-21 law does not mandate that any banks take images of checks, clear images or return checks as images, but it does pave the way for innovation from the traditional ways checks are processed and cleared in the USA.

3. Image Quality

[0012] In accordance with an embodiment of the invention, check images (or images of other documents, such as financial documents) may be utilized in a remote deposit capture process. For check deposits, to be considered an "acceptable" image, a digital image must conform to the Federal Reserve's ANSI X9 standards (American National Standards Institute). These standards specify black and white (bitonal) images at 200 or 240 dots-per-inch (dpi) resolution. They are designed to maintain a standard for check exchange formats and file formats. In a distributed check processing environment, original checks may be replaced by their image at the very beginning of processing. As a result, all the clearing and processing activities rely on these images. If the image quality is poor and elements of the check are not readable, this can jeopardize the security, time and cost of the process. [0013] In a recent report, a sub-committee of the Financial Services Technology Corporation

(FSTC) identified and defined 16 metrics that can be used to ensure overall image quality. This report may be downloaded at www.fstc.org projects , which is hereby incorporated by reference in its entirety.

4. E-mail Protocols and Security

[0014] Virtually all human-written Internet e-mail and a fairly large proportion of automated e-mail are transmitted via Simple Mail Transfer Protocol (SMTP) in unsecured Multipurpose Internet Mail Extensions (MIME) format. Internet e-mail is so closely associated with the SMTP and MIME standards that it is sometimes called SMTP/MIME e-mail. In accordance with an embodiment of the invention, Extended Simple Mail Transfer Protocol (ESMTP) and Secure Multipurpose Internet Mail Extensions (S/MIME) may be leveraged in order to provide the secure transmittal of financial documents and/or images requiring security and/or secure transmission, such as the transmission of check images for remote deposit capture messages at the transmission protocol, transport and encapsulated encryption layers. In other embodiments, other e-mail or transmission techniques may be utilized, which may include other secured email or transmission methodologies.

[0015] In some embodiments, an intermediate entity (such as MShift Inc.), may use

Extended SMTP (ESMTP) for transmission of images/documents from any mobile device that may support the ESMTP transmission protocol to the intermediate entity's servers. By implementing this ESMTP in a method of image/document transmission as provided according to embodiments of the invention, ESMTP allows the intermediate entity to implement secure forms of encryption to encapsulate and secure the transmission of the data.

[0016] The underlying standards currently used are Transport Layer Security (TLS), Secure Sockets Layer (SSL), and Secure Multipurpose Internet Mail Extensions (S/MIME); however the functionality conveyed in this patent can be applied to other secure email standards that currently exist or which could be developed in the future and rely upon underlying security protocols to insure the delivery and receipt of emails in a secure fashion. Such security protocols may or may not include cryptographic protocols incorporating key agreement or establishment, entity authentication, symmetric encryption and message authentication material construction, secured application-level data transport, non-repudiation methods, and/or other techniques.

A. S/MIME

[0017] S/MIME (Secure/Multipurpose Internet Mail Extensions) is a standard for public key encryption and signing of e-mail encapsulated in Multipurpose Internet Mail Extensions

(MIME).

[0018] MIME is an Internet standard that extends the format of e-mail to support: • Text in character sets other than ASCII

• Non-text attachments

• Message bodies with multiple parts

• Header information in non- ASCII character sets

[0019] S/MIME may provide following cryptographic security services for electronic messaging applications: authentication, message integrity and non-repudiation of origin (using digital signatures) and privacy and data security (using encryption).

B. TLS and SSL

[0020] Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols that provide security for communications over networks such as the Internet. TLS and SSL encrypt the segments of network connections at the Transport Layer end- to-end.

[0021] TLS protocol allows client/server applications to communicate across a network in a way designed to prevent eavesdropping, tampering, and message forgery. TLS provides endpoint authentication and communications confidentiality over the Internet using

cryptography. In some embodiments, TLS may support a unilateral authentication. For example, the TLS-server side may hold a certificate for authentication, or the server may be authenticated in another manner.

[0022] TLS can also support a more secure bilateral connection mode (typically used in enterprise applications), in which both ends of the "conversation" can be assured with whom they are communicating (provided they diligently scrutinize the identity information in the other party's certificate). This is known as mutual authentication.

[0023] Mutual authentication may require that the TLS client-side also hold a certificate (which is not usually the case in the end-user/browser scenario). Unless, that is, TLS-PSK (pre- shared key), the Secure Remote Password (SRP) protocol, or some other protocol is used that can provide strong mutual authentication in the absence of certificates.

[0024] SSL operates in modular fashion. It is extensible by design, with support for forward and backward compatibility and negotiation between peers.

[0025] Other goals and advantages of the invention will be further appreciated and understood when considered in conjunction with the following description and accompanying drawings. While the following description may contain specific details describing particular embodiments of the invention, this should not be construed as limitations to the scope of the invention but rather as an exemplification of preferable embodiments. For each aspect of the invention, many variations are possible as suggested herein that are known to those of ordinary skill in the art. A variety of changes and modifications can be made within the scope of the invention without departing from the spirit thereof.

INCORPORATION BY REFERENCE

[0026] All publications, patents, and patent applications mentioned in this specification are herein incorporated by reference to the same extent as if each individual publication, patent, or patent application was specifically and individually indicated to be incorporated by reference.

BRIEF DESCRIPTION OF THE DRAWINGS

[0027] The novel features of the invention are set forth with particularity in the appended claims. A better understanding of the features and advantages of the present invention will be obtained by reference to the following detailed description that sets forth illustrative embodiments, in which the principles of the invention are utilized, and the accompanying drawings of which:

[0028] FIG. 1 shows a system with client devices interacting with a server over a network.

[0029] FIG. 2 shows a block diagram of a registration process in accordance with an embodiment of the invention.

[0030] FIG. 3 shows a sequence diagram of a registration process using S/MIME in accordance with an implementation of the invention.

[0031] FIG. 4 shows a sequence diagram of a registration process using SSL or TLS and ESMTP security in accordance with another implementation of the invention.

[0032] FIG. 5 shows a block diagram of a runtime process in accordance with an embodiment of the invention.

[0033] FIG. 6 shows a sequence diagram of a runtime process using S/MIME in accordance with an implementation of the invention.

[0034] FIG. 7 shows a sequence diagram of a runtime process using SSL or TLS and

ESMTP security in accordance with another implementation of the invention.

[0035] FIG. 8 shows a sequence diagram of a runtime process using SSL or TLS and

ESMTP security with a third party server in accordance with another implementation of the invention.

DETAILED DESCRIPTION OF THE INVENTION

[0036] While preferable embodiments of the invention have been shown and described herein, it will be obvious to those skilled in the art that such embodiments are provided by way of example only. Numerous variations, changes, and substitutions will now occur to those skilled in the art without departing from the invention. It should be understood that various alternatives to the embodiments of the invention described herein may be employed in practicing the invention.

[0037] The invention provides systems and methods for financial image/document processing via a secure communication, such as e-mail. Various aspects of the invention described herein may be applied to any of the particular applications set forth below or for other types of financial transactions or transactions involving sensitive or personal information. The invention may be applied as a standalone system or method, or as part of an application, such as an online banking system. It shall be understood that different aspects of the invention can be appreciated individually, collectively, or in combination with each other.

[0038] An aspect of the invention provides methods for secured and encrypted transmission of images of financial instruments and sensitive documents from remote and/or mobile devices to intermediate servers for pre-processing and submission to financial institutions and back-end document processors for automated processing.

[0039] FIG. 1 shows a system with client devices 100a, 100b, 100c interacting with a server 102 over a network 104. In some embodiments, the server may be a financial instrument processing server that may have software 106 stored in memory. In some embodiments, the client devices may be remote devices interacting with an intermediate entity server over a network. The client devices may include mobile devices, which may include but are not limited to a mobile phone (e.g., iPhone, or other smartphone device), a personal digital assistant (PDA), laptop computer, pager, any other networked device, or any device that may communicate wirelessly or with a satellite or tower. Remote devices may also include a personal computer, netbook or similar cloud computing device, server computer, scanner, camera, a wireless device such as a wireless e-mail device or other device capable of communicating wirelessly with a computer network; or any other type of network device that may communicate over a network and capture, store and/or send images. The remote device may include a camera component, or may be able to capture, store and/or send images. The remote device may be able to capture and/or send image files (such as check images), financial documents, sensitive documents, or documents of any other type as discussed herein. Any description of any client/remote device herein may also apply to any other type of client/remote device. The client device may have one or more affiliated end user. For example, a user may use an iPhone, using any of the

methodologies described herein.

[0040] The intermediate entity may or may not be a separate company from a financial institution. In some instances, the intermediate entity may be a company (e.g., MShift Inc.). The intermediate entity may have one or more servers. Each of the intermediate entity servers may or may not be able to communicate with one or more of the client devices in the system. [0041] The network may include but is not limited to a wide area network, such as the

Internet, a local area network (LAN), a private network, intranet, VPN functionality,

communication or telecommunications network, or any other network for connecting one or more client devices to one or more intermediate server. In some embodiments, the secure documents may be exchanged internally within a corporation, group or network. Any of the connections between the client devices and server may occur over the same network or over different network. Wired or wireless connections may be provided. Any description of any specific type of network (e.g., the Internet) may also apply to any other type of network.

[0042] Another aspect of the invention provides methods for prior secure registration of a specific remote and/or mobile device and an affiliated end user. Thus, the documents sent by a registered mobile device to an intermediate entity (which may be a company such as MShift

Inc.) as an intermediate processor may be encrypted and uniquely identified as belonging to the affiliated end user. The documents may be routed securely to an appropriate financial institution

(FI) or back-end processor with appropriate user credentials that may be required for automated back-end processing.

[0043] Methods may be provided in accordance with an implementation of the invention, whereby the images may be transmitted in an encrypted format from the mobile device to the intermediate server via e-mail using an S/MIME secure e-mail certificate. The S/MIME certificate may be provided by an intermediate entity to a unique remote/mobile device and/or affiliated user. The S/MIME certificate may be decrypted on the intermediate server or another securely connected server and can be pre-processed for transmission to the financial institution or back-end processor.

[0044] Another implementation of the invention may provide methods whereby the images may be transmitted via e-mail from the remote and/or mobile device to the intermediate server using an encrypting protocol with SSL or TLS under the ESMTP mail protocol. The e-mail may be encrypted by the e-mail sending program and decrypted by the e-mail receiving program or client then securely read on that intermediate server or another securely connected server. The e- mail may also be pre-processed for transmission to the financial institution or back-end processor.

[0045] Methods may also be provided whereby the images may be transmitted via e-mail from the mobile device to a third party server using an encrypting protocol with SSL or TLS under the ESMTP mail protocol. The e-mail may be encrypted by the e-mail sending program and decrypted by the e-mail receiving program at the third party server. The third party server may then forward that e-mail again using an encrypting protocol with SSL or TLS under the

ESMTP mail protocol to the intermediate server where it is securely read on that server or another securely connected server, and pre-processed for transmission to the financial institution or back-end processor. The e-mail may be encrypted by an e-mail sending program on the third party server and decrypted by an e-mail receiving program on the intermediate server.

[0046] Although secure transmission techniques such as S/MIME, TLS, and SSL are described, the functionality conveyed by these techniques can be applied to other secure email standards that currently exist or which could be developed in the future and rely upon underlying security protocols to insure the delivery and receipt of emails in a secure fashion. Similarly, other file transfer techniques than e-mail may also be utilized, including but not limited to file transfer protocol (FTP), Hypertext Transfer Protocol Secure (HTTPS), or secure FTP (sFTP). Such security protocols may or may not include cryptographic protocols incorporating key agreement or establishment, entity authentication, symmetric encryption and message authentication material construction, secured application-level data transport, non-repudiation methods, and/or other techniques.

[0047] Examples given below are primarily demonstrative of remote deposit capture of check images, but the technology may apply to additional key documents or data to be encrypted and sent from a mobile device using the aforementioned methodology. Some examples of additional applications include, but are not limited to: sending account opening documents (e.g., user identification documents, photo of user) from a mobile environment via these delivery channels to a financial institution, presenting a financial document such as a check from the mobile environment for validation and/or verification, or sending pertinent document, requiring encryption and security in the delivery channel such as signed/executed, transactional documents with intrinsic or material value, from mobile devices.

[0048] Other examples may include documents, which need to be executed and sent securely with a physical signature (i.e., where it may be permissible to keep the original and send a scanned version to the recipient). Other secure documents that may utilize these systems and methods may include files which may be transmitted or saved prior on a mobile device, but need to be transmitted securely to another entity (e.g., key PDF's, or even documents that can be edited at a later date, but need to be transmitted in a secure fashion). This may have applicability in Government/DOD/military applications as well as corporate applications. Financial instruments or other documents which need to be presented and/or verified, and/or validated prior to acceptance or use by either the transmitter or by the recipient institution may also be transmitted using the systems and methods described herein..

[0049] Any discussion of document or data transfer herein can be applied to a variety of digital images corresponding to checks (personal or business check images) from financial institutions or any hardcopy document outside of banking transactions. Other preferable embodiments of the invention can be directed to documents or digital images thereof such as deposit slips, bank statements, brokerage statements, legal documents, credit card bills, as well as tax documents or returns, driver's licenses, medical records or any other document containing personalized or sensitive information that a user may wish to hide or conceal from view on a computer or online. It shall be understood that the personalized or sensitive information need not be in the form of text, but may be rather a graphical image such as an illustration of an individual, fingerprint or biometric information. The documents secured in accordance with this aspect of the invention can originally exist as a paper hardcopy that can be scanned to create digital images, or the documents may be stored as digital images and stored in computer readable memory such as a computer hard drives, flash memory drives or other memory media. Any description of any type of document or data may also be applicable to other types of documents or data described herein.

[0050] Additional benefits and/or applications by securely sending document images may be realized. For instance, such communications can be utilized as logistical communications, receipt of delivery, and confirmation of documents that were sent. Secure documents that once had to be sent urgently via physical mail carriers such as FedEx or UPS may be sent

electronically in accordance with embodiments of the invention. The signature on the secure documents can be sent as an image captured by a remote device. The original may be retained while a scanned or photographed image may be sent via e-mail. Additionally, documents which are time specific and that require a specific date stamp may be sent electronically. Preferably, when the documents are e-mailed, they may be time-stamped to confirm the time of sending. Also, documents requiring confirmation of sending may also be sent electronically in accordance with the invention.

1. Registration Process

[0051] FIG. 2 shows a block diagram of a registration process in accordance with an embodiment of the invention. In some embodiments, the registration may be communicated with a financial institution in real time. Alternatively, the registration need not be communicated with the financial institution in real time. The financial institution may send an intermediate entity (e.g., MShift) a list of authorized accounts, or the intermediate entity may send a list of requests.

[0052] The diagram uses the designation of "Financial Institution," which may refer to the financial institution that will have ultimate receipt of the data/documents or the back-end processor. Any discussion herein of a financial institution may include a bank, credit union, trust company, mortgage-loan company, insurance companies, pension funds, brokers, underwriters, and investment funds. Furthermore, any discussion of a financial institution may also apply to any receiving entity that may receive secured and/or sensitive documents. The subsequent figures may primarily use remote deposit capture (RDC) of check images as an example of financial instrument processing. However, as previously discussed, other financial documents, or other types of documents may be processed and/or transmitted for various applications.

[0053] The registration block diagram of FIG. 2 shows a system with allows registration of a remote device in accordance an aspect of the invention. The system may include a remote device 200, an intermediate entity 202 (e.g., MShift), and a financial institution 204 (or any receiving entity). The remote device, the intermediate entity, and the financial institution may communicate with one another over a network. In some embodiments, the remote device may communicate with the intermediate entity via HTTPS 206. In some instances, the intermediate may communicate with the financial institution via TCP/IP 208. In some implementations, the remote device, intermediate entity, and financial institution may communicate directly with one another.

[0054] The network may be the Internet, any other wide area network, a local area network, or any other network described herein. Any of the connections between the various devices may occur over the same network or over different network. Any of the devices, such as the remote device, an intermediate entity server, and/or financial institution server may communicate wirelessly or over a wired connection.

[0055] In some instances, the remote device may be a mobile device. Some examples of a remote device may include but are not limited to a mobile phone (e.g., iPhone, or other smartphone device), a personal digital assistant (PDA), laptop computer, pager, any other networked device, or any device that may communicate wirelessly or with a satellite or tower, personal computer, netbook or other similar cloud computing device, server computer, scanner, camera, a wireless device such as a wireless e-mail device or other device capable of communicating wirelessly with a computer network; or any other type of network device that may communicate over a network and capture, store and/or send images. The remote device may include a camera component, or may be able to capture, store and/or send images. The remote device may be able to capture and/or send financial documents, sensitive documents, or documents of any other type as discussed herein. A remote device need not be mobile, and in some implementations may be relatively static. As previously mentioned, any discussion herein of a remote device or any particular type of remote device may be applicable to other remote devices.

[0056] A user who may own or use a remote device with image capturing and/or sending capability, or with an image(s) transmitted to or already stored on such device, may receive a contact, key, certificate and/or authentication token on the device. In some embodiments, the contact, key, certificate and/or authentication token may be stored in memory on the device.

[0057] The contact, key, certificate, and/or token may enable one or more image/document to be sent to an intermediate entity using an Internet connection or other communications means. The image/document may be sent from the remote device. Any tangible computer readable media with logic, code, data, instructions, may be used to implement any software or steps or methodology. Similarly, the intermediate entity and/or the financial institution may have one or more server that may include tangible computer readable media with logic, code, data, and instructions that may be used to implement any of the steps or methodology described herein. Any of the devices described herein, which may include the remote device, intermediate servers, and/or servers of any financial institutions or back-end processors may include memory that may store such computer readable media and/or logic, code, data, instructions, may be used to implement any software or steps or methodology.

[0058] Although one financial institution is shown by way of example, a remote device may communicate with multiple financial institutions through an intermediate entity. In some embodiments, a remote device may be communicating with one financial institution at a time. For example, the remote device may send check images to be deposited at one financial institution. Alternatively, it may communicate with multiple financial institutions at a time. For example, a remote device may be able to send a document (e.g., a change of address document) to multiple financial institutions at once.

[0059] The registration process may set up how financial documents may be transmitted. The secure transmission of financial documents may be implemented by any of the techniques described herein (e.g., S/MIME, TLS, SSL). Any other secure transmission techniques may be utilized to transmit secured documents. Secure transmission may be used to transmit a document from a remote device to an intermediate entity server and/or to transmit the document from an intermediate entity server to a financial institution and/or back-end processor. In some embodiments, secure transmission (which may include any of the techniques described) may also be used to transmit a document from an intermediate entity server to a remote device and/or to transmit the document from a financial institution and/or back-end processor to an intermediate entity server.

[0060] The registration process may involve verifying the user's identity, associating the user with a specific financial institution and back-end processor, and/or securely providing the user with information required to securely send documents via e-mail for back-end processing. A. Registration for Transmission using S/MIME Encryption

[0061] FIG. 3 shows a sequence diagram of a registration process using S/MIME in accordance with an implementation of the invention. In some embodiments, there may be a remote device 300, intermediate entity 302, and financial institution 304 that may communicate with one another. Any of the steps described herein may be optional and/or may be substituted with similar steps. Also, in some instances, the steps may be provided in the sequential order described, or there may be variations to the order of the steps.

1. End user may register a specific mobile device and personal identifying information with an intermediate entity (e.g., MShift) on a desktop based interface. Identifying information can include but is not limited to:

(a) E-mail address

(b) Financial institution (may be already known by the registration process)

(c) User specified account number(s) for deposits at the financial institution (FI)

(d) User and financial institution defined preference for mobile response channel for validation processes (e.g., e-mail, SMS, voice)

2. The intermediate entity may validate the end user and account with FI and/or back-end processor Such validation may depend on identifying information provided by the end user

3. The intermediate entity may generate a specific and unique identifying token for the end user, and generates an outbound e-mail directed to the end user. This e-mail message generated by the intermediate entity contains contact information for the intermediate entity and includes embedded in the contact information, the intermediate entity's S/MIME public key for secure e-mail provisioning. In some embodiments, the unique token may be distinct from what is sent in the e-mail. It may be stored on the intermediate entity server and may aggregate some or all of the required permissions and credentials needed to communicate with the FI and/or the check processor (processor). The FI and processor are distinct entities requiring separate logins and identifying information. The intermediate entity may have information that is not shared between those two entities.

4. End user may be directed to save the affiliated contact information data generated by the intermediate entity in the "Contacts" section of the address book on their mobile phone / mobile Internet access device. This process associates the intermediate entity's secure S/MIME public encryption key with any outbound e-mail sent by the user using the designated mobile device to the defined and designated intermediate entity e-mail server(s). 5. End user may be instructed in the registration process to use the intermediate entity preset contact containing the secure S/MIME key in all communications with the intermediate entity for secure delivery of data via the intermediate entity-defined channel.

6. End user may be instructed to always reply in the affirmative when asked by the mobile e-mail program whether a communication with the intermediate entity secure server should be encrypted.

7. Note: Registration sequence may be effective with mobile Internet devices which support the S/MIME standard. In other embodiments, other remote devices may be used which do not support the S/MIME standard, but that may utilize a similar security standard and/or protocol.

[0062] Additional descriptions and/or variations to the steps are provided herein. In accordance with an embodiment of the invention, the registration process may start with the registration of a remote device. For instance, an end user may register a specific mobile device and personal identifying information with an intermediate entity (e.g., MShift) on a desktop based interface. For example, the mobile device may be registered with the intermediate entity via any interface, which may include a web browser, a mobile device, or interactive voice response (IVR). The web browser or other interface may be accessed from the mobile device itself, or from another device (which may be another mobile device, computer, or any other remote device described herein).

[0063] Identifying information that may be provided during registration can include but is not limited to: e-mail address, financial institution (FI) information (which may be already known by the registration process), user specified account number(s) for deposits at the financial institution, user and financial defined preference for mobile response channel for validation processes (e.g., e-mail, SMS, voice), or user personal information (e.g., user name, date of birth, address of residence, social security number, credit card number, phone number).

[0064] The intermediate entity (such as MShift) may validate the end user and account with the FI and/or back-end processor. Such validation may depend on identifying information provided by the end user. In some examples, the intermediate entity may send one or more item of identifying information to the Fl/back-end processor. The Fl/back-end process may compare the identifying information with stored information that the Fl/back-end processor possesses. In some embodiments, validation may occur if said comparison yields a validation response (e.g., if the identifying information matches the stored information, is within a threshold of the stored information, or has a particular relation to the stored information).

[0065] The intermediate entity may generate a specific and unique identifying token for the end user, and may generate an outbound e-mail directed to the end user. This e-mail message generated by the intermediate entity may contain contact information for the intermediate entity and may include embedded in the contact information, the intermediate entity's (e.g., MShift's) S/MIME public key for secure e-mail provisioning.

[0066] In some embodiments, the unique token may be distinct from what is sent in the e- mail. It may be stored on the intermediate entity server and may aggregate some or all of the required permissions and credentials needed to communicate with the FI and/or the check processor (processor). The FI and processor may be distinct entities requiring separate logins and identifying information. The FI and processor may or may not share information. The intermediate entity may or may not have information that is not shared between the FI and the processor.

[0067] An end user may be directed to save the affiliated contact information data generated by the intermediate entity in the "Contacts" section of the address book on the end user's remote device (e.g., mobile phone / mobile Internet access device). Thus, a remote device may have a memory, storing information for the remote device address book. The contact information received by the intermediate entity may be stored in the remote device memory as part of the address book. The contact information from the intermediate entity may include a public encryption key that is stored on the remote device memory. This process may associate the intermediate entity's secure S/MIME public encryption key with any outbound e-mail sent by the user using the designated mobile device to the defined and designated intermediate entity e-mail server(s).

[0068] The end user may be instructed in the registration process to use the preset contact from the intermediate entity containing the secure S/MIME key in all communications with the intermediate entity for secure delivery of data via the intermediate entity-defined channel.

[0069] The end user may be instructed to always reply in the affirmative when asked by the mobile e-mail program whether a communication with the intermediate entity secure server should be encrypted. The end user may or may not choose to encrypt the communication. In some alternate embodiments, an end user may not be asked whether the communication is to be encrypted; a default condition may be provided, so that the communication with the intermediate entity may automatically be encrypted unless specified otherwise by the end user.

[0070] Registration sequence may be effective with mobile Internet devices which support the S/MIME standard. In other embodiments, other remote devices may be used which do not support the S/MIME standard, but that may utilize a similar security standard and/or protocol.

B. Registration for Transmission using SSL or TLS under ESMTP Encryption

[0071] FIG. 4 shows a sequence diagram of a registration process using SSL or TLS and ESMTP security in accordance with another implementation of the invention. In some embodiments, there may be a remote device 400, intermediate entity 402, and a financial institution 404 that may communicate with one another. Any of the steps described herein may be optional and/or may be substituted with similar steps. Also, in some instances, the steps may be provided in the sequential order described, or there may be variations to the order of the steps.

1. End user may register a specific mobile device and personal identifying information with an intermediate entity (e.g., MShift) on a desktop or mobile based interface. Identifying information can include but is not limited to:

a. E-mail address

b. Financial institution (May be already known by the registration process) c. User specified account number(s) for deposits at the financial institution (FI) d. User and financial defined preference for mobile response channel for validation processes (e.g., e-mail, SMS, voice)

2. The intermediate entity may validate the end user and account with FI and/or back-end processor. Such validation may depend on identifying information provided by the end user

3. The intermediate entity may create unique identifying credentials for the end user.

4. End user is informed of unique identifying credentials for use when e-mailing document images.

5. End user configures mobile device with credentials and configuration properties

including SSL or TLS information returned from registration.

[0072] Additional description and/or variations to the steps are provided as follows. At the start of the registration process, an end user may register a specific mobile device and personal identifying information with an intermediate entity (e.g., MShift) on a desktop or mobile based interface. For example, the mobile device may be registered with the intermediate entity via any interface, which may include a web browser, a mobile device, or interactive voice response (IVR). The web browser or other interface may be accessed from the mobile device itself, or from another device (which may be another mobile device, computer, desktop device, or any other remote device described herein).

[0073] Identifying information that may be provided during registration can include but is not limited to: e-mail address, financial institution (FI) information (which may be already known by the registration process), user specified account number(s) for deposits at the financial institution, user and financial defined preference for mobile response channel for validation processes (e.g., e-mail, SMS, voice), or user personal information (e.g., user name, date of birth, address of residence, social security number, credit card number, phone number). [0074] The intermediate entity (such as MShift) may validate the end user and account with the FI and/or back-end processor. Such validation may depend on identifying information provided by the end user. In some examples, the intermediate entity may send one or more item of identifying information to the Fl/back-end processor. The Fl/back-end process may compare the identifying information with stored information that the Fl/back-end processor possesses. In some embodiments, validation may occur if said comparison yields a validation response (e.g., if the identifying information matches the stored information, is within a threshold of the stored information, or has a particular relation to the stored information).

[0075] The intermediate entity may create unique identifying credentials for end user. In some embodiments, the identifying credential may be a way to authenticate a mobile device and/or end user of the mobile device. The credential may include passwords or other means of authentication, properties of a process that may be used for determining its access rights, certificates and associated key material, or identifying tokens.

[0076] The end user may be informed of unique identifying credentials for use when e- mailing document images. In some instances, the identifying credentials may automatically be applied when transmitting documents to an intermediate server, while in other embodiments, the user may select to include the identifying credentials.

[0077] The end user may configure the mobile device with credentials and configuration properties including SSL or TLS information returned from registration.

2. Runtime Process

[0078] In accordance with an aspect of the invention, this example shows a path for remote deposit capture (RDC) of check images in which an intermediate entity (such as MShift) may deliver the data delivered by an end user to the intermediate entity, and the intermediate entity may integrate with a back-end processor which performs as an Industry standard (e.g. Check-21) processor that may be incorporated within or communicate with a financial institution for the purpose of clearing checks.

[0079] FIG. 5 shows a block diagram of a runtime process in accordance with an

embodiment of the invention. An intermediate server 502 (such as an MShift server) may be between a device 500 and processor 504, or between a device 500 and FI 506. The intermediate server may be used because it can contain separate credentials to communicate with the FI and processor. The processor does not handle e-mails directly. The intermediate server may associate the different accounts with the user. For example, a particular end user may have accounts at one, two, or more financial institutions. Furthermore, a particular end user may use one, two or more remote devices for financial document processing. [0080] The runtime block diagram of FIG. 5 shows a system with allows communication between a remote device and other devices in accordance an aspect of the invention. The communication may include a transmission of a document or data from the remote device to the other devices. The system may include a remote device, an intermediate entity (e.g., MShift), a processor, and a financial institution. The remote device, the intermediate entity, the processor, and the financial institution may communicate with one another over a network. In some embodiments, the remote device may communicate with the intermediate entity via HTTPS, or secure email (e.g., S/MIME) 508. In some instances, the intermediate entity may communicate with the processor and/or financial institution via TCP/IP 510. Similarly, a processor and a financial institution may communicate with one another via TCP/IP 512. In some

implementations, the remote device, intermediate entity, processor, and financial institution may communicate directly with one another.

[0081] As previously discussed, the network may be the Internet, or any other wide area network, or may be a local area network. Any of the connections between the various devices may occur over the same network or over different network. Any of the devices, such as the remote device, an intermediate entity server, processor, and/or financial institution server may communicate wirelessly or over a wired connection.

[0082] In some instances, the remote device may be a mobile device. As previously mentioned, any discussion herein of a remote device or any particular type of remote device may be applicable to other remote devices.

[0083] A user who may own or use a remote device with image capturing and/or sending capability, or with an image(s) transmitted to or already stored on such device, may receive a credential on the device. The credential may have any of the characteristics described elsewhere herein. In some embodiments, the credential may be stored in memory on the device.

[0084] The credential may enable one or more image/document to be sent to an intermediate entity using an Internet connection or other communications means. The image/document may be sent from the remote device. Any tangible computer readable media with logic, code, data, instructions, may be used to implement any software or steps or methodology. Similarly, the intermediate entity, processor and/or the financial institution may have one or more server that may include tangible computer readable media with logic, code, data, and instructions that may be used to implement any of the steps or methodology described herein. Any of the devices described herein, which may include the remote device, intermediate servers, and/or servers of any financial institutions or check processors may include memory that may store such computer readable media and/or logic, code, data, instructions, may be used to implement any software or steps or methodology. [0085] Although one check processor and one financial institution are shown by way of example, a remote device may communicate with multiple check processors and/or financial institutions through an intermediate entity. In some embodiments, a remote device may be communicating with one check processor and one financial institution (or any other receiving entity) at a time.

[0086] The runtime process may allow the secure transmission of financial documents. The secure transmission of various documents may be implemented by any of the techniques described herein (e.g., S/MIME, TLS, SSL). Any other secure transmission techniques may be utilized to transmit secured documents. Secure transmission may be used to transmit a document from a remote device to an intermediate entity server and/or to transmit the document from an intermediate entity server to a financial institution and/or processor. In some embodiments, secure transmission (which may include any of the techniques described) may also be used to transmit a document from an intermediate entity server to a remote device and/or to transmit the document from a financial institution and/or processor to an intermediate entity server. Secure transmission may also be enabled between a processor and a financial institution. In some implementations, a third party server may be utilized. Communication to and/or from the third party server may be secure.

[0087] In some preferable embodiments, a document may be securely transmitted to an intermediate server, which may transmit it to a back-end processor (which may process and/or validate the document), which may transmit the processed document to a financial institution. The processor may process a document to clarify the document or enable the document to meet Industry standard (e.g. Check-21) standards. If the document can reach Industry standard (e.g. Check-21) standards, the processor may validate the document. If the document can not be made to reach Industry standard (e.g. Check-21) standards, the document may be not validated, and an additional document may be requested from the remote device.

[0088] There may be a many-to-many relationship between processors and FIs, and there may possibly be different accounts within one FI. The intermediate server may insure the right connections are made. One or more intermediate server may also handle image pre-processing that may be required for the processor to handle the graphic images from a remote device (such as a cell phone or other device as needed). For example, an intermediate server may clarify or clean up a graphic image from a remote device before it reaches a processor and/or financial institution.

[0089] Thus, in various embodiments, continued communications may occur through an intermediate entity between the remote device and check processor/financial institution.

Alternatively, the intermediate entity may act as an authority allowing communications between the remote device and check processor/financial institution by providing such capabilities to the remote device and/or the check processor/financial institution.

[0090] During runtime, the secure transmission of financial documents may be implemented by any of the techniques described herein.

A. Runtime Process using S/MIME

[0091] FIG. 6 shows a sequence diagram of a runtime process using S/MIME in accordance with an implementation of the invention. In some embodiments, a remote device 600,

intermediate entity 602, a processor 604, and a financial institution 606 may communicate with one another. Any of the steps described herein may be optional and/or may be substituted with similar steps. Also, in some instances, the steps may be provided in the sequential order described, or there may be variations to the order of the steps.

1. End user signs the document, (endorses the check) and fills out intermediate entity (e.g.,

MShift) and FI defined information in specified fields and takes a photo(s) of the first page(s) (front of check) with their mobile device

2. End user creates e-mail with photo image(s) attached and an agreed upon description in the subject line and/or body of the e-mail (such as the amount of a check)

3. End user selects the intermediate entity contact in the "Contacts" list on their mobile device that includes the embedded public key and selects the intermediate entity as the recipient of the e-mail. Note: end user can initiate the e-mail from step two or from step three and attach the photo(s) to the e-mail.

4. End user sends the e-mail and replies "yes" if prompted as to whether to encrypt the e- mail

5. E-mail client uses the intermediate entity predetermined S/MIME secure protocol to encrypt e-mail with the intermediate entity public key

6. Upon receipt of e-mail from end user, the intermediate entity decrypts using the

intermediate entity private key

7. The intermediate entity processes the image(s) delivered from mobile device to conform to back-end processor specifications (e.g., 200 dpi for RDC)

8. The intermediate entity submits first image(s) to FI or RDC processor and receives

success/error code

9. The intermediate entity sends the user a success/failure message(s) (via the method

selected during registration process) showing the result of scan(s): success with completion code, or failure with appropriate error description.

10. End user receives message: If error, repeat steps to send the first page(s)/front of check/ back of check. 11. End user repeats process with subsequent pages of documents (or back of check in case of RDC)

12. When entire document has been successfully transmitted and processed, the end user receives a confirmation message(s) via mobile channel such as e-mail, SMS, MMS, voice or other communication standard.

[0092] Additional descriptions and/or variations for the steps herein are provided as follows. In a first step, an end user may sign a document (e.g., endorse a check), or otherwise provide a document or data that the user wishes to send securely. The user may fill out intermediate entity (e.g., MShift) and/or financial institution (FI) defined information in specified fields of a user interface. In some embodiments, the user interface may be provided as a web browser. The user interface may be provided on a remote device, which may be a mobile device. The user may take a photo of the first page of the document (e.g., front of check) with their mobile device. Alternatively, the user may use another image capture device (such as a digital camera or scanner) to take a picture of the first page of the document and may send the captured image to their mobile device.

[0093] The end user may create an e-mail with the captured image/photo attached and an agreed upon description in the subject line and/or body of the e-mail. In one embodiment, the amount of a check may be provided in the subject line and/or body of the e-mail. In other embodiments, agreed upon description may also include user account information or information associated with the financial institution. For example, if a user has accounts at multiple financial institutions and/or the remote device is registered with multiple financial institutions, the user may specify which financial institution is receiving the captured image.

[0094] The end user may select the intermediate entity (e.g., MShift) contact in the

"Contacts" list on their mobile device. The contact may include an embedded public key and may select the intermediate entity as the recipient of the e-mail. The end user can initiate flow from the step of creating the email or from selecting the intermediate entity contact.

[0095] The end user may send the e-mail. In some embodiments, the end user may be prompted whether to encrypt the email. In such situations, the end user may preferably reply "yes," although the user may choose not to encrypt the email. In alternate embodiments, the end user need not be asked whether to encrypt the email, the email may be automatically encrypted, or some default setting may be used.

[0096] The e-mail client may use the intermediate entity's predetermined S/MIME secure protocol to encrypt e-mail with intermediate entity public key. The intermediate entity public key may be the key that was provided within the contact provided by the intermediate entity during registration. In some embodiments, the intermediate entity public key may be the same for every remote device that may register with the intermediate entity. Alternatively, they may be varied for different remote devices.

[0097] The e-mail may be sent to the intermediate entity. Upon receipt of e-mail from end user, the intermediate entity may decrypt the encrypted portion using the intermediate entity's private key. The private key may be able to decrypt information encrypted by the public key. Preferably, only the intermediate entity's private key can decrypt what the recipient's public key encrypts. The private key may preferably not be provided to any outside entity, so that only the intermediate entity would be decrypting the e-mail.

[0098] In some additional embodiments of the invention, the public/private key pairs may be generated by the intermediate entity or any S/MIME compliant provider. The key pairs may be authenticated by a certificate authority. The certificate authority may be a party trusted by the remote device and the intermediate server.

[0099] Additionally, in some implementations, digital signing may occur in addition to encryption. The following outlines a possible series of steps for an alternate embodiment of encryption and/or digital signing:

(a) using an e-mail recipient's (e.g., intermediate entity) digital certificate, stored in

internal memory of an e-mailer controller, a hash or message digest may be generated;

(b) the hash may then be encrypted using the sender's (e.g., remote device) public key to thereby create the remote device's digital signature;

(c) the digital signature is then attached to the original message (e.g., check image,

financial document, or other secured/sensitive document);

(d) a session key is generated;

(e) the session key may be used to encrypt the original message; and,

(f) the e-mail recipient's private key, may be used to encrypt the session key.

[00100] Hence what is transmitted via Internet, other e-mail networks or the like and thus received by the e-mail recipient may include, in general, (1) an encrypted message, (2) the digital signature and (3) the encrypted session key.

[00101] In an alternate embodiment, since the algorithms for public, private key pairs are computationally expensive, symmetric keys or the like, which are not computationally taxing can be used to encrypt the original message.

[00102] In order for the e-mail recipient (e.g., intermediate server) to review the e-mailed transmission of the original message, the recipient could (1) use the recipient's private key to decrypt the session key; (2) decrypt the original message using the session key; (3) decrypt the hash using the sender's public key; and, (4) re-hash the original, now decrypted, message. [00103] Preferably, only the recipient's private key can decrypt the session key. Additionally, preferably only the banking institutions (sender's) public key can decrypt the hash. Thus, when the e-mail recipient re-hashes the original message, if the two hashes (the one sent with the original message and the one created when the original message is re-hashed) are equal, then the message has not been altered during transmission through Internet, other e-mail networks or the like. However, if the two hashes are not equal, the original message has been changed and may be considered suspect.

[00104] The digital signing and encryption processes of the present invention may allow the e-mail recipient to know that the remote device is the entity actually sending the original message. In other words, since the keys are asymmetric, only the remote entity's key could be used to encrypt the hash. Otherwise, remote entity's key would not have successfully decrypted the hash and the two hashes would not compare equally.

[00105] Furthermore, the digital signing and encryption processes of the present invention may allow the e-mail recipient to know that the original message was sent in a form only retrievable by the recipient since the recipients' private key was used to decrypt the session key originally encrypted using the recipient's public key. Only the recipient's private key can decrypt what the recipient's public key encrypts. Since only the recipient has access to his own private key, only the recipient can decrypt the original message.

[00106] Such alternate embodiments may be useful in order to detect tampering or interceptions of the secured e-mail.

[00107] After decrypting the e-mail, the intermediate entity may process the image delivered from the mobile device to conform to end-processor specifications. For example, such specifications may include 200 dpi for RDC, or any other Industry standard (e.g. Check-21) related qualifications. In some instances, the intermediate entity may provide some preprocessing steps which may or may not reach Industry standard (e.g. Check-21) standards. In other embodiments, the intermediate entity need not perform any image processing steps.

[00108] The intermediate entity may submit the first image to a FI or an RDC processor and receives success/error code. In some embodiments, the image may be submitted to the processor, which may process the image and/or validate the image. Alternatively, a financial institution may perform the image processing and/or validation step. During the validation, the processor and/or financial institution may let the intermediate entity know whether the image was a success or failure.

[00109] The intermediate entity may send the user a success/failure message(s). The success/failure message may be sent via the method selected during registration process. For example, the success/failure message may be sent via e-mail, SMS, MMS, voice or other communication standard. In some embodiments, the success/failure message may be sent to the mobile device, while in other embodiments, the success/failure message may be sent to another device, whether the other device be another mobile device and/or a static device. The success/failure message may show the result of scan(s): success with completion code, or failure with appropriate error description.

[00110] The end user may receive the success/failure message. If the end user receives an error, the end user may repeat the steps to send the first page. The end user may repeat such steps until there is success.

[00111] If the end user receives a message of success, the end user may repeat the process with subsequent pages of documents (or back of check in case of RDC). If an error occurs during the transmission of any of the subsequent pages, the user may repeat the steps to send that page until success is achieved.

[00112] When entire document has been successfully transmitted and processed, the end user may receive a confirmation message(s) via mobile channel such as e-mail, SMS, MMS, voice or other communication standard. The end user may receive the confirmation via the method selected during the registration process. This may or may not be the same method that is used to transmit a success/failure message for a document page.

[00113] In some embodiments, multiple documents may be transmitted and processed at the same time. For example, a mobile device may capture multiple images (e.g., front and back of a check) and transmit them simultaneously. In some instances, any number of documents (such as images) may be transmitted at once. In some images, images from multiple checks may be transmitted at once. In some embodiments, the intermediate entity may batch process the documents. For example, if images from multiple checks for deposit are received (e.g., simultaneously) by the intermediate entity, the intermediate entity may batch process the deposits. This may provide greater speed and ease of deposits.

B. Runtime Process Using SSL or TLS using ESMTP

[00114] FIG. 7 shows a sequence diagram of a runtime process using SSL or TLS and ESMTP security in accordance with another implementation of the invention. In some embodiments, a remote device 700, intermediate entity 702, processor 704, and financial institution 706 may communicate with one another. Any of the steps described herein may be optional and/or may be substituted with similar steps. Also, in some instances, the steps may be provided in the sequential order described, or there may be variations to the order of the steps.

1. End user signs the document, (endorses the check) and fills out the intermediate entity

(e.g., MShift) and FI defined information in specified fields and takes a photo of the first page (front of check) or multiple pages (front and back of check) with their mobile device.

2. End user creates e-mail with photo image(s) attached and an agreed upon description in the subject line and/or body of the e-mail (such as the amount of a check).

3. End user clicks on the intermediate entity contact in the "Contacts" list on their mobile device or manually enters the e-mail address for the intermediate entity secure document mail box.

4. End user sends the e-mail.

5. E-mail client uses the SSL or TLS to encrypt the e-mail.

6. Upon receipt of e-mail from end user, the intermediate entity e-mail server decrypts the e-mail.

7. The intermediate entity processes the image delivered from mobile device to conform to end-processor specifications (e.g., 200 dpi for RDC).

8. The intermediate entity submits image(s) to FI or RDC Processor and receives

success/error code.

10. End user receives message: If error, repeat prior steps to resend the image(s).

11. If necessary, end user repeats process with subsequent pages of documents (or back of check in case of RDC).

[00115] Additional descriptions and/or variations to the steps are provided herein. In a first step, an end user may sign a document (e.g., endorse a check), or otherwise provide a document or data that the user wishes to send securely. The user may fill out intermediate entity (e.g., MShift) and/or financial institution (FI) defined information in specified fields of a user interface. In some embodiments, the user interface may be provided as a web browser. The user interface may be provided on a remote device, which may be a mobile device. The user may take a photo of the first page of the document (e.g., front of check) with their mobile device. Alternatively, the user may use another image capture device (such as a digital camera or scanner) to take a picture of the first page of the document and may send the captured image to their mobile device. [00116] The end user may create an e-mail with the captured image/photo attached and an agreed upon description in the subject line and/or body of the e-mail. In one embodiment, the amount of a check may be provided in the subject line and/or body of the e-mail. In other embodiments, agreed upon description may also include user account information or information associated with the financial institution. For example, if a user has accounts at multiple financial institutions and/or the remote device is registered with multiple financial institutions, the user may specify which financial institution is receiving the captured image.

[00117] The end user may select the intermediate entity (e.g., MShift) contact in the

"Contacts" list on their mobile device. Alternatively, the end user can manually enter the e-mail address for the intermediate entity secure document mail box.

[00118] The e-mail may be sent to the intermediate entity. The e-mail client may use SSL or TLS to encrypt the e-mail. In other embodiments, other cryptographic protocols may be used that can provide security for communications over networks. In some embodiments, encryption (e.g., SSL and TLS) may be used to encrypt the segments of network connections at the transport layer end-to-end.

[00119] In some embodiments, unilateral authentication may occur, where the server (e.g., intermediate server) may be authenticated to the client (e.g., remote device). This may occur when the client uses a certificate authority's public key to validate the certificate authority's signature on the server's certificate. A connection between the client and server may be negotiated using a handshaking procedure. For example, the client may connect to a TLS- enabled server requesting a secure connection, and may present a list of supported ciphers and hash functions. From the list, the server may pick the strongest cipher and hash function that it supports and may notify the client of its decision. The server may send back its identification in the form of a digital certificate. The certificate may contain the server name, the trusted certificate authority, the server's public encryption key. The client may contact the server that issued the certificate (the certificate authority) and may confirm the certificate is authentic before proceeding. The client may check that the issuing certificate authority is on a list of trusted certificate authorities and the server's certificate validity period. In this case, the intermediate server may be authenticated to a remote device.

[00120] In some other embodiments, bilateral authentication may occur, in which case the client side may also hold a certificate. Alternatively, TLS-PSK, the secure remote password (SRP) protocol, or some other protocol that can provide strong mutual authentication in the absence of certificates can also be used.

[00121] When the TLS or SSL connection is established, the client (e.g., remote device) and server (e.g., intermediate entity server) may exchange CipherSuite codes (or other comparable codes). This may specify a combination of cryptographic algorithms that can be used for the connection. A key exchange and authentication algorithm may be used during the handshake. Also, an encryption algorithm may be used to encipher the data for each block cipher of the message stream. A message authentication code (MAC) algorithm may create a message digest, which may be cryptographic hash of each block of the message stream. Both the client and server may generate key material for encryption and decryption.

[00122] Upon receipt of e-mail from end user, the intermediate entity may decrypt the encrypted portion. This may be done using the key material.

[00123] The intermediate entity may process the image delivered from the mobile device to conform to end-processor specifications. For example, such specifications may include 200 dpi for RDC, or any other Industry standard (e.g. Check-21) related qualifications. In some instances, the intermediate entity may provide some pre-processing steps which may or may not reach Industry standard (e.g. Check-21) standards. In other embodiments, the intermediate entity need not perform any image processing steps.

[00124] The intermediate entity may submit the first image to a FI or an RDC processor and receives success/error code. In some embodiments, the image may be submitted to the processor, which may process the image and/or validate the image. Alternatively, a financial institution may perform the image processing and/or validation step. During the validation, the processor and/or financial institution may let the intermediate entity know whether the image was a success or failure.

[00125] The intermediate entity may send the user a success/failure message(s). The success/failure message may be sent via the method selected during registration process. For example, the success/failure message may be sent via e-mail, SMS, MMS, voice or other communication standard. In some embodiments, the success/failure message may be sent to the mobile device, while in other embodiments, the success/failure message may be sent to another device, whether the other device be another mobile device and/or a non-mobile device. The success/failure message may show the result of scan(s): success with completion code, or failure with appropriate error description.

[00126] The end user may receive the success/failure message. If the end user receives an error, the end user may repeat the steps to send the first image. The end user may repeat such steps until there is success.

[00127] If the end user receives a message of success, the end user may repeat the process with subsequent images of documents (or back of check in case of RDC). If an error occurs during the transmission of any of the subsequent images, the user may repeat the steps to send that image until success is achieved. [00128] When entire document has been successfully transmitted and processed, the end user may receive a confirmation message(s) via mobile channel such as e-mail, SMS, or voice. The end user may receive the confirmation via the method selected during the registration process. This may or may not be the same method that is used to transmit a success/failure message for a document page.

C. Runtime Process Using SSL or TLS using ESMTP with third party server

[00129] FIG. 8 shows a sequence diagram of a runtime process using SSL or TLS and ESMTP security with a third party server in accordance with another implementation of the invention. In some embodiments, a remote device 800, third-party e-mail server 802,

intermediate entity 804, processor 806 and financial institution 808 may communicate with one another. Any of the steps described herein may be optional and/or may be substituted with similar steps. Also, in some instances, the steps may be provided in the sequential order described, or there may be variations to the order of the steps.

1 End user signs the document, (endorses the check) and fills out the intermediate entity

(e.g., MShift) and FI defined information in specified fields and takes a photo(s) of the first page(s) (front/back of check) with their mobile device.

2. End user creates e-mail with photo(s) attached and an agreed upon description in the subject line and/or body of the e-mail (such as the amount of a check)

4. End user sends the e-mail.

5. E-mail client uses the SSL or TLS to encrypt the e-mail sent to third party e-mail server.

6. Third party mail server forwards the e-mail using SSL or TLS to the intermediate entity e-mail server.

7. Upon receipt of e-mail from end user, the intermediate entity e-mail server decrypts the e-mail.

8. The intermediate entity processes the image(s) delivered from mobile device to conform to end-processor specifications (e.g., 200 dpi for RDC)

9. The intermediate entity submits first image(s) to FI or RDC Processor and receives success/error code.

10. The intermediate entity sends the user a success/failure message(s) (via the method

11. End user receives message: If error, repeat steps to send the first image(s). 12. End user repeats process with subsequent images of documents (or back of check in case of RDC).

13. When entire document has been successfully transmitted and processed, the end user receives a confirmation message(s) via mobile channel such as e-mail, SMS, MMS, voice or other communication standard.

[00130] Additional descriptions and/or variations to the steps are provided herein. In a first step, an end user may sign a document (e.g., endorse a check), or otherwise provide a document or data that the user wishes to send securely. The user may fill out intermediate entity (e.g., MShift) and/or financial institution (FI) defined information in specified fields of a user interface. In some embodiments, the user interface may be provided as a web browser. The user interface may be provided on a remote device, which may be a mobile device. The user may take a photo of the first page of the document (e.g., front of check) with their mobile device. Alternatively, the user may use another image capture device (such as a digital camera or scanner) to take a picture of the first page of the document and may send the captured image to their mobile device.

[00131] The end user may create an e-mail with the captured image/photo attached and an agreed upon description in the subject line and/or body of the e-mail. In one embodiment, the amount of a check may be provided in the subject line and/or body of the e-mail. In other embodiments, agreed upon description may also include user account information or information associated with the financial institution. For example, if a user has accounts at multiple financial institutions and/or the remote device is registered with multiple financial institutions, the user may specify which financial institution is receiving the captured image.

[00132] The end user may select the intermediate entity (e.g., MShift) contact in the

[00133] The e-mail may be sent to a third party e-mail server. The e-mail client may use SSL or TLS to encrypt the e-mail. In other embodiments, other cryptographic protocols may be used that can provide security for communications over networks. In some instances, the e-mail may be encrypted using the third party's secure methodology.

[00134] The third party e-mail server may forward the e-mail using SSL or TLS to the intermediate entity e-mail server. In other embodiments, other cryptographic protocols may be used that can provide security for communications over networks. Alternatively, the e-mail may be encrypted using the third party's secure methodology.

[00135] In some embodiments, one third party e-mail server may be provided between the remote device and the intermediate entity server. In other embodiments, any number of third- party servers may be provided between the remote device and the intermediate entity server. Every time a communication is forwarded from a third party server, the communication may be encrypted using SSL or TLS using ESMTP, or any other cryptographic protocol. In other alternate embodiments, third party servers may be used to forward communications and/or provide secure methodology at any stage during the runtime process and between

communications between the remote device, intermediate server, processor, and/or financial institution.

[00136] Upon receipt of e-mail from end user, the intermediate entity may decrypt the encrypted portion. Any descriptions provided elsewhere herein or variations thereto may be utilized to encrypt and/or decrypt the e-mail.

[00137] The intermediate entity may process the image delivered from the mobile device to conform to end-processor specifications. For example, such specifications may include 200 dpi for RDC, or any other Industry standard (e.g. Check-21) related qualifications. In some instances, the intermediate entity may provide some pre-processing steps which may or may not reach Industry standard (e.g. Check-21) standards. In other embodiments, the intermediate entity need not perform any image processing steps.

[00138] The intermediate entity may submit the first image to a FI or an RDC processor and receives success/error code. In some embodiments, the image may be submitted to the processor, which may process the image and/or validate the image. Alternatively, a financial institution may perform the image processing and/or validation step. During the validation, the processor and/or financial institution may let the intermediate entity know whether the image was a success or failure.

[00139] The intermediate entity may send the user a success/failure message(s). The success/failure message may be sent via the method selected during registration process. For example, the success/failure message may be sent via e-mail, SMS, or voice. In some embodiments, the success/failure message may be sent to the mobile device, while in other embodiments, the success/failure message may be sent to another device, whether the other device be another mobile device and/or a non-moving device. The success/failure message may show the result of scan(s): success with completion code, or failure with appropriate error description.

[00140] The end user may receive the success/failure message. If the end user receives an error, the end user may repeat the steps to send the first image(s). The end user may repeat such steps until there is success.

[00141] If the end user receives a message of success, the end user may repeat the process with subsequent pages of documents (or back of check in case of RDC). If an error occurs during the transmission of any of the subsequent pages, the user may repeat the steps to send that subsequent page until success is achieved.

[00142] When entire document has been successfully transmitted and processed, the end user may receive a confirmation message(s) via mobile channel such as e-mail, SMS, or voice. The end user may receive the confirmation via the method selected during the registration process. This may or may not be the same method that is used to transmit a success/failure message for a document page.

[00143] In accordance with alternate embodiments of the invention, the front and back may be validated at the same time, or the back may be validated before the front. In some embodiments, the front may be validated before the back in order to provide a clear series of steps for the user. For example, if the user sends both images at once, it may be confusing to explain which image to resend if an image is not validated, especially if both images need to be resent. However, in other embodiments, it may be desirable to send both images. These may refer to the front and back images of a check, for RDC. Alternatively, they may refer to the front and back images or pages of any other document.

[00144] Furthermore, different usage scenarios can apply to different ordering for different types of documents. For example, documents other than checks may be sent and/or validated. The documents may have any length (e.g., 1, 2, 3, 4, 5, 6, or more pages or images). The documents may have one page/image sent and/or validated at a time, or multiple or all of the pages may be sent and/or validated at once.

[00145] This methodology described may enable the S/MIME or ESMTP with SSL /TLS delivery path described to be functionally used for more than delivering physical check deposits via the mobile phone. Essentially, the application enables the mobile phone/thin client Internet interface to deliver secure documents. It may transform a mobile phone or device to function as a secured scanner connected to the Internet. Some additional applications may include but are not limited to:

• Account opening documents for banks (2 forms of ID, + a photo of the end user)

• Documents, which need to be executed and sent securely with a physical signature, (i.e., keep the original a scanned version is fine)

• Files which are transmitted or saved prior on the mobile device, but need to be

transmitted securely to another entity (Key PDF's, or even documents that can be edited at a later date, but need to be transmitted in a secure fashion)

• Financial Instruments or other documents which need to be presented and/or verified, and/or validated prior to acceptance or use by either the transmitter or by the recipient institution. [00146] This methodology can be applied to a variety of digital images corresponding to checks (personal or business check images) from financial institutions or any hardcopy document outside of banking transactions. Other preferable embodiments of the invention can be directed to documents or digital images thereof such as deposit slips, bank statements, brokerage statements, legal documents, credit card bills, as well as tax documents or returns, driver's licenses, medical records or any other document containing personalized or sensitive information that a user may wish to hide or conceal from view on a computer or online. It shall be understood that the personalized or sensitive information need not be in the form of text, but may be rather a graphical image such as an illustration of an individual, fingerprint or biometric information. The documents secured in accordance with this aspect of the invention can originally exist as a paper hardcopy that can be scanned to create digital images, or the documents may be stored as digital images and stored in computer readable memory such as a computer hard drives, flash memory drives or other memory media.

[00147] In any of the description and functions relating to a Check 21 processor, may also be applied to or performed by the intermediate entity. The intermediate entity may function as a backend processor. In some embodiments, the same intermediate entity may perform the steps described relating to the intermediate entity and the Check 21 processor. In other embodiments, different intermediate entities may perform the steps described relating to the intermediate entity and the Check 21 processor. Any number of intermediate entities may perform any of the steps described herein.

[00148] The secure transmission of documents may occur to other entities than a financial institution. Any discussion herein of a financial institution may also apply to any other receiving entity or party.

[00149] The systems and methods disclosed herein may incorporate or include any

characteristics, features, steps, or components as is known or later developed in the art. See, e.g., U.S. Patent Publication No. 2008/0173781; U.S. Patent No. 6,721,783; U.S. Patent Publication No. 2005/0144131; U.S. Patent No. 7,113,925; U.S. Patent Publication No. 2005/0097046; U.S. Patent Publication No. 2009/0094148; and U.S. Patent No. 7,555,462, which are hereby incorporated by reference in their entirety. See also, e.g., Remote Deposit Capture Web Site, http://RemoteDepositCapture.com; USAA article from E-Week,

http://www.eweek.com/c/a/Mobile-and-Wireless/USAA-Mobile-App-for-Android-Palm- BlackBerry-Windows-Coming-Soon-706579/; American City's Business Journal article on USAA solution,

http ://sanfrancisco .bizj ournals. com/sanfrancisco/stories/2009/08/ 17/daily75.html?surround=etf& ana=e_article, which are hereby incorporated by reference in their entirety. [00150] It should be understood from the foregoing that, while particular implementations have been illustrated and described, various modifications can be made thereto and are contemplated herein. It is also not intended that the invention be limited by the specific examples provided within the specification. While the invention has been described with reference to the aforementioned specification, the descriptions and illustrations of the preferable embodiments herein are not meant to be construed in a limiting sense. Furthermore, it shall be understood that all aspects of the invention are not limited to the specific depictions,

configurations or relative proportions set forth herein which depend upon a variety of conditions and variables. Various modifications in form and detail of the embodiments of the invention will be apparent to a person skilled in the art. It is therefore contemplated that the invention shall also cover any such modifications, variations and equivalents.

Claims

CLAIMS WHAT IS CLAIMED IS:

1. A method comprising:

(a) capturing an image of a financial document or a document requiring security in transmission and receipt with a remote device;

(b) transmitting the image to an intermediate entity via a secured e-mail using the intermediate entity's certificate to encrypt the e-mail;

(c) decrypting the e-mail and validating the image at the intermediate entity; and

(d) sending transaction data relating to the image of the financial document to a financial institution.

2. The method of claim 1 wherein the secured e-mail is secured using at least one of the following: S/MIME, TLS over ESMTP, or SSL over ESTMP.

3. The method of claim 1 wherein the secured e-mail is sent through a third party server which forwards the secured e-mail to the intermediate entity.

4. The method of claim 3 wherein the secured e-mail that is forwarded to the intermediate server is secured using S/MIME, TLS over ESMTP, or SSL over ESTMP.

5. The method of claim 1 further comprising pre-processing the image at the intermediate entity.

6. The method of claim 1 further comprising sending confirmation of validation to an end user of the remote device.

7. The method of claim 1 further comprising forwarding the image to a Check 21 processor.

8. The method of claim 7 further comprising receiving a validation of the image from the Check 21 processor.

9. The method of claim 1 further comprising enhancing the image at the

intermediate entity.

10. A system comprising :

(a) a remote device configured to capture an image of a document;

(b) an intermediate entity in communication with the remote device, wherein the intermediate entity provides a certificate to the remote device; and

(c) a financial institution in communication with the intermediate entity, wherein the intermediate entity confirms the identity of a user of the remote device with the financial institution.

11. The system of claim 10 wherein the certificate is an S/MIME certificate that is stored as a contact on the remote device.

12. The system of claim 10 wherein the remote device is selected from the group consisting of: a mobile phone, a personal device assistant, laptop computer, desktop computer, netbook or similar cloud computing device, camera, or scanner.

13. The system of claim 12 wherein the device captures the image of the document by use of a camera.

14. The system of claim 12 wherein the image of the document is the front of a check or the back of the check.

15. A method comprising :

(a) registering a device from a desktop/laptop environment for the purpose of remote capture and transmittal of documents;

(b) validating the user's credentials with one or more financial institutions and/or back-end processors; and

(c) sending an e-mail containing contact information which includes a secure certificate containing a public encryption key to the registered device for encryption of documents for transmission to the validated institutions.

16. A method comprising :

(a) registering a device from a mobile Internet environment for the purpose of remote capture and transmittal of documents over a secure and/or an encrypted network;

(c) sending an email containing contact information which includes a secure certificate containing a public encryption key to the registered device for encryption of documents for transmission to the validated institutions.

17. The method of claim 15 or claim 16 wherein said registration step includes providing identifying information.

18. The method of claim 17 wherein the identifying information includes at least one of: user e-mail address, financial institution information, user financial institution account number, or preference for mobile response channel for validation process.