METHODS AND SYSTEMS FOR FACILITATING DOCUMENT BANKING

TECHNICAL FIELD

The presently disclosed embodiments relate to document banking, and more particularly, to methods and systems for facilitating trusted document transactions.

BACKGROUND

Consumers are often required to submit a significant number of documents to organizations, such as public offices and private service providers, for purchasing services, submitting applications, etc. These documents are not available in a central repository; rather, they are typically in paper form or in stored electronic repositories, such as consumers' email account(s). Some of the required documents may be lost or unavailable. In one exemplary scenario, when a consumer wishes to apply for a United States (U.S.) visa, the consumer needs to submit a set of documents (e.g., passport, address proof, bank account statement, photo, etc.) to the U.S. Embassy. Typically, the consumer will first manually gather the original or certified copies of these documents by going to different sources (such as, a government office, real estate agency, bank, etc.), and then submit them to the U.S. Embassy in person or by mail. This process is cumbersome, time-consuming and/or error prone. Further, it causes human stress as well as productivity loss. Additionally, manual document submissions also stress organizational resources and hinder organizational productivity, in addition to prolonging business process completion times. For example, upon receiving the documents from the consumer, the U.S. Embassy's personnel would need to check the documents and determine their veracity. Again, this process is cumbersome and time-consuming process, and may require crosschecking with the organizations that issued these documents.

In some cases, the consumer may proactively maintain scanned copies of all required documents in a document repository service (e.g., Dropbox®, Gmail®) or on her own computer. However, in general, these scanned copies would still need to be authenticated/certified/duly notarized before they can be submitted to the requesting organization (e.g., U.S. Embassy). Therefore, this scenario still results in human stress and productivity loss for both the consumer and the requesting organization.

SUMMARY

In an embodiment, a system for facilitating document banking for one or more account holders is disclosed. The system further a document banking system and one or more verification partners. The document banking system includes a storage repository to store one or more documents for the one or more account holders. The document banking system further includes a transaction engine facilitating one or more document transactions. The one or more verification partners verify one or more documents when requested by the document banking system. Various examples of the one or more document transactions include, but are not limited to, opening a document account, depositing one or more documents in the document account, verifying one or more documents in the document account, sending one or more documents through a gateway, adding an account holder to a beneficiary list, receiving one or more documents, deleting one or more documents, and updating one or more documents.

In another embodiment, a method for facilitating one or more document transactions for at least one account holder through a document banking system is disclosed. The method includes receiving a request from the at least one account holder to perform the one or more document transactions. Then, the one or more document transactions are performed and finally the at least one account holder is notified about the result of the one or more document transactions.

In further embodiment, a method for facilitating document transactions through a document banking system is disclosed. The method includes receiving one or more documents from a first account holder at the document banking system. Next, the one or more documents are authenticated and deposited in the document account of the first account holder. Thereafter, the one or more documents may be verified.

Next, on receiving a request through a gateway at the document banking system to send the one or more documents to a third party, the method includes obtaining a token generated by a third party and sending the one or more documents to the third party through a gateway. Finally, the first account holder is billed when the one or more documents are successfully sent to the third party.

In further embodiment, a document banking system for facilitating document transactions is disclosed. The document banking system includes a storage repository to store one or more documents for at least one account holder in a predefined format. Further, the document banking system includes a document transaction engine executing one or more document transactions.

In an additional embodiment, a method for opening a document account with a document banking system is disclosed. The method includes receiving a request from a user to open a document account at the document banking system and then one or more documents received. Then, the one or more documents are verified. Next, the document account of the user is created at the document banking system based on the verification. Finally, the one or more documents are stored in the document account of the user.

A method for facilitating document transactions through a document banking system is disclosed. The method includes receiving a document from a first account holder at the document banking system. Then the document is authenticated and deposited in the document account of the first account holder. Next, the document is verified. Thereafter, on receiving a request to send the document to a second account holder at the document banking system, the method includes sending the document to the second account holder, if a beneficiary list of the first account holder includes the second account holder. Finally, the first account holder is billed, when the document is successfully sent to the second account holder.

A method for depositing one or more documents in a document account of at least one account holder at a document banking system is disclosed. The method includes allowing the at least one account holder to log into the document account. Next, the method includes receiving one or more documents from the at least one account holder and securing the one or more documents in a predefined format. Finally, the method includes storing the one or more documents in the document account of the at least one account holder.

A method for verifying one or more documents in a document account of at least one account holder at a document banking system is disclosed. The method includes receiving a request from the at least one account holder to verify the one or more documents. Then, a verification partner is identified to perform the verification. Thereafter, a request is sent to an identified verification partner to verify the one or more documents. Finally, a verified tag is associated with the one or more documents if the verification partner successfully verifies the one or more documents.

A method for enabling a first account holder at a document banking system to send one or more documents to a second account holder at the document banking system is disclosed. The method includes receiving a request from the first account holder to send the one or more documents to the second account holder. Next, the one or more documents are transferred to the second account holder, when a beneficiary list of the first account holder includes the second account holder. Finally, billing information of the first account holder is updated when the one or documents are successfully transferred to the second account holder.

A method for enabling a first account holder at a document banking system to send one or more documents to a third party at the document banking system is disclosed. The method includes receiving a request through a gateway from the first account holder to send the one or more documents to the third party. Then, a token is obtained from the third party. Next, the one or more document are transferred to the third party through the gateway and finally billing information of the first account holder us updated when the one or documents are successfully transferred to the third party.

A method for adding a first account holder at a document banking system to a beneficiary list of a second account holder at a document banking system is described. The method includes receiving a request from the second account holder to add the first account holder in the beneficiary list. Thereafter, the received request is sent to the first account holder and the first account holder is added to the beneficiary list, when the first account holder accepts the request.

A method for requesting one or more documents by at least one account holder at a document banking system is disclosed. The method includes receiving a request from the at least one account holder to receive the one or more documents. Then the one or more documents are transferred to a document account of the at least one account holder, if the document is available in a public space or an available protected space in the document banking system.

A method for deleting one or more documents in a document account of at least one account holder at a document banking system is disclosed. The method includes allowing the at least one account holder to log into the document account. Then, a request from the at least one account holder is received to delete the one or more documents. Next, a token is sent to the at least one account holder and the one or more documents are deleted from the document account, when the at least one account holder provides the correct token.

A method for updating one or more documents in a document account of at least one account holder at a document banking system is disclosed. The method includes allowing the at least one account holder to log into the document account. Then, a request is received from the at least one account holder to update the one or more documents, wherein the at least one account holder provides the one or more documents and changes made to the one or more documents. Next, a token is sent to the at least one account holder, and the one or more documents are updated when the at least one account holder provides the correct token.

A storage repository to store one or more documents for the at least one account holder in a document banking system is disclosed. The storage repository is configured to store the one or more documents and to facilitate retrieving of the one or more documents.

A transaction engine facilitating one or more document transactions in a document banking system, the one or more document transactions include at least one of opening a document account, depositing one or more documents in the document account, verifying one or more documents in the document account, sending one or more documents through a gateway, adding an account holder to a beneficiary list, receiving one or more documents, deleting one or more documents, and updating one or more documents.

A verification system to verify one or more documents in the document account in a document banking system is disclosed. The verification is performed through at least one verification partner when requested by the document banking system.

A method includes initiating a request by a user, to perform one or more document transactions and obtaining a token by the user to execute the one or more document transactions, based on the type of request.

A method for facilitating document transactions through a document banking system is disclosed. The method includes a user initiating one or more document transactions in the document banking system and the user receiving a notification from the document banking system when the one or more document transactions are processed.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an exemplary overall system in which various embodiments of the disclosure may be practiced.

FIG. 2 illustrates a document banking system, according to an embodiment of the disclosure.

FIG. 3 illustrates the document banking system, according to an embodiment of the disclosure.

FIG. 4 is a flowchart of a method for opening a document account, according to an embodiment of the disclosure.

FIG. 5 is a snapshot of a display screen of a computer when an account holder logs-in to the document banking system, according to an exemplary embodiment of the disclosure.

FIG. 6 is a flowchart of a method for depositing one or more documents in the document account, according to an embodiment of the disclosure.

FIG. 7 is a snapshot of a display screen of the computer used to deposit one or more documents, according to an exemplary embodiment of the disclosure.

FIG. 8 is a flowchart of a method for verifying one or more documents in the document account, according to an embodiment of the disclosure.

FIG. 9 is a snapshot of the display screen of the computer used to verify a document, according to an exemplary embodiment of the disclosure.

FIG. 10 is a flowchart of a method for sending one or more documents, according to an embodiment of the disclosure.

FIG. 11 shows a snapshot of the display screen of the computer used to send one or more documents, according to an exemplary embodiment of the disclosure.

FIG. 12 shows a snapshot of the display screen of the computer used to send one or more documents through a gateway, according to an exemplary embodiment of the disclosure.

FIG. 13 is a flowchart of a method for adding an account holder to a beneficiary list and sending a document to the account holder, according to an embodiment of the disclosure.

FIG. 14 is a snapshot of the display screen of the computer used to add an account holder to the beneficiary list, according to an exemplary embodiment of the disclosure.

FIG. 15 is a snapshot of the display screen of the computer used to send one or more documents, according to an exemplary embodiment of the disclosure.

FIG. 16 is a flowchart of a method for receiving one or more documents, according to an embodiment of the disclosure.

FIG. 17 is a snapshot of the display screen of the computer used to receive one or more documents, according to an exemplary embodiment of the disclosure.

DETAILED DESCRIPTION

The following detailed description is provided with reference to the figures. Exemplary, and in some case preferred, embodiments are described to illustrate the disclosure, not to limit its scope, which is defined by the claims. Those of ordinary skill in the art will recognize a number of equivalent variations in the description that follows.

Definitions

Definitions of one or more terms that will be used in this disclosure are described below. The term, “document banking” refers to document storage as well as trusted document transactions between one or more parties. The term “document” refers to any information such as a text, a video, an audio, a fingerprint that can be embedded inside a paper document or an electronic document. Some or all of the operations of document banking are analogous to traditional banking, which stores and transacts money. The term “document transaction” refers to any activity related to documents performed in a document banking system. Examples of document transactions include, but not limited to, opening a new document account, depositing a document in the document account, verifying a document, sending one or more documents through a gateway, sending a document periodically to a beneficiary, receiving a document from the document account, deleting a document, updating an existing document and adding an account holder to list of beneficiaries to send documents to the account holder.

The term “transaction engine” refers to a device or a software module within the document banking system that processes all document transactions. The transaction engine may execute predefined functions corresponding to the one or more document transactions to process the corresponding document transactions. The term “billing and payment module” refers to a device or a software module within the document banking system to handle billing and payment activities. Similarly, the term “logging module” refers to a device or a software module within the document banking system to log the result of each document transaction.

The term “account holder(s)” refers to any individual or entity that maintains a document account with a document banking system. The term “storage repository” refers to any storage space available at a document banking system to store documents. Each account holder is allocated a pre-defined space within the storage repository, wherein the pre-defined space is associated with the document account of the account holder. The storage repository also stores a “profile database (DB)” to store information related to the account holders. Further, the storage repository stores documents in a predefined format, such as PDF, DOC, JPEG, MPEG, etc. The term “secure data technologies (SDT) module” refers to a device or a software module within the document banking system that secures and authenticates the documents stored in the storage repository.

As used herein, the term “verification partners” refers to individuals or organizations who have the authority to certify the veracity of documents. The verification partners include public offices (e.g., Passport and Immigration Office, Income Tax Department, Motor Vehicles Department), private offices (e.g., banks, hospitals, schools) as well as other offices or officials (e.g., gazette officers and notarization services). As used herein, the term “verification module” is a device or a software module within the document banking system that manages verification related activities at the document banking system. Once a document is verified, a “verified tag” is associated with the document.

The term “gateway” refers to a communication channel used by third parties to connect account holders with their respective document accounts with a document banking system. The term “token” refers to a unique identifier generated by third parties. In some cases, the term “token” refers to a unique identifier generated by the document banking system and sent to an account holder to confirm an action (such as deleting or modifying of a document) initiated by the account holder.

Overview

Some disclosed embodiments generally relate to trusted document transactions between one or more parties via a document banking system. The one or more parties include account holders, verification partners, other third parties, etc. To this end, the disclosure provides a document banking system that includes a repository for storing the account holders' documents (e.g., passport, driver's license, photos and/or videos, or others) in a document account, and enables account holders to transact or transfer these documents to other accounts as and/or when requested. For example, an account holder can efficiently send her document(s) from her document account to an intended recipient's document account or to a third party, such as U.S. Embassy, a company, a college, etc.

Document transactions involve authenticating the identities of the sending and the receiving parties, and verifying the document(s) being transacted. This ensures integrity as well as non-repudiation in sending or receiving of document(s) across, between, or among the concerned parties. Thus, some of the disclosed embodiments relate to business processes, systems and methods that allow a given account holder to perform trusted document transactions.

Overall Exemplary System

FIG. 1 illustrates an overall exemplary system 100 in which various of the disclosed embodiments may be practiced. The system 100 includes a document banking system 102, which facilitates document transactions among account holders and verification partners. The document banking system 102 may be hosted on a server. The architecture of the document banking system 102 is explained in further detail in conjunction with FIG. 2 below. One or more individuals 104 and one or more business(es)/organization(s) 106 (hereinafter, collectively referred as at least one account holder 104 and 106) may have document accounts with the document banking system 102. The at least one account holder 104 and 106 of the document banking system 102 interact with the document banking system 102 to perform various types of document transactions. Various examples of document transactions include, but not limited to, opening a new document account, depositing a document in the document account, verifying a document, sending a document through a gateway, sending a document periodically to a beneficiary, receiving a document from the document account, deleting a document, updating an existing document and adding an account holder to list of beneficiaries to send documents to the account holder.

Further, a given document transaction may occur in any one of the following forms: Consumer-To-Business (C2B), Business-To-Consumer (B2C), Consumer-To-Consumer (C2C) and Business-To-Business (B2B). An example of a C2B document transaction is an individual sending her resume to a company for applying for a job. An example of a B2C document transaction is a company sending a job offer to a job applicant. An example of a C2C document transaction is a house owner sending a lease agreement to the tenant. An example of a B2B document transaction is a company sending financial documents to a bank for applying for a loan. The document transactions as described here are exemplary in nature and should not limit the scope of the disclosure. More examples of types of transactions are described in further detail in conjunction with FIGS. 4-17 below.

The document banking system 102 may communicate with or access at least one verification partner 108 to verify documents stored in the document banking system 102. The at least one verification partner 108 includes public offices 110, private offices 112 as well as other offices or officials 114. The document banking system 102 establishes interactions with the at least one verification partner 108, either via a web-based API or manually, thereby enabling verification of any given account holder's documents. This is explained in further detail in conjunction with FIGS. 8 and 9 below.

Document Banking System

FIG. 2 illustrates the document banking system 102, according to one embodiment of the disclosure. The document banking system 102 includes a storage repository 202, a profile DataBase (DB) 204, an Secure Data Technologies (SDT) module 206, a document transaction engine 208, a billing and payment module 210, and a verification module/system 212. These modules interact with each other to perform the desired task.

The storage repository 202 stores documents of the at least one account holder 104 and 106 in a reliable and secure manner using one or more technologies known in the art. For example, the storage repository 202 may allow access only through a firewall to ensure secure access. Further, the storage repository 202 may employ antispyware and anti-virus programs to ensure data integrity and security. Moreover, the documents may be stored in a pre-defined format.

The profile DB 204 stores account information of the at least one account holder 104 and 106; for example, login credentials, beneficiary list and other related information. The SDT module 206 helps in authenticating the documents and storing the documents in a pre-defined format in the storage repository 202. The SDT module 106 may use one or more known technologies in art, for example, encryption, to authenticate documents and store them in an encrypted form. The document authentication ensures that documents cannot be modified inadvertently. The document transaction engine 208 facilitates one or more document transactions among various parties including the at least one account holder 104 and 106, the at least one verification partner 108, third parties, etc. The various types of document transactions are explained in detail in conjunction with FIGS. 4-17 below. The billing and payment module 210 handles billing related activities associated with the one or more document transactions. When or if requested, the verification module 212 performs verification of the documents, either manually or via a web-based API.

Further, the document banking system 102 includes a notification module to notify the at least one account holder 104 and 106 of account activity related to one or more document transactions. Moreover, the document banking system 102 includes a logging module to log information related to all activities performed on the document banking system 102. The logged information may be used to perform system performance analytics to facilitate reasonable document transaction response times as well as system scalability with respect to a large and/or growing number of account holders and an increasingly large number of transactions. The statistics obtained by the performance analytics may include average time taken for different types of transactions, most frequently requested transactions, etc. The obtained statistics may be available to the document banking system 102 so that it may take corrective actions to maintain reasonable system performance. In some embodiments, the document banking system 102 may also include a scanner to scan documents and a printer to print documents.

The storage repository 202, the profile DB 204, the SDT module 206, the document transaction engine 208, the billing and payment module 210, and the verification module 212 interact with each other to execute one or more document transactions. In an exemplary embodiment, the at least one account holder 104 and 106 logs into the document banking system 102. The document banking system 102 uses the profile DB 204 to verify the login credentials of the at least one account holder 104 and 106 before the at least one account holder 104 and 106 is allowed access to the document account at the document banking system 102. Thereafter, the at least one account holder 104 and 106 initiates a document transaction, such as a deposit document transaction and sends a document to the document transaction engine 208. The document transaction engine 208 processes the deposit document transaction as per the predefined functionality. Thereafter, the SDT module 206 authenticates the document sent by the at least one account holder 104 and 106 and stores an encrypted copy of the document in the storage repository 202. In some embodiments, the billing and payment module 210 updates billing information for the at least one account holder 104 and 106 based on the type of document transaction.

In cases where the at least one account holder 104, and 106 initiates a request for verifying a document, the verification module 212 identifies a relevant verification partner, in the at least one verification partner 108, to verify the document. On successful verification, the verification module 212 sets a “verified_tag” associated with the document to “TRUE”. Finally, the billing and payment module 210 updates billing information for the at least one account holder 104 and 106 based on the verified document transaction.

Exemplary Document Banking System

FIG. 3 illustrates an exemplary document banking system 102, according to one embodiment of the disclosure. The at least one account holder 104 and 106 may access the document banking system 102 using a computer 302, a mobile device 304, a document automated teller machine (DOC ATM) 306 or visit a branch 308 of the document banking system 102. The computer 302 may be a computer using an operating system including but not limited to Android®, BSD®, iOS®, Linux®, OS X®, QNX®, Microsoft Windows®, and IBM z/OS®. The mobile device 304 may be based on a mobile operating system, including but not limited to iOS®, Android®, BlackBerry OS®, BlackBerry Tablet OS®, webOS®, Symbian OS®, bada®, Windows Mobile®, Windows Phone OS®, Maemo®, and MeeGo®. The at least one account holder 104 and 106 may use an application installed on the mobile device 304, wherein the application is one of an iPhone® application, iPad® application, Android® application, Blackberry® Application, Blackberry tablet® Application, webOS® application, Symbian® application, bada® application, Windows® application and Maemo® application. Alternatively, the at least one account holder 104 and 106 may use the DOC ATM 306 installed at a remote location from the document banking system 102. The DOC ATM 306 may be integrated with bank ATMs. Further, the DOC ATM 306 may have an in-built scanner to scan documents deposited by the at least one account holder 104 and 106. The DOC ATM 306 may have a built-in printer to print secure documents. Moreover, the at least one account holder 104 and 106 may visit a branch office of the document banking system 102 to access the document account.

When the at least one account holder 104 and 106 accesses the document banking system 102, an authentication system 310 may be used to authenticate the at least one account holder 104 and 106 before they can access the services provided by the document banking system 102. The authentication system 310 may authenticate the at least one account holder 104 and 106 using the login credentials stored in the profile DB 204. The authentication system 310 may send the requests received from the at least one account holder 104 and 106 to an input queue to organize the requests into a sequence. The input queue then sends the received requests the document transaction engine 208 for execution. The input queue may send requests to the document transaction engine 208 on a first-come-first served basis. Alternatively, the input queue may send requests based on a priority of the one or more transactions and/or the at least one account holder 104 and 106.

Thereafter, the document transaction engine 208 receives the requests. In some embodiments, the document transaction engine 208 controls and coordinates execution of all transactions. For each transaction, the document banking system 102 predefines the functionality using a structured format; for example, an Input-Output-Precondition-Effect (I-O-P-E) model. The I-O-P-E model for an exemplary transaction “Open_Account” is provided below:

Name: Open_Account
Participants: S

Input: supporting docs

Output: Acknowledgement receipt

Precondition: S has the necessary supporting documents to create an account

Effect: Link/copy of supporting docs is added to S's document banking account repository.

According to the I-O-P-E model described above, the name of the transaction is “Open_Account”. A user “S” is a participant of this transaction. The required input for this transaction is “supporting docs”. The precondition is that “S has the necessary supporting documents to create an account”. The transaction if successful, will have an effect such that “Link/copy of supporting docs gets added to S's document banking account repository”. Finally, the output of the transaction is that an “Acknowledgement receipt” is provided to “S”. The acknowledgement receipt may be sent to the at least one account holder 104 and 106 by electronic communication such as an email or an SMS, or a printed copy may be sent to “S”.

The I-O-P-E model is easy to implement and provides scalability, extensibility, semantic technologies and completeness to the transaction model used by the document banking system 102. Further, according to the I-O-P-E model, depending upon the preconditions, the same functionality may have different outputs and effects. The definitions of various transactions based on the I-O-P-E model are explained in detail in conjunction with FIGS. 5-18 below.

Open a Document Account

FIG. 4 is a flowchart of a method 400 for opening a document account, according to an embodiment of the disclosure. The I-O-P-E model for the transaction “Open_Account” is described in detail in conjunction with FIG. 3 above. At step 402, the document transaction engine 208 receives a request from a user to open a new document account. The user submits one or more documents along with the request. Upon receipt, the SDT module 206 authenticates the one or more documents.

Next at step 404, the verification module 212 verifies the one or more documents against predefined requirements. Furthermore, the user may have to agree to a set of terms and conditions; for example, terms and conditions related to the usage of the document banking system 102. Typically, verification involves using third party services (the at least one verification partner 108) to verify the authenticity of the submitted documents. For example, for a passport document, the passport office may be contacted to verify the authenticity of the passport. Typically, the verification is performed manually. However, verification may be performed automatically using online information sources. For example, for Permanent Account Number (PAN) (issued by the Government of India) may be verified using online resources. The document verification is explained in further detail in conjunction with FIGS. 8 and 9 below.

Thereafter, at step 406, the document transaction engine 208 determines whether any additional documents are required. If additional documents are required, then the document transaction engine 208 sends a request to the user to submit the remaining documents at step 408. Then, at step 410, the remaining supporting documents are received from the user. However, if it is determined at step 406 that the additional documents are not required, then at step 412, the submitted documents are scanned. Thereafter, the document transaction engine 208 creates an account and an associated profile at step 414. Next, the document transaction engine 208 stores the submitted documents in the storage repository 202 at step 416. Finally, the document transaction engine 208 notifies the user about successful account creation at step 418 and adds a corresponding entry into a log at step 420. Upon successful account creation, the document transaction engine 208 may allocate a certain fixed amount of disk space to the user/account holder in the storage repository 202 depending upon the document banking plan chosen by the user/account holder. In case the allocated disc space is full, the user/account holder may have to either delete some of the documents from the document account, or sign-up for a plan that allows for more disk space. All of the account-related information of the account holder is stored in the profile DB 204. Once a user creates a new account using the method 400; thereafter, the user may log into the account to perform one or more transactions. When the user logs into the account, a user interface may be presented to the user to facilitate one or more transactions. Such an exemplary user interface is explained in conjunction with FIG. 5 below.

An Exemplary User Interface

FIG. 5 is a snapshot 500 of the display screen of the computer 302 used by an account holder “S”, according to an exemplary embodiment of the disclosure. The snapshot 500 shows a user interface that includes multiple buttons 502-518 related to various transactions that may be performed using the document banking system 102. The account holder “S” may activate:

1. “view documents” button 502 to view one or more documents stored in the document account

2. “view account summary” button 504 to view the account summary

3. “deposit” button 506 to deposit one or more documents into the document account. This is explained in further detail in conjunction with FIGS. 6 and 7 below.

4. “verify” button 508 to verify one or more documents into the document account. This is explained in further detail in conjunction with FIGS. 8 and 9 below.

5. “send” button 510 to send one or more documents to at least one account holder. This is explained in further detail in conjunction with FIGS. 10-15 below.

6. “receive” button 512 to receive one or more documents available in a public space. This is explained in further detail in conjunction with FIGS. 16 and 17 below.

7. “add account holder to beneficiary list” button 514 to add at least one account holder to a beneficiary list. This is explained in further detail in conjunction with FIGS. 13 and 14 below.

8. “print/scan” button 516 to print or scan one or more documents

9. “print account summary” button 518 to print account summary

For a person skilled in the art, it is understood that the user interface as shown is exemplary in nature and should not limit the scope of the disclosure.

Deposit a Document

FIG. 6 is a flowchart of a method 600 for depositing a document in the document account, according to an embodiment of the disclosure. At step 602, an account holder “S” logs into her document account using at least one of the computer 302, the mobile device 304 or the DOC ATM 306. Alternatively, the account holder “S” may visit branch of the document banking system 102 to deposit a document. Then at step 604, the account holder “S” sends a request to deposit a document and store the document in the storage repository 202. Next, at step 606, the document is scanned and uploaded. The account holder “S” may scan the document and upload the document using the computer 302 or a mobile device 304. Alternatively, the account holder “S” may use a scanner available at the DOC ATM 306 to scan the document. The document banking system 102 may accept only a subset of available file extension types (including PDF, DOC, etc.) for the scanned documents. Next, at step 608, the SDT module 206 secures and authenticates the uploaded document, which is then stored in the storage repository 202 at step 610. Finally, the account holder “S” is notified about successful account creation at step 612, and the corresponding entry is written into a log at step 614.

The I-O-P-E model for depositing a document is provided below:

Name: Deposit_Doc_TX
Participants: S

Input: document

Output: Acknowledgement receipt

Precondition: S has an account (i.e., S′s identity has been authenticated) AND S is currently logged into her account

Effect: Link/copy of document is added to S's document banking account repository

According to the I-O-P-E model described above, the name of the transaction is “Deposit_Doc_TX”. The account holder “S” is a participant of this transaction. The required input for this transaction is a “document”. The precondition is that “S has an account (i.e., S's identity has been authenticated) AND S is currently logged into her account”. The transaction, if successful, will have an effect such that “Link/copy of document gets added to S's document banking storage repository”. Finally, the output of the transaction is that an “Acknowledgement receipt” is provided to “S”. The method 600 may be executed using a user interface explained in conjunction with FIG. 7 below.

FIG. 7 is a snapshot 700 of display screen of the computer 302 used by the account holder “S” to deposit a document, according to an exemplary embodiment of the disclosure. The snapshot 700 includes a user interface configured to display a form for depositing the document. The user interface is displayed if the account holder “S” activates the “Deposit” button 506. The form includes a “Select document to deposit” field 702. The account holder “S” may use a “Browse” button 704 to select a scanned document to upload and deposit in the document account. Further, the account holder “S” may use a “Select document type” drop down menu 706 to select the type of document, wherein the type of document includes a passport, an academic degree, a PAN card, a driving license, etc. Finally, the account holder “S” uses a “Submit” button 708 to deposit the selected document.

Verify a Document

FIG. 8 is a flowchart of a method 800 for verifying one or more documents in a document account of an account holder “S”, according to an embodiment of the disclosure. If one or more documents are uploaded to the document account, then they are stored as non-verified documents by default, accordingly a “verified_tag” associated with the one or more documents is initialized to “FALSE” by default. However, the account holder “S” may request a document to be verified. At step 802, the account holder “S” logs into the document account. Then, at step 804, the account holder “S” selects a document in the document account and requests the verification module 212 to verify the selected document. This is explained in further detail in conjunction with FIG. 9 below. The verification module 212 identifies a verification partner from the at least one verification partner 108 at step 806, and requests the identified verification partner to verify the selected document at step 808. The identified verification partner may be the original issuer of document, or a relevant certifying/attesting organization such as a notary. In some cases, self-attestation on the part of the account holder may be used to verify the document. The mode of verification depends on the type of the document as well as the circumstances under consideration, such as government laws, best practices, etc. Next, the verification module 212 waits for reply from the identified verification partner at step 810.

Thereafter, at step 812, the verification module 212 determines whether the document has been verified by the identified verification partner. If the document is not verified, then the verification module 212 aborts the transaction at step 814 and notifies the account holder “S” about the failure at step 816. However, if it is determined at step 812 that the document has been verified, then the “verified_tag” is initialized to “TRUE” at step 818. Alternatively, a verified watermark may be embedded in the given document to reflect that it has been verified. Other suitable techniques, such as digital certificate or digital signature, may be used to mark that the document as verified. The verification process is performed only once for a given document, and subsequently, the verified document is considered to be as good or valid as the original document. The updated document may be stored back in the storage repository 202 at step 820, and the account holder “S” is notified at step 822. In either case of success or failure of the transaction, the entry is written into a log at step 824.

The I-O-P-E model for the transaction “Verify_Doc” is provided below:

Name: Verify_Doc
Participants: S

Input: document to be verified

Output: Acknowledgement receipt

Precondition: S has an account (i.e., S's identity has been authenticated) AND verification partner has been identified

Effect: Verified version of documents stored in S's document banking account repository

According to the I-O-P-E model, the name of the transaction is “Verify_Doc”. The account holder “S” is a participant of this transaction. The required input for this transaction is the “document to be verified”. The precondition is that “S has an account (i.e., S's identity has been authenticated) AND verification partner has been identified”. The transaction if successful, will have an effect such that “Verified version of document is stored in S's document banking storage repository”. Finally, the output of the transaction is that an “Acknowledgement receipt” is provided to the account holder “S”. The method 800 may be executed using a user interface explained in conjunction with FIG. 9 below.

FIG. 9 is a snapshot 900 of the display screen of the computer 302 used by the account holder “S” to verify a document, according to an exemplary embodiment of the disclosure. The snapshot 900 includes a user interface configured to display a form for verifying a document. The user interface is displayed if the account holder “S” activates the “Verify” button 508. The account holder “S” may use a “Browse” button 902 to select the document to be verified. The selected document is displayed in the “Select document to be verified” text field 904. Finally, the account holder “S” uses a “Submit” button 906 to submit request for verifying the selected document. Upon successful submission, a message 908 may be displayed, wherein the message 908 says, “Your document has been successfully submitted for verification. You will receive an alert on your registered phone number or email address after the verification procedure has been completed.”

Send Document

FIG. 10 is a flowchart of a method 1000 for sending one or more documents through a gateway, according to an embodiment of the disclosure. The flowchart has been explained taking an example of a single document, but for a person it is understood that multiple documents can be sent through the gateway. At step 1002, a user visits a third party portal, for example, U.S. embassy website, a college website, a job portal, etc. The user is required to submit a document(s) to the third party portal. Therefore, at step 1004, the third party portal redirects the user to the document account of the user. For example, the third party portal may include a web form that requires the user to submit documents through a document account. When the user selects this option, the third party portal may redirect the user to the document account. Next, at step 1006, the user (hereinafter, a first account holder “S”) logs into the document account. Then, at step 1008, the first account holder “S” selects a document and requests the document transaction engine 208 to send the document to the third party. In another embodiment, the third party sends information about the required document to the document banking system through the gateway, wherein the transaction engine 208 matches the required document against the available documents in the document account. If the required document is available, then the transaction engine 208 is requested to send the document to the third party.

Before the document is transferred, the first account holder “S” may be required to provide a token. The first account holder “S” obtains a token from the third party outside the document banking system 102. For example, the first account holder “S” may physically visit the U.S. Embassy to obtain a token after paying the visa processing fees or by other techniques. The token confirms to the third party, that the first account holder “S” is not a spammer. Thereafter, at step 1010, the gateway connects the first account holder “S” to her document account to transfer the document to the third party using the token. Here, for preserving the first account holders' privacy, the gateway or the third party do not have access to the document account of the first account holder “S,” i.e., the gateway is merely used as a conduit to connect the first account holder “S” to her document account. Then, at step 1012, the billing and payment module 210 updates billing information of the first account holder “S” related to the document transfer to the third party. Finally, the first account holder “S” is notified about success or failure of the document transfer at step 1014 and the entry is written into a log at step 1016.

The I-O-P-E model for the transaction “Send_Doc_gateway” is provided below:

Name: Send_Doc_gateway

Participants: S and Third party

Input: identification token and document

Output: Acknowledgement receipt

Precondition: S has an account (i.e., S′s identity has been authenticated) AND S is currently logged into her account AND S has a valid identification token from the gateway

Effect: Link/copy of document is sent to third party.

According to the I-O-P-E model, the name of the transaction is “Send_Doc_gateway”. The first account holder “S” and the third party are participants of this transaction. The required input for this transaction is “identification token” and “document”. The precondition is that “S has an account (i.e., S's identity has been authenticated) AND S is currently logged into her account AND S has a valid identification token from the gateway.” The transaction if successful, will have an effect such that “Link/copy of document is sent to third party”. Finally, the output of the transaction is that an “Acknowledgement receipt” is provided to the first account holder “S”. The method 1000 may be executed using user interfaces explained in conjunction with FIGS. 11 and 12 below.

FIG. 11 is a snapshot 1100 of the display screen of the computer 302 used by the first account holder “S” to send a document, according to an exemplary embodiment of the disclosure. The snapshot 1100 includes a user interface configured to display a form for sending a document. The user interface may be displayed when the first account holder “S” activates the “Send” button 510. The form includes a text field “To” 1102. The first account holder “S” inputs the token number (e.g., “2543478907”) received from the third party in the “To” field 1102. Then the first account holder “S” may use a “Browse” button 1104 to select a document to send to the third party. The selected document is displayed in the text field 1106. Finally, the first account holder “S” uses a “Send” button 1108 to send the document.

FIG. 12 is a snapshot 1200 of display screen of the computer 302 used by the first account holder “S” to send multiple documents through the gateway, according to an exemplary embodiment of the disclosure. The snapshot 1200 includes a user interface configured to display a form for sending multiple documents. The user interface may be displayed if the first account holder “S” activates the “Send” button 510. The form includes a “To” text field 1202. The first account holder “S” inputs the token number (e.g., “2543478907”) received from the third party in the “To” field. Then, the first account holder “S” may use “Browse” buttons 1204, 1206 and 1208 to select multiple documents to be transferred through the gateway. The selected documents are displayed in the text fields 1210, 1212 and 1214. Finally, the first account holder “S” uses a button “Send” 1216 to send the selected documents to the third party. Adding an account holder to a beneficiary list

FIG. 13 is a flowchart of a method 1300 for adding an account holder to a beneficiary list and sending a document to the account holder, according to an embodiment of the disclosure. At step 1302, a first account holder “S” logs into the document account. Then, at step 1304, the first account holder “S” selects the document to be sent to a second account holder “R”. Further, at step 1304, the first account holder “S” sends a request to the document transaction engine 208 to add the second account holder “R” into the beneficiary list of the first account holder “S”. The beneficiary list of each account holder is maintained in the profile DB 204. This is explained in further detail in conjunction with FIGS. 14 and 15 below. If the second account holder “R” accepts the request from the first account holder “S” to add the second account holder “R” to the beneficiary list of the first account holder “S” at step 1306, then the document transaction engine 208 adds the second account holder “R” to the beneficiary list of the first account holder “S” at step 1308. Further, at step 1310, the document transaction engine 208 transfers the document to the second account holder “R”. However, if it is determined at step 1306, that the second account holder “R” has not accepted the request sent by the first account holder “S”, then the transaction is aborted at step 1308, and the first account holder is notified of the failure at step 1310. Finally, the corresponding entry is written into a log at step 1316.

The I-O-P-E model for the transaction “Send_doc_beneficiary” is provided below:

Name: Send_doc_beneficiary
Participants: S ad R

Input: document

Output: Acknowledgement receipt

Precondition: S and R have accounts (i.e., S's and R's identities have been authenticated) AND S is currently logged into her account AND R has been added to S's beneficiary list

Effect: S has permission to send document multiple times to R

According to the I-O-P-E model, the name of the transaction is “Send_doc_beneficiary”. The first account holder “S” and the second account holder “R” are participants of this transaction. The required input for this transaction is the “document”. The precondition is that “S” and R have accounts (i.e., S's and R's identities have been authenticated) AND S is currently logged into her account AND R has been added to S's beneficiary list.” The transaction if successful will have an effect such that “S has permission to send document multiple times to R.” Finally, the output of the transaction is that an “Acknowledgement receipt” is provided to “S”.

In an exemplary embodiment, monthly mobile phone bills are sent from a given service provider's document account (“S”) to the customer's document account (“R”). The document banking system 102 asks “R” if it would like to be added as a beneficiary of “S”, and once “R” agrees, it becomes a beneficiary of “S”. That is, “R” has now agreed to receive documents from “S” on a periodic basis (weekly, monthly, quarterly, annually, etc.). A periodicity of one is a special case of this, and it is equivalent to a one-time document transaction from “S” to “R”. The method 1300 may be executed using user interfaces explained in conjunction with FIGS. 14 and 15 below.

FIG. 14 is a snapshot 1400 of display screen of the computer 302 used by the first account holder “S” to add the second account holder “R” to a beneficiary list of the first account holder “S”, according to an exemplary embodiment of the disclosure. The snapshot 1400 includes a user interface configured to display a form for adding an account holder to a beneficiary list. The user interface may be displayed if the first account holder “S” activates the “Add account holder to beneficiary list” button 514. The form includes a “Select account holder to be added to your beneficiary list” field 1402. The first account holder “S” inputs the account number (e.g., “267845034567”) of the second account holder “R” in the field 1402. Thereafter, under “Select beneficiary type”, the first account holder “S” selects one of the radio buttons “One-time” 1404, “Always” 1406 and “Periodically” 1408 as per the requirements. For example, the first account holder “S” selects the “One-time” radio button 1404 if the first account holder “S” needs to send one or more documents to the second account holder “R” just once. However, the first account holder “S” may select the “Always” radio button 1406 if the first account holder “S” needs to send one or more documents to the second account holder “R” over a long period. Further, the first account holder “S” may selects the “Periodically” radio button 1408 if the first account holder “S” needs to send one or more documents to the receiver “R” periodically. The first account holder “S” may specify the periodicity in a field 1410 (e.g., for receiving once every 3 months, “3” is the typed in the field 1410). Finally, the first account holder “S” uses a “Submit” button 1412 to send the request. Upon successful submission, a message 1414 may be displayed, wherein the message 1414 says, “Account number 267845034567 has been successfully added to your beneficiary list.”

FIG. 15 is a snapshot 1500 of display screen of the computer 302 used by the first account holder “S” to send a document to the second account holder “R”, according to an exemplary embodiment of the disclosure. The snapshot 1500 includes a user interface configured to display a form for sending a document. The user interface may be displayed if the first account holder “S” activates the “Send” button 510. The form includes a “To” field 1502. The first account holder “S” inputs the account number (e.g., “267845034567”) of the second account holder “R” in the field 1502. Then, the first account holder “S” may use “Browse” button 1504 to select a document to be transferred to the second account holder “R”. The selected document is displayed in the field 1506. Finally, the first account holder “S” activates a “Send” button 1508 to send the selected document to the second account holder “R”.

Receive Document

FIG. 16 is a flowchart of a method 1600 for receiving one or more documents, according to an embodiment of the disclosure. At step 1602, a first account holder “S” logs into the document account. Then, at step 1604, the first account holder “S” searches for a document. Once the document is located, the first account holder “S” sends a request to the document transaction engine 208 to send the located document at step 1604. Every document account has its own private, public and protected spaces to respectively store private documents, public documents that can be subscribed to (‘pulled’) by other account holders, and protected documents that can be ‘pulled’ only by a selected set of account holders chosen by the owner of the documents. Therefore, account holders may “pull” certain documents that are disposed in the public space or an available protected of a document bank account. For instance, certain documents, such as application forms, may be disposed in the public account space of a University or a bank. Accordingly, at step 1606, the document banking system 102 checks whether the selected document is available in a public space or an available protected space. If it is determined that the selected document is not available in public spaces or available protected spaces, then the transaction is aborted at step 1608 and the first account holder “S” is notified at step 1610. However, if it is determined that the selected document is available in public spaces or protected spaces at step 1606, then the document is transferred at step 1612. Finally, the corresponding entry is written into a log at step 1614.

The I-O-P-E model for the transaction “Receive_Doc” is provided below:

Name: Receive_Doc
Participants: S and R

Input: public document in S's account

Output: Acknowledgement receipt

Precondition: S has an account AND document lies in the public account space of S

Effect: Link/copy of document is sent to document account of R

According to the I-O-P-E model, the name of the transaction is “Receive_Doc”. Account holders “S” and “R” are participants of this transaction. The required input for this transaction is the “public document in S′s account”. The precondition is that “S has an account AND document lies in the public account space of S”. The transaction if successful will have an effect such that “Link/copy of document is sent to document account of R”. Finally, the output of the transaction is that an “Acknowledgement receipt” is provided to “S”. The method 1600 may be executed using a user interface explained in conjunction with FIG. 17 below.

FIG. 17 is a snapshot 1700 of the display screen of the computer 302 used by the first account holder “S” to receive a document, according to an exemplary embodiment of the disclosure. The snapshot 1700 includes a user interface configured to display a form for receiving a document. The user interface may be displayed if the first account holder “S” activates the “Receive” button 512. The form includes a “Search for document” field 1702. The first account holder “S” inputs the document name (e.g., “2543478907”) in the field 1702. Then, the first account holder “S” may use “Receive Document” button 1704 to receive the searched document.

Similarly, the document transaction engine 208 supports other transactions including deleting a document, updating a document, viewing documents, viewing account summary, printing documents, scanning documents, and printing account summary.

In an exemplary embodiment, an account holder “S” decides to delete an existing document from the document account. The account holder “S” logs into the document account, selects the document, and requests the document transaction engine 208 to delete the selected document. Upon receiving the request from the account holder “S”, the document transaction engine 208 sends a token “Tok” to the account holder “S” by web, phone or email. Thereafter, the document transaction engine 208 requests the account holder “S” to input the token “Tok”. Upon the account holder“S” successfully inputting “Tok”, the document transaction engine 208 deletes the document from the document account. The token-based authentication ensures that the document deletions are handled with due care so that any given account holder does not accidentally delete documents from the document account.

The I-O-P-E model for the transaction “Delete_Doc_TX” is provided below:

Name: Delete_Doc_TX
Participants: S

Input: document

Output: Acknowledgement receipt

Precondition: S has an account (i.e., S's identity has been authenticated) AND S is currently logged into her account AND S has provided a valid token “Tok” associated with document deletion

Effect: Link/copy of document is removed from S's document banking account According to the I-O-P-E model, the name of the transaction is “Delete_Doc_TX”. Account holder “S” is a participant of this transaction. The required input for this transaction is the “document”. The precondition is that “S has an account (i.e., S's identity has been authenticated) AND S is currently logged into her account AND S has provided a valid token “Tok” associated with document deletion.” The transaction if successful will have an effect such that “Link/copy of document is removed from S's document banking account.” Finally, the output of the transaction is that an “Acknowledgement receipt” is provided to “S”.

In another exemplary embodiment, the account holder “S” decides to update a document in the document account. The account holder “S” logs into the document account, selects the document, and requests the document transaction engine 208 to update the selected document. The document transaction engine 208 requests the account holder “S” to input a token “Tok”, which the document transaction engine 208 transmits to “S” by web, phone or email. Upon the account holder “S” successfully inputting “Tok”, the document transaction engine 208 allows the account holder “S” to update the document. If the account holder “S” completes updating the document and saves the changes, then the document transaction engine 208 confirms with the account holder “S” to create a new version of document (i.e., both the newly saved version and the old version will be stored in the document account) or replace the existing version of document. Once the account holder “S” confirms, the document update transaction gets completed. Thus, there may be multiple versions of the same document in an account holder's document account.

The I-O-P-E model for the transaction “Update_Doc_TX” is provided below:

Name: Update_Doc_TX
Participants: S

Input: document AND changes made to document

Output: Acknowledgement receipt

Precondition: S has an account (i.e., S's identity has been authenticated) AND S is currently logged into her account AND S has provided a valid token “Tok” associated with document update AND S has answered the system's question regarding the multiple-versions vs. replace options

Effect: Link/copy of either the updated version of document or multiple versions of document are stored in S′s document banking account repository

According to the I-O-P-E model, the name of the transaction is “Update_Doc_TX”. Account holder “S” is a participant of this transaction. The required input for this transaction is the “document AND changes made to document.” The precondition is that “S has an account (i.e., S's identity has been authenticated) AND S is currently logged into her account AND S has provided a valid token “Tok: associated with document update AND S has answered the system's question regarding the multiple-versions vs. replace options.” The transaction if successful will have an effect such that “Link/copy of either the updated version of document or multiple versions of document are stored in S's document banking storage repository.” Finally, the output of the transaction is that an “Acknowledgement receipt” is provided to “S”.

The functionalities and the transaction model described above can be leveraged towards the realization of typical use-cases of document banking. In particular, these use-cases are realized by a combination of two types of operations, namely transactions and service requests. Each of these types of operations may occur multiple times within the same use-case. A transaction is any operation that relates to documents, e.g., initiating a document transfer, receiving a document, document creation, updates, deletions, etc. Any operation, which is not directly associated with a document, may be defined as a service request, e.g., login request to an account holder's document banking account. An example of a use-case is an account holder depositing a document into her account and requesting for that document to be verified before sending it to the U.S. Embassy through a gateway. In essence, by combining the set of functionalities and service requests in a specific configuration to satisfy some objective (e.g., submitting documents required for a visa), different use-cases for document banking can be provided.

The present disclosure facilitates method and systems for document banking in a more secure, trusted, and reliable environment. Particularly, the methods and systems enable account holders to perform transactions related to documents, thereby increasing productivity, and reducing hassles. For example, the account holder can access his document account anytime and use the documents in any desired manner. Further, the disclosed methods and systems enable account holders to perform transactions in a trusted environment by reducing spam transactions. Yet further, the existing infrastructure of banks may be used to implement the disclosed document banking system, wherein the existing banks provide additional services related to document transactions as disclosed above. The existing bank customers may purchase these additional services as per monthly or annual plans offered by the bank.

It will be appreciated that variants of the above-disclosed and other features and functions, or alternatives thereof, may be combined into many other different systems or applications. Various presently unforeseen or unanticipated alternatives, modifications, variations, or improvements therein may be subsequently made by those skilled in the art which are also intended to be encompassed by the following claims.

What is claimed is:

METHODS AND SYSTEMS FOR FACILITATING DOCUMENT BANKING

Information

Publication Number

Date Filed

Date Published

Inventors

Original Assignees

CPC

US Classifications

International Classifications

Abstract

Description

Claims