US20150052047A1 - Methods and systems for facilitating document banking - Google Patents
Methods and systems for facilitating document banking Download PDFInfo
- Publication number
- US20150052047A1 US20150052047A1 US13/969,635 US201313969635A US2015052047A1 US 20150052047 A1 US20150052047 A1 US 20150052047A1 US 201313969635 A US201313969635 A US 201313969635A US 2015052047 A1 US2015052047 A1 US 2015052047A1
- Authority
- US
- United States
- Prior art keywords
- document
- documents
- account
- account holder
- banking system
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
-
- G06F17/30011—
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/28—Databases characterised by their database models, e.g. relational or object models
- G06F16/284—Relational databases
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/93—Document management systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/95—Retrieval from the web
- G06F16/951—Indexing; Web crawling techniques
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
- G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F40/00—Handling natural language data
- G06F40/10—Text processing
- G06F40/166—Editing, e.g. inserting or deleting
- G06F40/186—Templates
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
- G06Q20/027—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP] involving a payment switch or gateway
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/14—Payment architectures specially adapted for billing systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/22—Payment schemes or models
- G06Q20/227—Payment schemes or models characterised in that multiple accounts are available, e.g. to the payer
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/322—Aspects of commerce using mobile devices [M-devices]
- G06Q20/3221—Access to banking information through M-devices
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/02—Banking, e.g. interest calculation or account maintenance
Definitions
- the presently disclosed embodiments relate to document banking, and more particularly, to methods and systems for facilitating trusted document transactions.
- 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.
- sources such as, a government office, real estate agency, bank, etc.
- 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.
- 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.
- a document repository service e.g., Dropbox®, Gmail®
- 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.
- 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.
- a method for facilitating one or more document transactions for at least one account holder through a document banking system 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.
- a method for facilitating document transactions through a document banking system 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.
- 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.
- a document banking system for facilitating document transactions.
- 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.
- a method for opening a document account with a document banking system 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 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 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 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 includes receiving a request from the first account holder to send the one or more documents to the second account holder.
- 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.
- 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 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 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 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 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 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 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.
- 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.
- document banking refers to document storage as well as trusted document transactions between one or more parties.
- 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.
- 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.
- 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.
- billing and payment module refers to a device or a software module within the document banking system to handle billing and payment activities.
- 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.
- 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.
- SSLT secure data technologies
- 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).
- 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.
- gate refers to a communication channel used by third parties to connect account holders with their respective document accounts with a document banking system.
- 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.
- 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.
- 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.
- 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.
- some of the disclosed embodiments relate to business processes, systems and methods that allow a given account holder to perform trusted document transactions.
- 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.
- 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.
- 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.
- 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.
- DB profile DataBase
- SDT Secure Data Technologies
- 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.
- the storage repository 202 may allow access only through a firewall to ensure secure access.
- the storage repository 202 may employ antispyware and anti-virus programs to ensure data integrity and security.
- 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.
- the verification module 212 performs verification of the documents, either manually or via a web-based API.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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 .
- the document transaction engine 208 receives the requests.
- the document transaction engine 208 controls and coordinates execution of all transactions.
- the document banking system 102 predefines the functionality using a structured format; for example, an Input-Output-Precondition-Effect (I-O-P-E) model.
- I-O-P-E Input-Output-Precondition-Effect
- 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.
- 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.
- 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.
- the SDT module 206 authenticates the one or more documents.
- 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 .
- 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.
- 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.
- PAN Permanent Account Number
- 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 .
- 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 .
- 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 .
- a user may log into the account to perform one or more transactions.
- 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.
- 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:
- “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.
- “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.
- “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.
- “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
- FIG. 6 is a flowchart of a method 600 for depositing a document in the document account, according to an embodiment of the disclosure.
- 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 .
- the account holder “S” may visit branch of the document banking system 102 to deposit a document.
- the account holder “S” sends a request to deposit a document and store the document in the storage repository 202 .
- 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 .
- 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.
- the SDT module 206 secures and authenticates the uploaded document, which is then stored in the storage repository 202 at step 610 .
- 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:
- 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.
- 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.
- 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.
- the verification module 212 waits for reply from the identified verification partner at step 810 .
- 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:
- 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 .
- the account holder “S” uses a “Submit” button 906 to submit request for verifying the selected document.
- 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.”
- 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.
- 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.
- the third party portal may include a web form that requires the user to submit documents through a document account.
- the third party portal may redirect the user to the document account.
- the user hereinafter, a first account holder “S”
- the first account holder “S” selects a document and requests the document transaction engine 208 to send the document to the third party.
- 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.
- the first account holder “S” 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 .
- 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.
- the gateway connects the first account holder “S” to her document account to transfer the document to the third party using the token.
- 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.
- the billing and payment module 210 updates billing information of the first account holder “S” related to the document transfer to the third party.
- 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:
- 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”.
- 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 .
- 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 .
- 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.
- 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 .
- 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.
- a first account holder “S” logs into the document account.
- the first account holder “S” selects the document to be sent to a second account holder “R”.
- 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.
- 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:
- 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.”
- the output of the transaction is that an “Acknowledgement receipt” is provided to “S”.
- 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 .
- 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.
- 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 ).
- the first account holder “S” uses a “Submit” button 1412 to send the request.
- 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 .
- 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”.
- FIG. 16 is a flowchart of a method 1600 for receiving one or more documents, according to an embodiment of the disclosure.
- a first account holder “S” logs into the document account.
- the first account holder “S” searches for a document.
- 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.
- account holders may “pull” certain documents that are disposed in the public space or an available protected of a document bank account.
- certain documents such as application forms, may be disposed in the public account space of a University or a bank.
- 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:
- 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.
- 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.
- 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.
- the document transaction engine 208 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”.
- 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:
- 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”.
- 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.
- the document transaction engine 208 allows the account holder “S” to update the document.
- 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:
- 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.”
- the output of the transaction is that an “Acknowledgement receipt” is provided to “S”.
- 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.
- some objective e.g., submitting documents required for a visa
- the present disclosure facilitates method and systems for document banking in a more secure, trusted, and reliable environment.
- the methods and systems enable account holders to perform transactions related to documents, thereby increasing productivity, and reducing hassles.
- the account holder can access his document account anytime and use the documents in any desired manner.
- the disclosed methods and systems enable account holders to perform transactions in a trusted environment by reducing spam transactions.
- 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.
Abstract
Description
- The presently disclosed embodiments relate to document banking, and more particularly, to methods and systems for facilitating trusted document transactions.
- 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.
- 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.
-
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. - 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 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.
- 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.
-
FIG. 1 illustrates an overallexemplary system 100 in which various of the disclosed embodiments may be practiced. Thesystem 100 includes adocument banking system 102, which facilitates document transactions among account holders and verification partners. Thedocument banking system 102 may be hosted on a server. The architecture of thedocument banking system 102 is explained in further detail in conjunction withFIG. 2 below. One ormore individuals 104 and one or more business(es)/organization(s) 106 (hereinafter, collectively referred as at least oneaccount holder 104 and 106) may have document accounts with thedocument banking system 102. The at least oneaccount holder document banking system 102 interact with thedocument 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 oneverification partner 108 to verify documents stored in thedocument banking system 102. The at least oneverification partner 108 includespublic offices 110,private offices 112 as well as other offices orofficials 114. Thedocument banking system 102 establishes interactions with the at least oneverification 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 withFIGS. 8 and 9 below. -
FIG. 2 illustrates thedocument banking system 102, according to one embodiment of the disclosure. Thedocument banking system 102 includes astorage repository 202, a profile DataBase (DB) 204, an Secure Data Technologies (SDT)module 206, adocument transaction engine 208, a billing andpayment 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 oneaccount holder storage repository 202 may allow access only through a firewall to ensure secure access. Further, thestorage 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 oneaccount holder SDT module 206 helps in authenticating the documents and storing the documents in a pre-defined format in thestorage repository 202. TheSDT 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. Thedocument transaction engine 208 facilitates one or more document transactions among various parties including the at least oneaccount holder verification partner 108, third parties, etc. The various types of document transactions are explained in detail in conjunction withFIGS. 4-17 below. The billing andpayment module 210 handles billing related activities associated with the one or more document transactions. When or if requested, theverification 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 oneaccount holder document banking system 102 includes a logging module to log information related to all activities performed on thedocument 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 thedocument banking system 102 so that it may take corrective actions to maintain reasonable system performance. In some embodiments, thedocument banking system 102 may also include a scanner to scan documents and a printer to print documents. - The
storage repository 202, theprofile DB 204, theSDT module 206, thedocument transaction engine 208, the billing andpayment module 210, and theverification module 212 interact with each other to execute one or more document transactions. In an exemplary embodiment, the at least oneaccount holder document banking system 102. Thedocument banking system 102 uses theprofile DB 204 to verify the login credentials of the at least oneaccount holder account holder document banking system 102. Thereafter, the at least oneaccount holder document transaction engine 208. Thedocument transaction engine 208 processes the deposit document transaction as per the predefined functionality. Thereafter, theSDT module 206 authenticates the document sent by the at least oneaccount holder storage repository 202. In some embodiments, the billing andpayment module 210 updates billing information for the at least oneaccount holder - In cases where the at least one
account holder verification module 212 identifies a relevant verification partner, in the at least oneverification partner 108, to verify the document. On successful verification, theverification module 212 sets a “verified_tag” associated with the document to “TRUE”. Finally, the billing andpayment module 210 updates billing information for the at least oneaccount holder -
FIG. 3 illustrates an exemplarydocument banking system 102, according to one embodiment of the disclosure. The at least oneaccount holder document banking system 102 using acomputer 302, amobile device 304, a document automated teller machine (DOC ATM) 306 or visit abranch 308 of thedocument banking system 102. Thecomputer 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®. Themobile 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 oneaccount holder 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 oneaccount holder DOC ATM 306 installed at a remote location from thedocument banking system 102. TheDOC ATM 306 may be integrated with bank ATMs. Further, theDOC ATM 306 may have an in-built scanner to scan documents deposited by the at least oneaccount holder DOC ATM 306 may have a built-in printer to print secure documents. Moreover, the at least oneaccount holder document banking system 102 to access the document account. - When the at least one
account holder document banking system 102, anauthentication system 310 may be used to authenticate the at least oneaccount holder document banking system 102. Theauthentication system 310 may authenticate the at least oneaccount holder profile DB 204. Theauthentication system 310 may send the requests received from the at least oneaccount holder document transaction engine 208 for execution. The input queue may send requests to thedocument 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 oneaccount holder - Thereafter, the
document transaction engine 208 receives the requests. In some embodiments, thedocument transaction engine 208 controls and coordinates execution of all transactions. For each transaction, thedocument 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: - 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 oneaccount holder - 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 withFIGS. 5-18 below. -
FIG. 4 is a flowchart of amethod 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 withFIG. 3 above. Atstep 402, thedocument 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, theSDT module 206 authenticates the one or more documents. - Next at
step 404, theverification 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 thedocument 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 withFIGS. 8 and 9 below. - Thereafter, at
step 406, thedocument transaction engine 208 determines whether any additional documents are required. If additional documents are required, then thedocument transaction engine 208 sends a request to the user to submit the remaining documents atstep 408. Then, atstep 410, the remaining supporting documents are received from the user. However, if it is determined atstep 406 that the additional documents are not required, then atstep 412, the submitted documents are scanned. Thereafter, thedocument transaction engine 208 creates an account and an associated profile atstep 414. Next, thedocument transaction engine 208 stores the submitted documents in thestorage repository 202 atstep 416. Finally, thedocument transaction engine 208 notifies the user about successful account creation atstep 418 and adds a corresponding entry into a log atstep 420. Upon successful account creation, thedocument transaction engine 208 may allocate a certain fixed amount of disk space to the user/account holder in thestorage 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 theprofile DB 204. Once a user creates a new account using themethod 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 withFIG. 5 below. -
FIG. 5 is asnapshot 500 of the display screen of thecomputer 302 used by an account holder “S”, according to an exemplary embodiment of the disclosure. Thesnapshot 500 shows a user interface that includes multiple buttons 502-518 related to various transactions that may be performed using thedocument 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 withFIGS. 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 withFIGS. 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 withFIGS. 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 withFIGS. 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 withFIGS. 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.
-
FIG. 6 is a flowchart of amethod 600 for depositing a document in the document account, according to an embodiment of the disclosure. Atstep 602, an account holder “S” logs into her document account using at least one of thecomputer 302, themobile device 304 or theDOC ATM 306. Alternatively, the account holder “S” may visit branch of thedocument banking system 102 to deposit a document. Then atstep 604, the account holder “S” sends a request to deposit a document and store the document in thestorage repository 202. Next, atstep 606, the document is scanned and uploaded. The account holder “S” may scan the document and upload the document using thecomputer 302 or amobile device 304. Alternatively, the account holder “S” may use a scanner available at theDOC ATM 306 to scan the document. Thedocument banking system 102 may accept only a subset of available file extension types (including PDF, DOC, etc.) for the scanned documents. Next, atstep 608, theSDT module 206 secures and authenticates the uploaded document, which is then stored in thestorage repository 202 atstep 610. Finally, the account holder “S” is notified about successful account creation atstep 612, and the corresponding entry is written into a log atstep 614. - The I-O-P-E model for depositing a document is provided below:
- 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”. Themethod 600 may be executed using a user interface explained in conjunction withFIG. 7 below. -
FIG. 7 is asnapshot 700 of display screen of thecomputer 302 used by the account holder “S” to deposit a document, according to an exemplary embodiment of the disclosure. Thesnapshot 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 downmenu 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. -
FIG. 8 is a flowchart of amethod 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. Atstep 802, the account holder “S” logs into the document account. Then, atstep 804, the account holder “S” selects a document in the document account and requests theverification module 212 to verify the selected document. This is explained in further detail in conjunction withFIG. 9 below. Theverification module 212 identifies a verification partner from the at least oneverification partner 108 atstep 806, and requests the identified verification partner to verify the selected document atstep 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, theverification module 212 waits for reply from the identified verification partner atstep 810. - Thereafter, at
step 812, theverification module 212 determines whether the document has been verified by the identified verification partner. If the document is not verified, then theverification module 212 aborts the transaction atstep 814 and notifies the account holder “S” about the failure atstep 816. However, if it is determined atstep 812 that the document has been verified, then the “verified_tag” is initialized to “TRUE” atstep 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 thestorage repository 202 atstep 820, and the account holder “S” is notified atstep 822. In either case of success or failure of the transaction, the entry is written into a log atstep 824. - The I-O-P-E model for the transaction “Verify_Doc” is provided below:
- 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”. Themethod 800 may be executed using a user interface explained in conjunction withFIG. 9 below. -
FIG. 9 is asnapshot 900 of the display screen of thecomputer 302 used by the account holder “S” to verify a document, according to an exemplary embodiment of the disclosure. Thesnapshot 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, amessage 908 may be displayed, wherein themessage 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.” -
FIG. 10 is a flowchart of amethod 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. Atstep 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, atstep 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, atstep 1006, the user (hereinafter, a first account holder “S”) logs into the document account. Then, atstep 1008, the first account holder “S” selects a document and requests thedocument 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 thetransaction engine 208 matches the required document against the available documents in the document account. If the required document is available, then thetransaction 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, atstep 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, atstep 1012, the billing andpayment 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 atstep 1014 and the entry is written into a log atstep 1016. - 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”. Themethod 1000 may be executed using user interfaces explained in conjunction withFIGS. 11 and 12 below. -
FIG. 11 is asnapshot 1100 of the display screen of thecomputer 302 used by the first account holder “S” to send a document, according to an exemplary embodiment of the disclosure. Thesnapshot 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 thetext field 1106. Finally, the first account holder “S” uses a “Send”button 1108 to send the document. -
FIG. 12 is asnapshot 1200 of display screen of thecomputer 302 used by the first account holder “S” to send multiple documents through the gateway, according to an exemplary embodiment of the disclosure. Thesnapshot 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 -
FIG. 13 is a flowchart of amethod 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. Atstep 1302, a first account holder “S” logs into the document account. Then, atstep 1304, the first account holder “S” selects the document to be sent to a second account holder “R”. Further, atstep 1304, the first account holder “S” sends a request to thedocument 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 theprofile DB 204. This is explained in further detail in conjunction withFIGS. 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” atstep 1306, then thedocument transaction engine 208 adds the second account holder “R” to the beneficiary list of the first account holder “S” atstep 1308. Further, atstep 1310, thedocument transaction engine 208 transfers the document to the second account holder “R”. However, if it is determined atstep 1306, that the second account holder “R” has not accepted the request sent by the first account holder “S”, then the transaction is aborted atstep 1308, and the first account holder is notified of the failure atstep 1310. Finally, the corresponding entry is written into a log atstep 1316. - The I-O-P-E model for the transaction “Send_doc_beneficiary” is provided below:
- 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”. Themethod 1300 may be executed using user interfaces explained in conjunction withFIGS. 14 and 15 below. -
FIG. 14 is asnapshot 1400 of display screen of thecomputer 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. Thesnapshot 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 thefield 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, amessage 1414 may be displayed, wherein themessage 1414 says, “Account number 267845034567 has been successfully added to your beneficiary list.” -
FIG. 15 is asnapshot 1500 of display screen of thecomputer 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. Thesnapshot 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 thefield 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 thefield 1506. Finally, the first account holder “S” activates a “Send”button 1508 to send the selected document to the second account holder “R”. -
FIG. 16 is a flowchart of amethod 1600 for receiving one or more documents, according to an embodiment of the disclosure. Atstep 1602, a first account holder “S” logs into the document account. Then, atstep 1604, the first account holder “S” searches for a document. Once the document is located, the first account holder “S” sends a request to thedocument transaction engine 208 to send the located document atstep 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, atstep 1606, thedocument 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 atstep 1608 and the first account holder “S” is notified atstep 1610. However, if it is determined that the selected document is available in public spaces or protected spaces atstep 1606, then the document is transferred atstep 1612. Finally, the corresponding entry is written into a log atstep 1614. - The I-O-P-E model for the transaction “Receive_Doc” is provided below:
- 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”. Themethod 1600 may be executed using a user interface explained in conjunction withFIG. 17 below. -
FIG. 17 is asnapshot 1700 of the display screen of thecomputer 302 used by the first account holder “S” to receive a document, according to an exemplary embodiment of the disclosure. Thesnapshot 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 thefield 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”, thedocument transaction engine 208 sends a token “Tok” to the account holder “S” by web, phone or email. Thereafter, thedocument transaction engine 208 requests the account holder “S” to input the token “Tok”. Upon the account holder“S” successfully inputting “Tok”, thedocument 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:
- 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. Thedocument transaction engine 208 requests the account holder “S” to input a token “Tok”, which thedocument transaction engine 208 transmits to “S” by web, phone or email. Upon the account holder “S” successfully inputting “Tok”, thedocument 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 thedocument 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:
- 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:
Claims (28)
Priority Applications (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/969,635 US20150052047A1 (en) | 2013-08-19 | 2013-08-19 | Methods and systems for facilitating document banking |
US14/175,025 US9825935B2 (en) | 2013-08-19 | 2014-02-07 | Gateway facilitating document transactions and related methods |
US14/254,980 US20150302386A1 (en) | 2013-08-19 | 2014-04-17 | Methods and systems for facilitating document banking on mobile devices |
US14/665,028 US9596228B2 (en) | 2013-08-19 | 2015-03-23 | Methods and systems for handling trusted content from various service providers |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/969,635 US20150052047A1 (en) | 2013-08-19 | 2013-08-19 | Methods and systems for facilitating document banking |
Publications (1)
Publication Number | Publication Date |
---|---|
US20150052047A1 true US20150052047A1 (en) | 2015-02-19 |
Family
ID=52467531
Family Applications (4)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/969,635 Abandoned US20150052047A1 (en) | 2013-08-19 | 2013-08-19 | Methods and systems for facilitating document banking |
US14/175,025 Active 2035-04-28 US9825935B2 (en) | 2013-08-19 | 2014-02-07 | Gateway facilitating document transactions and related methods |
US14/254,980 Abandoned US20150302386A1 (en) | 2013-08-19 | 2014-04-17 | Methods and systems for facilitating document banking on mobile devices |
US14/665,028 Active 2035-04-17 US9596228B2 (en) | 2013-08-19 | 2015-03-23 | Methods and systems for handling trusted content from various service providers |
Family Applications After (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/175,025 Active 2035-04-28 US9825935B2 (en) | 2013-08-19 | 2014-02-07 | Gateway facilitating document transactions and related methods |
US14/254,980 Abandoned US20150302386A1 (en) | 2013-08-19 | 2014-04-17 | Methods and systems for facilitating document banking on mobile devices |
US14/665,028 Active 2035-04-17 US9596228B2 (en) | 2013-08-19 | 2015-03-23 | Methods and systems for handling trusted content from various service providers |
Country Status (1)
Country | Link |
---|---|
US (4) | US20150052047A1 (en) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9596228B2 (en) | 2013-08-19 | 2017-03-14 | Xerox Corporation | Methods and systems for handling trusted content from various service providers |
US10163153B1 (en) * | 2013-08-26 | 2018-12-25 | Wells Fargo Bank, N.A. | Electronic disclosure delivery system and method |
CN110598453A (en) * | 2019-09-20 | 2019-12-20 | 中国银行股份有限公司 | Client information data acquisition method and device |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10740052B2 (en) * | 2016-12-20 | 2020-08-11 | Sap Se | Integrated services for forms generation and maintenance on cloud |
GB2566765B (en) | 2017-03-23 | 2022-09-14 | Pismo Labs Technology Ltd | Method and system for restricting transmission of data traffic for devices with networking capabilities |
CN107679419B (en) * | 2017-10-17 | 2020-07-14 | 南通纤麦家纺科技有限公司 | Screen capturing method and device |
US11537670B2 (en) * | 2020-09-14 | 2022-12-27 | Open Text Holdings, Inc. | System and method for event driven generation of content |
Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030028495A1 (en) * | 2001-08-06 | 2003-02-06 | Pallante Joseph T. | Trusted third party services system and method |
US20070220614A1 (en) * | 2006-03-14 | 2007-09-20 | Jason Ellis | Distributed access to valuable and sensitive documents and data |
US20080134294A1 (en) * | 2006-11-30 | 2008-06-05 | Microsoft Corporation | Personal Site Privacy Policy |
US20080235236A1 (en) * | 2007-03-20 | 2008-09-25 | Docommand Solution, Inc. | Secure Document Management System |
US20090288143A1 (en) * | 2008-05-16 | 2009-11-19 | Sun Microsystems, Inc. | Multi-factor password-authenticated key exchange |
US20100116877A1 (en) * | 2001-03-07 | 2010-05-13 | Parmelee Christopher L | Automated banking machine that operates responsive to data bearing records |
US20100146005A1 (en) * | 2007-08-15 | 2010-06-10 | Donglin Wang | Method and apparatus for storing document data in docbase management system |
US20140047507A1 (en) * | 2011-02-25 | 2014-02-13 | Bioid Ag | Method for publicly providing protected electronic documents |
Family Cites Families (29)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5783808A (en) * | 1996-01-11 | 1998-07-21 | J. D. Carreker And Associates, Inc. | Electronic check presentment system having transaction level reconciliation capability |
US6289322B1 (en) * | 1998-03-03 | 2001-09-11 | Checkfree Corporation | Electronic bill processing |
US5832460A (en) | 1995-06-02 | 1998-11-03 | International Business Machines Corporation | Method and system for bill presentation and payment reconciliation |
US7805365B1 (en) * | 1999-10-25 | 2010-09-28 | Jpmorgan Chase Bank, N.A. | Automated statement presentation, adjustment and payment system and method therefor |
US8380630B2 (en) * | 2000-07-06 | 2013-02-19 | David Paul Felsher | Information record infrastructure, system and method |
AU2001288263A1 (en) * | 2000-08-14 | 2002-02-25 | I2 Technologies, Inc. | Network application program interface facilitating communication in a distributed network environment |
CA2355785C (en) | 2001-08-16 | 2010-06-01 | Ibm Canada Limited-Ibm Canada Limitee | Electronic presentation of invoices using a trusted document repository |
CA2378289A1 (en) * | 2002-03-22 | 2003-09-22 | Billwhiz Inc. | Method and system for document presentment between generic publishers and generic subscribers |
CA2484562A1 (en) * | 2002-08-30 | 2004-03-11 | Sap Aktiengesellschaft | Method and system for electronic bill presentment and payment |
GB0318000D0 (en) * | 2003-07-31 | 2003-09-03 | Ncr Int Inc | Mobile applications |
WO2007047683A2 (en) * | 2005-10-14 | 2007-04-26 | Uhlig Llc | Dynamic variable-content publishing |
US7958562B2 (en) * | 2006-04-27 | 2011-06-07 | Xerox Corporation | Document access management system |
US9911114B2 (en) * | 2006-07-06 | 2018-03-06 | Qualcomm Incorporated | Methods and systems for making a payment via a stored value card in a mobile environment |
EP2128830A1 (en) * | 2008-05-30 | 2009-12-02 | Gemplus | A method and an electronic device for transferring application data from a source electronic device to a destination electronic device |
US8095112B2 (en) * | 2008-08-21 | 2012-01-10 | Palo Alto Research Center Incorporated | Adjusting security level of mobile device based on presence or absence of other mobile devices nearby |
US20100094756A1 (en) * | 2008-10-10 | 2010-04-15 | Gelpay, Llc | System and method for rapid financial transactions through an open financial exchange or wire transfer |
US8578465B2 (en) * | 2009-07-21 | 2013-11-05 | Cisco Technology, Inc. | Token-based control of permitted sub-sessions for online collaborative computing sessions |
US20110153362A1 (en) * | 2009-12-17 | 2011-06-23 | Valin David A | Method and mechanism for identifying protecting, requesting, assisting and managing information |
US20120072837A1 (en) * | 2010-05-10 | 2012-03-22 | Triola C Richard | Method, system, apparatus, and program for on demand document delivery and execution |
CN101894335A (en) | 2010-06-17 | 2010-11-24 | 中兴通讯股份有限公司 | Payment method and system for on-line transaction and home gateway |
GB2483051A (en) | 2010-08-17 | 2012-02-29 | Mpower Payment Ltd | Ordering and paying for goods over a network using a mobile device |
GB2484653A (en) | 2010-10-07 | 2012-04-25 | Mpower Payment Ltd | Universal transaction gateway |
US20130144785A1 (en) * | 2011-03-29 | 2013-06-06 | Igor Karpenko | Social network payment authentication apparatuses, methods and systems |
US9058515B1 (en) * | 2012-01-12 | 2015-06-16 | Kofax, Inc. | Systems and methods for identification document processing and business workflow integration |
US20150052047A1 (en) | 2013-08-19 | 2015-02-19 | Xerox Business Services, Llc | Methods and systems for facilitating document banking |
US20150178708A1 (en) * | 2013-12-19 | 2015-06-25 | Maxim Reutov | Dynamic payment processing gateway with rules based payment processing engine |
US20150199660A1 (en) * | 2014-01-14 | 2015-07-16 | Bank Of America Corporation | Communication network for collecting data and executing electronic transaction services |
US9286403B2 (en) * | 2014-02-04 | 2016-03-15 | Shoobx, Inc. | Computer-guided corporate governance with document generation and execution |
US9805014B2 (en) * | 2014-08-28 | 2017-10-31 | Xerox Corporation | Methods and systems for facilitating trusted form processing |
-
2013
- 2013-08-19 US US13/969,635 patent/US20150052047A1/en not_active Abandoned
-
2014
- 2014-02-07 US US14/175,025 patent/US9825935B2/en active Active
- 2014-04-17 US US14/254,980 patent/US20150302386A1/en not_active Abandoned
-
2015
- 2015-03-23 US US14/665,028 patent/US9596228B2/en active Active
Patent Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20100116877A1 (en) * | 2001-03-07 | 2010-05-13 | Parmelee Christopher L | Automated banking machine that operates responsive to data bearing records |
US20030028495A1 (en) * | 2001-08-06 | 2003-02-06 | Pallante Joseph T. | Trusted third party services system and method |
US20070220614A1 (en) * | 2006-03-14 | 2007-09-20 | Jason Ellis | Distributed access to valuable and sensitive documents and data |
US20080134294A1 (en) * | 2006-11-30 | 2008-06-05 | Microsoft Corporation | Personal Site Privacy Policy |
US20080235236A1 (en) * | 2007-03-20 | 2008-09-25 | Docommand Solution, Inc. | Secure Document Management System |
US20100146005A1 (en) * | 2007-08-15 | 2010-06-10 | Donglin Wang | Method and apparatus for storing document data in docbase management system |
US20090288143A1 (en) * | 2008-05-16 | 2009-11-19 | Sun Microsystems, Inc. | Multi-factor password-authenticated key exchange |
US20140047507A1 (en) * | 2011-02-25 | 2014-02-13 | Bioid Ag | Method for publicly providing protected electronic documents |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9596228B2 (en) | 2013-08-19 | 2017-03-14 | Xerox Corporation | Methods and systems for handling trusted content from various service providers |
US10163153B1 (en) * | 2013-08-26 | 2018-12-25 | Wells Fargo Bank, N.A. | Electronic disclosure delivery system and method |
US11301928B1 (en) | 2013-08-26 | 2022-04-12 | Wells Fargo Bank, N.A. | Electronic disclosure delivery system and method |
US11688000B1 (en) | 2013-08-26 | 2023-06-27 | Wells Fargo Bank, N.A. | Electronic disclosure delivery system and method |
CN110598453A (en) * | 2019-09-20 | 2019-12-20 | 中国银行股份有限公司 | Client information data acquisition method and device |
Also Published As
Publication number | Publication date |
---|---|
US20150302386A1 (en) | 2015-10-22 |
US9825935B2 (en) | 2017-11-21 |
US20150227896A1 (en) | 2015-08-13 |
US9596228B2 (en) | 2017-03-14 |
US20160285862A1 (en) | 2016-09-29 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9805014B2 (en) | Methods and systems for facilitating trusted form processing | |
US8949706B2 (en) | Systems and methods for distributed electronic signature documents | |
US20150052047A1 (en) | Methods and systems for facilitating document banking | |
US20110270763A1 (en) | Methods and apparatus for a financial document clearinghouse and secure delivery network | |
US20090271321A1 (en) | Method and system for verification of personal information | |
US20080127331A1 (en) | Method, system, and apparatus for linked personas authenticator | |
US11798007B1 (en) | Compliance document creation, modification, and provisioning | |
JP6524205B1 (en) | Transaction management system, transaction management apparatus, transaction management method and transaction management program | |
TW201939332A (en) | Authentication method and apparatus | |
US20150106246A1 (en) | Systems and methods for secure financial transactions | |
CA2970301C (en) | Improved network for onboarding and delivery of electronic payments to payees | |
JP7461241B2 (en) | Customer information management server and customer information management method | |
AU2020202543A1 (en) | Unauthenticated access to artifacts in commerce networks | |
US20150213405A1 (en) | Methods and systems for facilitating document transactions | |
US11057323B1 (en) | System and method for distributed document upload via electronic mail | |
US20220335397A1 (en) | Systems and methods for compliance at transaction kiosks | |
US20230259602A1 (en) | Method for electronic identity verification and management | |
KR20230082150A (en) | An electric contract system and a contract document sending and receiving algorithm | |
WO2009080771A1 (en) | A method and system of conducting a communication |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: XEROX CORPORATION, CONNECTICUT Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:PIRATLA, NISCHAL M;MONDAL, ANIRBAN , ,;DASGUPTA, KOUSTUV , ,;AND OTHERS;SIGNING DATES FROM 20130802 TO 20130805;REEL/FRAME:031040/0235 Owner name: XEROX BUSINESS SERVICES, LLC, TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:PIRATLA, NISCHAL M;MONDAL, ANIRBAN , ,;DASGUPTA, KOUSTUV , ,;AND OTHERS;SIGNING DATES FROM 20130802 TO 20130805;REEL/FRAME:031040/0235 |
|
AS | Assignment |
Owner name: XEROX CORPORATION, CONNECTICUT Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:JOHNSTON, MARK E;REEL/FRAME:037993/0096 Effective date: 20160315 Owner name: XEROX CORPORATION, CONNECTICUT Free format text: CORRECTIVE ASSIGNMENT TO REMOVE THE SECOND ASSIGNEE NAME PREVIOUSLY RECORDED AT REEL: 031040 FRAME: 0235. ASSIGNOR(S) HEREBY CONFIRMS THE ASSIGNMENT;ASSIGNORS:PIRATLA, NISCHAL MURTHY, ,;MONDAL, ANIRBAN , ,;DASGUPTA, KOUSTUV , ,;AND OTHERS;SIGNING DATES FROM 20130802 TO 20130805;REEL/FRAME:038104/0462 |
|
AS | Assignment |
Owner name: CONDUENT BUSINESS SERVICES, LLC, TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:XEROX CORPORATION;REEL/FRAME:041542/0022 Effective date: 20170112 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |