METHODS AND SYSTEMS FOR FACILITATING DOCUMENT BANKING

Systems and related methods for facilitating document banking for one or more account holders are disclosed. The system includes 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 the one or more documents when requested by the document banking system.

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.

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. 1illustrates an overall exemplary system100in which various of the disclosed embodiments may be practiced. The system100includes a document banking system102, which facilitates document transactions among account holders and verification partners. The document banking system102may be hosted on a server. The architecture of the document banking system102is explained in further detail in conjunction withFIG. 2below. One or more individuals104and one or more business(es)/organization(s)106(hereinafter, collectively referred as at least one account holder104and106) may have document accounts with the document banking system102. The at least one account holder104and106of the document banking system102interact with the document banking system102to 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 withFIGS. 4-17below.

The document banking system102may communicate with or access at least one verification partner108to verify documents stored in the document banking system102. The at least one verification partner108includes public offices110, private offices112as well as other offices or officials114. The document banking system102establishes interactions with the at least one verification partner108, 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 withFIGS. 8 and 9below.

Document Banking System

FIG. 2illustrates the document banking system102, according to one embodiment of the disclosure. The document banking system102includes a storage repository202, a profile DataBase (DB)204, an Secure Data Technologies (SDT) module206, a document transaction engine208, a billing and payment module210, and a verification module/system212. These modules interact with each other to perform the desired task.

The storage repository202stores documents of the at least one account holder104and106in a reliable and secure manner using one or more technologies known in the art. For example, the storage repository202may allow access only through a firewall to ensure secure access. Further, the storage repository202may 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 DB204stores account information of the at least one account holder104and106; for example, login credentials, beneficiary list and other related information. The SDT module206helps in authenticating the documents and storing the documents in a pre-defined format in the storage repository202. The SDT module106may 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 engine208facilitates one or more document transactions among various parties including the at least one account holder104and106, the at least one verification partner108, third parties, etc. The various types of document transactions are explained in detail in conjunction withFIGS. 4-17below. The billing and payment module210handles billing related activities associated with the one or more document transactions. When or if requested, the verification module212performs verification of the documents, either manually or via a web-based API.

Further, the document banking system102includes a notification module to notify the at least one account holder104and106of account activity related to one or more document transactions. Moreover, the document banking system102includes a logging module to log information related to all activities performed on the document banking system102. 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 system102so that it may take corrective actions to maintain reasonable system performance. In some embodiments, the document banking system102may also include a scanner to scan documents and a printer to print documents.

The storage repository202, the profile DB204, the SDT module206, the document transaction engine208, the billing and payment module210, and the verification module212interact with each other to execute one or more document transactions. In an exemplary embodiment, the at least one account holder104and106logs into the document banking system102. The document banking system102uses the profile DB204to verify the login credentials of the at least one account holder104and106before the at least one account holder104and106is allowed access to the document account at the document banking system102. Thereafter, the at least one account holder104and106initiates a document transaction, such as a deposit document transaction and sends a document to the document transaction engine208. The document transaction engine208processes the deposit document transaction as per the predefined functionality. Thereafter, the SDT module206authenticates the document sent by the at least one account holder104and106and stores an encrypted copy of the document in the storage repository202. In some embodiments, the billing and payment module210updates billing information for the at least one account holder104and106based on the type of document transaction.

In cases where the at least one account holder104, and106initiates a request for verifying a document, the verification module212identifies a relevant verification partner, in the at least one verification partner108, to verify the document. On successful verification, the verification module212sets a “verified_tag” associated with the document to “TRUE”. Finally, the billing and payment module210updates billing information for the at least one account holder104and106based on the verified document transaction.

Exemplary Document Banking System

FIG. 3illustrates an exemplary document banking system102, according to one embodiment of the disclosure. The at least one account holder104and106may access the document banking system102using a computer302, a mobile device304, a document automated teller machine (DOC ATM)306or visit a branch308of the document banking system102. The computer302may 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 device304may 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 holder104and106may use an application installed on the mobile device304, 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 holder104and106may use the DOC ATM306installed at a remote location from the document banking system102. The DOC ATM306may be integrated with bank ATMs. Further, the DOC ATM306may have an in-built scanner to scan documents deposited by the at least one account holder104and106. The DOC ATM306may have a built-in printer to print secure documents. Moreover, the at least one account holder104and106may visit a branch office of the document banking system102to access the document account.

When the at least one account holder104and106accesses the document banking system102, an authentication system310may be used to authenticate the at least one account holder104and106before they can access the services provided by the document banking system102. The authentication system310may authenticate the at least one account holder104and106using the login credentials stored in the profile DB204. The authentication system310may send the requests received from the at least one account holder104and106to an input queue to organize the requests into a sequence. The input queue then sends the received requests the document transaction engine208for execution. The input queue may send requests to the document transaction engine208on 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 holder104and106.

Thereafter, the document transaction engine208receives the requests. In some embodiments, the document transaction engine208controls and coordinates execution of all transactions. For each transaction, the document banking system102predefines 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:

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 holder104and106by 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 system102. 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 withFIGS. 5-18below.

Open a Document Account

FIG. 4is a flowchart of a method400for 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 withFIG. 3above. At step402, the document transaction engine208receives 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 module206authenticates the one or more documents.

Next at step404, the verification module212verifies 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 system102. Typically, verification involves using third party services (the at least one verification partner108) 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 withFIGS. 8 and 9below.

Thereafter, at step406, the document transaction engine208determines whether any additional documents are required. If additional documents are required, then the document transaction engine208sends a request to the user to submit the remaining documents at step408. Then, at step410, the remaining supporting documents are received from the user. However, if it is determined at step406that the additional documents are not required, then at step412, the submitted documents are scanned. Thereafter, the document transaction engine208creates an account and an associated profile at step414. Next, the document transaction engine208stores the submitted documents in the storage repository202at step416. Finally, the document transaction engine208notifies the user about successful account creation at step418and adds a corresponding entry into a log at step420. Upon successful account creation, the document transaction engine208may allocate a certain fixed amount of disk space to the user/account holder in the storage repository202depending 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 DB204. Once a user creates a new account using the method400; 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 withFIG. 5below.

An Exemplary User Interface

FIG. 5is a snapshot500of the display screen of the computer302used by an account holder “S”, according to an exemplary embodiment of the disclosure. The snapshot500shows a user interface that includes multiple buttons502-518related to various transactions that may be performed using the document banking system102. The account holder “S” may activate:

1. “view documents” button502to view one or more documents stored in the document account
2. “view account summary” button504to view the account summary
3. “deposit” button506to deposit one or more documents into the document account. This is explained in further detail in conjunction withFIGS. 6 and 7below.
4. “verify” button508to verify one or more documents into the document account. This is explained in further detail in conjunction withFIGS. 8 and 9below.
5. “send” button510to send one or more documents to at least one account holder. This is explained in further detail in conjunction withFIGS. 10-15below.
6. “receive” button512to receive one or more documents available in a public space. This is explained in further detail in conjunction withFIGS. 16 and 17below.
7. “add account holder to beneficiary list” button514to add at least one account holder to a beneficiary list. This is explained in further detail in conjunction withFIGS. 13 and 14below.
8. “print/scan” button516to print or scan one or more documents
9. “print account summary” button518to 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. 6is a flowchart of a method600for depositing a document in the document account, according to an embodiment of the disclosure. At step602, an account holder “S” logs into her document account using at least one of the computer302, the mobile device304or the DOC ATM306. Alternatively, the account holder “S” may visit branch of the document banking system102to deposit a document. Then at step604, the account holder “S” sends a request to deposit a document and store the document in the storage repository202. Next, at step606, the document is scanned and uploaded. The account holder “S” may scan the document and upload the document using the computer302or a mobile device304. Alternatively, the account holder “S” may use a scanner available at the DOC ATM306to scan the document. The document banking system102may accept only a subset of available file extension types (including PDF, DOC, etc.) for the scanned documents. Next, at step608, the SDT module206secures and authenticates the uploaded document, which is then stored in the storage repository202at step610. Finally, the account holder “S” is notified about successful account creation at step612, and the corresponding entry is written into a log at step614.

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

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 method600may be executed using a user interface explained in conjunction withFIG. 7below.

FIG. 7is a snapshot700of display screen of the computer302used by the account holder “S” to deposit a document, according to an exemplary embodiment of the disclosure. The snapshot700includes 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” button506. The form includes a “Select document to deposit” field702. The account holder “S” may use a “Browse” button704to 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 menu706to 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” button708to deposit the selected document.

Verify a Document

FIG. 8is a flowchart of a method800for 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 step802, the account holder “S” logs into the document account. Then, at step804, the account holder “S” selects a document in the document account and requests the verification module212to verify the selected document. This is explained in further detail in conjunction withFIG. 9below. The verification module212identifies a verification partner from the at least one verification partner108at step806, and requests the identified verification partner to verify the selected document at step808. 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 module212waits for reply from the identified verification partner at step810.

Thereafter, at step812, the verification module212determines whether the document has been verified by the identified verification partner. If the document is not verified, then the verification module212aborts the transaction at step814and notifies the account holder “S” about the failure at step816. However, if it is determined at step812that the document has been verified, then the “verified_tag” is initialized to “TRUE” at step818. 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 repository202at step820, and the account holder “S” is notified at step822. In either case of success or failure of the transaction, the entry is written into a log at step824.

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

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 method800may be executed using a user interface explained in conjunction withFIG. 9below.

FIG. 9is a snapshot900of the display screen of the computer302used by the account holder “S” to verify a document, according to an exemplary embodiment of the disclosure. The snapshot900includes 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” button508. The account holder “S” may use a “Browse” button902to select the document to be verified. The selected document is displayed in the “Select document to be verified” text field904. Finally, the account holder “S” uses a “Submit” button906to submit request for verifying the selected document. Upon successful submission, a message908may be displayed, wherein the message908says, “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. 10is a flowchart of a method1000for 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 step1002, 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 step1004, 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 step1006, the user (hereinafter, a first account holder “S”) logs into the document account. Then, at step1008, the first account holder “S” selects a document and requests the document transaction engine208to 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 engine208matches the required document against the available documents in the document account. If the required document is available, then the transaction engine208is 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 system102. 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 step1010, 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 step1012, the billing and payment module210updates 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 step1014and the entry is written into a log at step1016.

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

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 method1000may be executed using user interfaces explained in conjunction withFIGS. 11 and 12below.

FIG. 11is a snapshot1100of the display screen of the computer302used by the first account holder “S” to send a document, according to an exemplary embodiment of the disclosure. The snapshot1100includes 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” button510. 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” field1102. Then the first account holder “S” may use a “Browse” button1104to select a document to send to the third party. The selected document is displayed in the text field1106. Finally, the first account holder “S” uses a “Send” button1108to send the document.

FIG. 12is a snapshot1200of display screen of the computer302used by the first account holder “S” to send multiple documents through the gateway, according to an exemplary embodiment of the disclosure. The snapshot1200includes 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” button510. The form includes a “To” text field1202. 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” buttons1204,1206and1208to select multiple documents to be transferred through the gateway. The selected documents are displayed in the text fields1210,1212and1214. Finally, the first account holder “S” uses a button “Send”1216to send the selected documents to the third party. Adding an account holder to a beneficiary list

FIG. 13is a flowchart of a method1300for adding an account holder to a beneficiary list and sending a document to the account holder, according to an embodiment of the disclosure. At step1302, a first account holder “S” logs into the document account. Then, at step1304, the first account holder “S” selects the document to be sent to a second account holder “R”. Further, at step1304, the first account holder “S” sends a request to the document transaction engine208to 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 DB204. This is explained in further detail in conjunction withFIGS. 14 and 15below. 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 step1306, then the document transaction engine208adds the second account holder “R” to the beneficiary list of the first account holder “S” at step1308. Further, at step1310, the document transaction engine208transfers the document to the second account holder “R”. However, if it is determined at step1306, that the second account holder “R” has not accepted the request sent by the first account holder “S”, then the transaction is aborted at step1308, and the first account holder is notified of the failure at step1310. Finally, the corresponding entry is written into a log at step1316.

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

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 system102asks “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 method1300may be executed using user interfaces explained in conjunction withFIGS. 14 and 15below.

FIG. 14is a snapshot1400of display screen of the computer302used 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 snapshot1400includes 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” button514. The form includes a “Select account holder to be added to your beneficiary list” field1402. The first account holder “S” inputs the account number (e.g., “267845034567”) of the second account holder “R” in the field1402. Thereafter, under “Select beneficiary type”, the first account holder “S” selects one of the radio buttons “One-time”1404, “Always”1406and “Periodically”1408as per the requirements. For example, the first account holder “S” selects the “One-time” radio button1404if 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 button1406if 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 button1408if 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 field1410(e.g., for receiving once every 3 months, “3” is the typed in the field1410). Finally, the first account holder “S” uses a “Submit” button1412to send the request. Upon successful submission, a message1414may be displayed, wherein the message1414says, “Account number 267845034567 has been successfully added to your beneficiary list.”

FIG. 15is a snapshot1500of display screen of the computer302used 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 snapshot1500includes 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” button510. The form includes a “To” field1502. The first account holder “S” inputs the account number (e.g., “267845034567”) of the second account holder “R” in the field1502. Then, the first account holder “S” may use “Browse” button1504to select a document to be transferred to the second account holder “R”. The selected document is displayed in the field1506. Finally, the first account holder “S” activates a “Send” button1508to send the selected document to the second account holder “R”.

Receive Document

FIG. 16is a flowchart of a method1600for receiving one or more documents, according to an embodiment of the disclosure. At step1602, a first account holder “S” logs into the document account. Then, at step1604, 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 engine208to send the located document at step1604. 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 step1606, the document banking system102checks 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 step1608and the first account holder “S” is notified at step1610. However, if it is determined that the selected document is available in public spaces or protected spaces at step1606, then the document is transferred at step1612. Finally, the corresponding entry is written into a log at step1614.

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

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 method1600may be executed using a user interface explained in conjunction withFIG. 17below.

FIG. 17is a snapshot1700of the display screen of the computer302used by the first account holder “S” to receive a document, according to an exemplary embodiment of the disclosure. The snapshot1700includes 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” button512. The form includes a “Search for document” field1702. The first account holder “S” inputs the document name (e.g., “2543478907”) in the field1702. Then, the first account holder “S” may use “Receive Document” button1704to receive the searched document.

Similarly, the document transaction engine208supports 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 engine208to delete the selected document. Upon receiving the request from the account holder “S”, the document transaction engine208sends a token “Tok” to the account holder “S” by web, phone or email. Thereafter, the document transaction engine208requests the account holder “S” to input the token “Tok”. Upon the account holder“S” successfully inputting “Tok”, the document transaction engine208deletes 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:

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 engine208to update the selected document. The document transaction engine208requests the account holder “S” to input a token “Tok”, which the document transaction engine208transmits to “S” by web, phone or email. Upon the account holder “S” successfully inputting “Tok”, the document transaction engine208allows 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 engine208confirms 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:

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.

What is claimed is: