WO2009042113A2 - Système d'acquisition et d'authentification de document - Google Patents

Système d'acquisition et d'authentification de document Download PDF

Info

Publication number
WO2009042113A2
WO2009042113A2 PCT/US2008/011006 US2008011006W WO2009042113A2 WO 2009042113 A2 WO2009042113 A2 WO 2009042113A2 US 2008011006 W US2008011006 W US 2008011006W WO 2009042113 A2 WO2009042113 A2 WO 2009042113A2
Authority
WO
WIPO (PCT)
Prior art keywords
document
documents
user
owner
users
Prior art date
Application number
PCT/US2008/011006
Other languages
English (en)
Other versions
WO2009042113A3 (fr
Inventor
Carter Kirkwood
Misha Gridnev
Original Assignee
Unlimited Cad Services, Llc
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Unlimited Cad Services, Llc filed Critical Unlimited Cad Services, Llc
Priority to CA2700222A priority Critical patent/CA2700222A1/fr
Publication of WO2009042113A2 publication Critical patent/WO2009042113A2/fr
Publication of WO2009042113A3 publication Critical patent/WO2009042113A3/fr

Links

Classifications

    • 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
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • 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/24—Querying
    • G06F16/245—Query processing
    • G06F16/2457—Query processing with adaptation to user needs
    • G06F16/24573—Query processing with adaptation to user needs using data annotations, e.g. user-defined metadata
    • 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
    • G06F21/6263—Protecting personal data, e.g. for financial or medical purposes during internet communication, e.g. revealing personal data from cookies

Definitions

  • the present invention generally relates to information access and distribution, and in particular to techniques for the access and distribution of authenticated sensitive private information, such as financial and medical information.
  • the document owner controls distribution of the document to desired users, such as a mortgage broker or a tax accountant, but without the ability to change the contents or at least without the ability to do so without the ability to make changes without detection.
  • desired users such as a mortgage broker or a tax accountant
  • the author may provide the owner with a document that the owner can cause to ,be received by a desired user or other recipient while maintaining the authentication of the document by the issuing author, for example, the financial institution.
  • the privacy and security of the data contents may be protected by encryption.
  • the author may encrypt the document and the owner may select recipients to receive the decryption key, for example, via a website [0006] It would be advantageous to provide an application to facilitate users to manually or automatically acquire, manage, store and index documents, data, and metadata, and to share these items with authenticity and user privacy protections.
  • the present invention improves on the system disclosed in the earlier application.
  • the present invention is directed to a document acquisition and authentication system that comprises a network-based application (e.g., software implemented processes and functions) that on behalf of its users can automatically: a) collect Digital Documents, b) create standardized descriptive metadata related to each Digital Document, c) use that descriptive metadata to organize, sort, and filter the collected Digital Documents, d) collect and create evidence that third party users can use to judge the authenticity of particular Digital Documents, e) protect the users privacy during the collection, storage, and sharing of the Digital Documents. More specifically the web-based application of the
  • System provides users with functionalities including user management, Source management, automatic and manual document acquisition, and document management and sharing.
  • the disclosed System is also able to receive Digital Documents that users manually upload into it and it enables users to manually enter standardized descriptive metadata. For manually uploaded documents the disclosed System can then automatically a) use that descriptive metadata to organize, sort, and filter the uploaded Digital Documents, b) collect and create evidence that third party users can use to judge the authenticity of the uploaded Digital Documents, c) protect the user's privacy during the uploading, storage, and sharing of the Digital Documents.
  • the System operates over the Internet, wherein the user interface application is a web-based application.
  • Fig. 1 is a block diagram illustrating the user management function in accordance with one embodiment of the present invention.
  • Fig. 2 is a block diagram illustrating the document acquisition function in accordance with one embodiment of the present invention.
  • FIG. 3 is a block diagram illustrating the document management function in accordance with one embodiment of the present invention.
  • Fig. 4 illustrates the My Folders tree page in accordance with one embodiment of the present invention.
  • Fig. 5 illustrates a document list for a user's folder page in accordance with one embodiment of the present invention.
  • Fig. 6 illustrates the document management page in accordance with one embodiment of the present invention.
  • Fig. 7 is a block diagram illustrating the verified contact of the contact management process in accordance with one embodiment of the present invention.
  • Fig. 8 illustrates the home page for the System's Web site in accordance with one embodiment of the present invention.
  • Fig. 9 illustrates the Manage Folders page in accordance with one embodiment of the present invention.
  • FIG. 10 is a block diagram illustrating sharing folder names function in accordance with one embodiment of the present invention.
  • Fig. 1 1 is a block diagram illustrating sharing an added folder name function in accordance with one embodiment of the present invention.
  • Fig. 12 is a block diagram illustrating deleting a shared folder name function in accordance with one embodiment of the present invention.
  • Fig. 13 is a block diagram illustrating unsharing folder names function in accordance with one embodiment of the present invention.
  • Fig. 14 is a web page illustrates how users search for documents in accordance with one embodiment of the present invention.
  • Fig. 15 is a block diagram illustrating acquiring a new version of a previously acquired document function in accordance with one embodiment of the present invention.
  • Fig. 16 is a block diagram illustrating automatic check list (year-to-year) function in accordance with one embodiment of the present invention.
  • Fig. 17 is a block diagram illustrating automatic check list (received statements) function in accordance with one embodiment of the present invention.
  • Fig. 18 is a block diagram illustrating automatic forwarding process in accordance with one embodiment of the present invention.
  • Fig. 19 is a block diagram illustrating automatic forwarding with approval process in accordance with one embodiment of the present invention.
  • Fig. 20 is a block diagram illustrating third-party request process.
  • Fig. 21 is a block diagram illustrating third-party request of system folder function in accordance with one embodiment of the present invention.
  • Fig. 22 is a block diagram illustrating third-party search and request function in accordance with one embodiment of the present invention.
  • Fig. 23 is a block diagram illustrating capital gains planning function in accordance with one embodiment of the present invention.
  • Fig. 24 is a block diagram illustrating integration with other software packages in accordance with one embodiment of the present invention.
  • Fig. 25 is a block diagram illustrating automatic to-do list function in accordance with one embodiment of the present invention.
  • Fig. 25 is a block diagram illustrating statement auditing function in accordance with one embodiment of the present invention.
  • Fig. 27 is a block diagram illustrating superimposed dynamic content function in accordance with one embodiment of the present invention.
  • Fig. 28 is a block diagram illustrating replaced dynamic content function, hash on static content only in accordance with one embodiment of the present invention.
  • Fig. 29 is a block diagram illustrating replaced dynamic content function, hash on entire document in accordance with one embodiment of the present invention.
  • Fig. 30 illustrates the Documents to Share/Revoke pane in accordance with one embodiment of the present invention.
  • Fig. 31 is a block diagram illustrating manual redaction with contextual data function in accordance with one embodiment of the present invention.
  • Fig. 32 is a block diagram illustrating automatic redaction function in accordance with one embodiment of the present invention.
  • Fig. 33 is a block diagram illustrating default redaction function in accordance with one embodiment of the present invention.
  • Fig. 34 is a block diagram illustrating manual redaction with no contextual data function in accordance with one embodiment of the present invention.
  • Fig. 35 is a block diagram illustrating document-class redaction function in accordance with one embodiment of the present invention.
  • Fig. 36 is a block diagram illustrating default redaction rer document class function in accordance with one embodiment of the present invention.
  • Fig. 37 is a block diagram illustrating document ownership transfer function in accordance with one embodiment of the present invention.
  • Fig. 38 is a block diagram illustrating decryption function in accordance with one embodiment of the present invention.
  • Fig. 39 is a schematic diagram of an exemplary computing environment in which aspects of the invention may be implemented.
  • Useful devices for performing the software implemented processes, operations and functions of the present invention include, but are not limited to, general or specific purpose digital processing and/or computing devices, which devices may be standalone devices or part of a larger system. These devices may be selectively activated or reconfigured by a program, routine and/or a sequence of instructions and/or logic stored in the devices to undertake the disclosed functions, processes and operations. In short, use of the processes, functions and operations described and suggested herein is not limited to a particular processing configuration.
  • Fig. 39 shows an exemplary computing environment in which aspects of the invention may be implemented.
  • the computing system environment 100 is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the invention. Neither should the computing environment 100 be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary operating environment 100.
  • the invention is operational with numerous other general purpose or special purpose computing system environments or configurations.
  • Examples of well known computing systems, environments, and/or configurations that may be suitable for use with the invention include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, embedded systems, distributed computing environments that include any of the above systems or devices, and the like.
  • the invention may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer.
  • program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types, including the networked based (e.g., web-based) application of the System described herein below.
  • the invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network or other data transmission medium.
  • program modules and other data may be located in both local and remote computer storage media including memory storage devices.
  • an exemplary system for implementing the invention includes a general purpose computing device in the form of a computer 1 10.
  • Components of computer 1 10 may include, but are not limited to, a processing unit 120, a system memory 130, and a system bus 121 that couples various system components including the system memory to the processing unit 120.
  • the processing unit 120 may represent multiple logical processing units such as those supported on a multi-threaded processor.
  • the system bus 121 may also be implemented as a point-to-point connection, switching fabric, or the like, among the communicating devices.
  • Computer 1 10 typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by computer 1 10 and includes both volatile and nonvolatile media, removable and non-removable media.
  • Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal (i.e., a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal) such as a carrier wave or other transport mechanism and includes any information delivery media.
  • a modulated data signal i.e., a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal
  • communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.
  • the system memory 130 includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) 131 and random access memory (RAM) 132.
  • ROM read only memory
  • RAM random access memory
  • BIOS basic input/output system
  • RAM 132 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 120.
  • Fig. 39 illustrates operating system 134, application programs 135, other program modules 136, and program data 137.
  • the computer 1 10 may also include other removable/non-removable, volatile/nonvolatile computer storage media.
  • Fig. 39 illustrates a hard disk drive 141 , a magnetic disk drive 151 that reads/writes a removable magnetic disk 152, and an optical disk drive 155 that reads/writes a removable optical disk 156, such as a CD ROM or other optical media.
  • the hard disk drive 141 is typically connected to the system bus 121 through a non-removable memory interface such as interface 140, and magnetic disk drive 151 and optical disk drive 155 are typically connected to the system bus 121 by a removable memory interface, such as interface 150.
  • hard disk drive 141 is illustrated as storing operating system 144, application programs 145, other program modules 146, and program data 147. Note that these components can either be the same as or different from operating system 134, application programs 135, other program modules 136, and program data 137. Operating system 144, application programs 145, other program modules 146, and program data 147 are given different numbers here to illustrate that, at a minimum, they are different copies.
  • a user may enter commands and information into the computer 20 through input devices such as a keyboard 162 and pointing device 161 , commonly referred to as a mouse, trackball or touch pad.
  • Other input devices may include a microphone, joystick, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit 120 through a user input interface 160 that is coupled to the system bus, but may be connected by other interface and bus structures, such as a parallel port, game port or a universal serial bus (USB).
  • a monitor 191 or other type of display device is also connected to the system bus 121 via an interface, such as a video interface 190.
  • computers may also include other peripheral output devices such as speakers 197 and printer 196, which may be connected through an output peripheral interface 195.
  • the computer 1 10 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 180.
  • the remote computer 180 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 1 10, although only a memory storage device 181 has been illustrated in Fig. 39.
  • the logical connections depicted in Fig. 39 include a local area network (LAN) 171 and a wide area network (WAN) 173, but may also include other networks.
  • LAN local area network
  • WAN wide area network
  • Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet.
  • the computer 1 10 When used in a LAN networking environment, the computer 1 10 is connected to the LAN 171 through a network interface or adapter 170. When used in a WAN networking environment, the computer 1 10 typically includes a modem 172 or other means for establishing communications over the WAN 173, such as the Internet.
  • the modem 172 which may be internal or external, may be connected to the system bus 121 via the user input interface 160, or other appropriate mechanism.
  • program modules depicted relative to the computer 1 10, or portions thereof may be stored in the remote memory storage device.
  • Fig. 39 illustrates remote application programs 185 as residing on memory device 181. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.
  • the network-based application of the System may be implemented in one or more servers, computers, etc., in the environment shown in Fig. 39.
  • Acquired File a file consisting a combination of Digital Document and Related metadata, in particular: Source name, Document Date, Acquisition Date, Originator name, Owner name, hash result.
  • the application has all six metadata items, but other applications could have a smaller subset of metadata.
  • An Acquired File may also contain other data discussed in this disclosure.
  • Application Server That part of the System that accepts requests and commands from users and serves documents and other information to users.
  • the Application Server handles encryption and decryption tasks as well.
  • ADAM Automatic Document Acquisition Module
  • Authenticity Evidence - Data that is related to a particular Digital Document that is relevant to whether or not a particular document is authentic and which can be taken into consideration by a System user in his or her deciding if they believe a particular Digital Document is authentic. With respect to any particular Digital Document the System collects and stores the following: Integrity Evidence, the name of that Digital Document's Source, and that Document's Acquisition Date.
  • Contact - A Contact is a registered user of the System with whom another user can share Acquired Files. Contacts are maintained in users' address books. A Contact may also be referred to as a Recipient, Sender, or sharing partner.
  • Contextual Data is a machine-readable representation of the information in a Digital Document.
  • Contextual data typically adheres to one of a number of formats based on Extensible Markup Language (XML), such as the Open Financial Exchange (OFX) format or the U.S. Internal Revenue Service's standard XML format. Other institution- or industry-specific XML formats may be used as well.
  • XML Extensible Markup Language
  • Credentials - Credentials are tokens that are presented to the System to gain access to a resource. A common form of credentials is a user name and password pair.
  • Descriptive Metadata Extraction (DME) - DME consists of software implemented components which extract document metadata from Digital Documents and/or Source's websites.
  • Digital Document - A Digital Document is the digital representation of information that can be presented to users as a document, such as an Adobe PDF, Microsoft Word, Microsoft Excel, GIF, or HTML file.
  • Integrity Evidence This term refers to evidence indicating that a document has not been altered since the Acquisition Date.
  • Originator - The Originator is the individual or entity that created a Digital Document or that is likely to be perceived to be the creator of a particular Digital Document.
  • the Originator's name is used for organizing, filtering, and sorting Digital Documents. As a potential contrast, see also Source and Owner.
  • Owner - The Owner is the individual or entity that owns certain rights in a Digital Document and/or has effective control over a document.
  • An example of these kinds of rights would be a user's privacy rights in his or her financial and medical records.
  • Source and Originator see also Source and Originator.
  • Recipient is the individual or entity with whom the document Sender intends to share a document.
  • the Recipient is also referred to as a Contact or sharing partner once the Recipient becomes a registered user of the System.
  • the document Sender In the process of document sharing, the document Sender is the document Owner in a state where he/she wishes to share a document with a Recipient.
  • Source - The Source is the individual or entity that last had control of a document just before the document was acquired by the System.
  • the Source data is used for providing document integrity evidence about a related Digital Document.
  • Originator and Owner The Source is the individual or entity that was the last party to have control of the document before it entered into the System, as evidenced by, without limitation, any of the following: (a) a user's System credentials; (b) URL information for a location where the postings of documents is controlled by a known entity or individual; and (c) a secure communication channel that only a particular entity or individual has access to.
  • a Source, Owner, and Originator may or may not be the same person or entity.
  • a Source financial institution from which the System obtains Digital Documents directly will also be the Originator for those documents.
  • Person 1 scans a paper document from a given financial institution and uploads the resulting Digital Document into the System
  • the Originator will be that financial institution, but Person 1 will be the Source and the Owner.
  • a third party could scan documents from a financial institution and upload them into the System on behalf of Person 1.
  • the Source (the third party), the Originator (the financial institution), and the Owner (Person 1) are all different entities.
  • System The disclosed system as a whole comprising the disclosed functions and features herein; the System consists of software implemented modules and processes and associated hardware.
  • Administrative Metadata - Information used to manage the object or control access to it.
  • administrative metadata could include how the Digital Document was scanned, its storage format, an copyright Ownership information.
  • Structural Metadata It ties each object to others to make up logical units.
  • Structural metadata can enable single Source publishing and flexible display of content.
  • structural metadata could relate individual images of pages from a book to the others that make up the book or could track that the same content is used in multiple documents.
  • Descriptive Metadata It describes the intellectual content of the associated object. Descriptive metadata is typically used for bibliographic purposes and for search and retrieval. For example, knowing that a particular document is a contract and its effective date could be used to quickly find that particular contract among many other documents.
  • the illustrated embodiment of the System comprises a web-based software implemented process that is designed to provide its users with a means of collecting, managing, and sharing documents while preserving confidentiality.
  • the System provides the following functionality: [0091] 1. User registers and logs into the System's website.
  • User configures his/her profile to acquire documents from Sources; for example, a user might configure his profile to collect bank accounts from a financial institution. Configuring the profile involves providing the System with information about the accounts a user holds at an institution, such as the credentials used to log into the institution's website.
  • User configures the System to schedule automatic document acquisition at specific intervals, or to collect the documents manually when the user asks the System to do so. The System determines the appropriate schedule to automatically, periodically, collect documents on the user's behalf. The user can initiate document collection manually whenever he/she visits the System's website.
  • the user could override the System-determined collection schedule by selecting a time frequency (including, without limitation, daily, weekly, and monthly) with which the System should attempt to collect documents from a given Source. [0100] 4. Once the documents are collected, the user can use the System's website to view documents easily in one central location, as well as share them with other users, such as their accountants.
  • a time frequency including, without limitation, daily, weekly, and monthly
  • document Recipients can obtain information about the document that can helps them verify the authenticity of the document, such as how long the document has been in the System, confirmation that the document has remained unaltered while in the System, and who originally created the document.
  • the System has software implemented functional components that provide users with the following functionality:
  • the System has components that handle user registration and logins into the System's website.
  • the System can verify a user's phone and e-mail information by sending an e-mail with unique information a user must use to access the System and calling a specified number with an authentication code which the user then must enter in the System to verify his or her access to that phone number.
  • Source management The System enables users to store credentials for Sources. For example, if a user has an account at River Bank, and has online banking, the user can store the login information in the System. The System stores this information in a way so that the information can later be used to collect documents from the Source automatically at intervals set by the user.
  • the Source management component is designed to log into the user's Source account and to handle challenge questions and security codes with which the Source may respond.
  • ADAM Automatic Document Acquisition Module
  • ADAM includes software implemented components that can collect Digital Documents and information related to those Digital Documents (metadata) from Sources.
  • ADAM can use the credentials stored during the user management process to log into Sources' websites. It can navigate the Sources' websites, locate Digital Documents, extract metadata, and copy the information to the System's data store; all without user intervention. Users can configure the System to schedule ADAM to collect documents at specific intervals. Because ADAM's navigational and collection components rely heavily on the then current layout, structure, and format of each Source's website, these components will need to be updated whenever relevant changes are made to the layout, structure, and/or format of any Source website. Regular monitoring and updating by the System's development and quality assurance staff is important for ongoing functional availability. Manual document upload can be done by each user. The user can use the System website to upload a digital representation of a paper document. [0106] 4. Document management and sharing (see Fig.
  • the System provides users with the ability to view and sort documents.
  • the System enables users to share documents amongst one another. This process involves mechanisms by which the System requires the Sender and the Recipient of shared documents to be mutually authenticated to maintain confidentiality of the documents.
  • the Contact creation process is described in "Contact Management" later below.
  • the disclosed invention's metadata taxonomy includes administrative, structural, and descriptive types of metadata.
  • the definitions for most, if not all, of the Metadata Taxonomy are made available to users of the System so they can understand how to use the metadata to find things, determine authenticity of a document, protect their privacy, and reuse data.
  • the disclosed invention includes Administrative metadata that enables its users to manage what individuals or entities have access to particular documents. Administrative metadata is collected, stored, and presented to ' users as evidence related to the authenticity of a document.
  • the disclosed administrative metadata taxonomy includes the following types of metadata:
  • Source a The invention tracks the Source using unique identification for each Source.
  • It is used for providing evidence about the party that last had control of a particular document before it was added to the System. This evidence is intended to assist users in determining if a particular document is authentic.
  • c Examples include without limitation: i. Bank of America ii. Joe Smith (or any other individual's name) d. Citibank, e. ETrade, f. Kaiser, g. AT&T Wireless [0113]
  • Owner a Used granting control or management of certain rights and access to documents in the System. b. Examples include without limitation: i. Joe Smith (or any other individual's name) c.
  • the disclosed invention includes a descriptive metadata taxonomy that enables the efficient and intuitive use by non professionals of record keeping System that include without limitation financial, legal, and medical records.
  • the disclosed descriptive metadata taxonomy includes the following hierarchy: [0117] 1. Originator a. Examples include without limitation: i. Bank of America, ii. Citibank, iii. ETrade, iv. Kaiser, v. AT&T Wireless, vi. Mary's Cafe, LLC. [0118] 2. Account number a. Defined as numeric or textual way of tracking different accounts or clients of any Source. b.
  • Document Date a Defined as the official date of a document or the date upon which a designated action occurred. The date format can be selected by the user.
  • Examples include without limitation: i. The particular date that a check was deposited, ii. The particular date that a check was cleared, iii. The particular date that a contract was signed, and iv. The particular date that a contract became effective.
  • Document Type a Defined as the official date of a document or the date upon which a designated action occurred. The date format can be selected by the user.
  • Examples include without limitation: i. The particular date that a check was deposited, ii. The particular date that a check was cleared, iii. The particular date that a contract was signed, and iv. The particular date that a contract became effective.
  • Account Type i Defined as the legal type of account or an industries' term for a type of account.
  • r ii. Examples include without limitation: iii. Checking, iv. Savings,
  • custom metadata In addition to the administrative and descriptive metadata associated with a given document, users can define and use custom metadata of their own design. Such custom metadata is manifested in the ability to create and manage custom folders (see “Managing Folders" discussed later below). Custom metadata is for a user's benefit only; unlike descriptive and administrative metadata, custom metadata cannot be used by third party users. [0127] - Evolution of Metadata
  • the administrative and descriptive metadata can be created in one or more of three ways:
  • Metadata is derived or inferred from information made available by a Source, for example, on a Source's Web site or Web application. For more information on this method, see
  • Metadata is directly supplied by or acquired from a Source in some standard format. (See “Secure Peer-To-Peer Connection” discussed later below.)
  • the administrative and descriptive metadata associated with a document can be used by third parties with whom a document is shared (see “Sharing Documents” discussed later below), for example, for filtering and sorting of shared documents.
  • the System employs a centralized document acquisition methodology.
  • document acquisition, metadata acquisition and extraction, as well as the storage and sharing of documents is all performed at the server level rather than on users' local computers.
  • the System is the central point to which users connect to view and share documents.
  • the Source may also connect to the System to push documents into the System.
  • Encryption, decryption, and document integrity verification occurs at the central location as well.
  • a user has several accounts at financial institutions and wants to be able to view and share the financial documents from a single location. To be able to do so, the user registers with the
  • the user logs into her System account and configures her profile to store the login information for the financial institutions.
  • the System connects to the financial institution's website and enters the login information to verify the credentials.
  • the System has the user provide challenge question answers and security codes if a financial institution requests those for login.
  • ADAM then extracts the relevant data and translates it into the appropriate metadata form, runs the hash function, encrypts the Digital Document, and stores the metadata, hash, and Digital Document in the appropriate parts of the System's storage.
  • the System creates accounts and assigns the appropriate Digital Documents to the accounts.
  • the user can now view the Digital Documents from the System's website and can share them with other System users, such as her tax accountant.
  • the user can also assign documents to existing folders or organize the documents using custom folders.
  • the user can modify the phone number provided during the registration process.
  • the user requests the System to calls the provided number with an authentication code.
  • the System verifies if the entered code matches the code sent to the user's phone. If the codes match, the System sends an invitation to the accountant's email address. If the codes do not match, the System prompts the user to try again.
  • the System displays a page asking the accountant to log into the System to accept the invitation.
  • the accountant requests the System to send an authentication code to the phone number provided by the user.
  • the System calls the tax accountant's phone number with an authentication code.
  • John Smith is the Originator, Source, and Owner of the letter.
  • River Bank creates a monthly statement. Customer A uses the System to automatically collect that monthly statement from River Bank's web site. In this case, River Bank is the Originator and the Source of that monthly statement. Customer A is the Owner of that monthly statement.
  • Global Bank is the Originator and Mary is both the Source and Owner of that monthly statement.
  • Tim hires Scanners-R-Us to scan it into one of their computer and upload it onto the System
  • Scanners-R-US indicates to the System that Tim is the rightful owner of that monthly statement.
  • Dollar Brokerage is the Originator
  • Scanners-R-Us is the Source
  • Tim is the Owner of that monthly statement.
  • the user interaction functionality of the System pertains to the tasks a user of the System can perform, other than document-management tasks.
  • User interaction tasks include registering with the System and logging into the System, managing financial institution credentials, viewing documents, managing contacts, customizing the user experience, and deleting various elements.
  • [0177] User clicks a link in the email or enters the URL information in the email into a browser.
  • a User Information Entry screen displays that recognizes some identifying information in the URL and associates this web page visit with the previous web page visit and the information that was collected in the previous visit.
  • the user selects either a free trial subscription (available for users to try the service for a limited time period) or a permanent, paid subscription.
  • the System provides an interface that enables the user to authenticate himself or herself and create a new password:
  • the System presents a list of the financial institutions that the user has set up in the
  • the System enables users to configure their profile to indicate from which Sources they want to acquire documents.
  • users can initiate manual document collection or configure the
  • Supported Sources are institutions for which the System is preconfigured with institution information such as the URL,
  • the user enters their login information (credentials) for the Source website. [0200] 5. If desired, the user can opt to save the credentials to the System. (In another embodiment, the user can also set the frequency interval for the System to automatically retrieve documents from the Source without user intervention.) If the user chooses to store credentials in the
  • the System can automatically, without user intervention, acquire documents on behalf of the user. Otherwise, the user must manually initiate each document acquisition process, providing credentials each time.
  • the System validates the credentials by logging into the Source website using the
  • the System passes the information request and/or challenge question to the user. Once the user enters the relevant information and/or answer into the System, then the System relays the relevant information and/or answer into the Source's website.
  • the System creates a login for the Source and shows the user an updated list of
  • ADAM collects the documents and metadata from the
  • Source creates the appropriate accounts in the System.
  • the user can enter this information.
  • Users can configure the System to automatically collect documents at a scheduled interval without user intervention.
  • users can opt to manually initiate document collection; in that case, the System only acquires documents when users manually intervene to initiate the acquisition.
  • Users can specify how often they want the System to acquire new documents. For example, document acquisitions can be scheduled to occur weekly, monthly, quarterly, and yearly. For these scheduled acquisitions, users must have stored their credentials for the Source in the System.
  • users can opt to store their credentials for Sources, or they can choose to provide that information at the time of acquisition.
  • the System starts an interactive acquisition, it checks for stored credentials. If none are stored, the System prompts the user to enter the credentials. Users have the option to then store the credentials if they so wish.
  • [0219] To view a particular document, the user does the following: [0220] 1. The user accesses the File Cabinet. The System provides the user with a list of custom folders (see “Managing Folders” discussed later below), similar to the My Folders tree illustrated in
  • the System decrypts the document (see "Decryption” discussed later below), and displays the selected Digital Document in a separate page.
  • U.S. patent application serial no. 1 1/750178 discloses enabling users to confidentially share their documents in a distributed embodiment where the documents are stored on users' local computers.
  • the present System includes software implemented components that enable users to securely share documents with other users. For more information, refer to "Sharing Documents" discussed later below.
  • the sharing process is designed to work with the Contact Management process through which Senders and the Recipients of their documents can gain confidence that they are only sharing Digital Documents with who they intend to.
  • the System thus provides a process by which users can view certain verified information about one another as a means to mutually authenticate one another.
  • the System automatically verifies that a particular person has access to both the email and phone number provided.
  • the Sender's Contact information is verified first.
  • Sender's email addresses are verified when they first register with the System.
  • Senders want to share one or more documents with a Recipient they are asked to confirm which phone number they want to have verified. This can be the number entered during the registration process, or a different number.
  • the System automatically calls the phone number supplied by the Sender and plays a recorded message that includes a one-time authorization code. The Sender then has to enter that one time key into the appropriate field in the application.
  • the Sender wants to change either his/her email address or phone number at some future time, they would need to verify those before they could be changed.
  • the Sender's email address is used in the invitation to the Recipient and the Sender's phone number is shown to the Recipient when they register with the System so that the Recipient can determine how confident they are that the Sender is who the Recipient expects him/her to be.
  • the Sender When a Sender invites a Recipient, the Sender enters the Recipient's email address and phone number into the invitation form.
  • the System emails an invitation to the Recipient and informs the Recipient that the Sender wants to securely share one or more documents with the Recipient and that to get access to the document, the Recipient must register with the System.
  • the invitation includes a link with embedded identification information, such as the Sender's phone number.
  • the System If the Recipient accepts the invitation, the System calls the phone number that the Sender provided for the Recipient plays a recorded message with an authorization code. The Recipient must enter that one time code into the appropriate field in the System. This confirms that the Recipient had access to the phone number provided by the Sender. Once the Recipient has entered the one time key he or she can get access to the document(s) that the Sender wanted to share with him or her.
  • the Sender can modify the phone number provided during the registration process.
  • the Sender requests the System to call the provided number and play an authentication code.
  • the System verifies if the entered code matches the code sent to the Sender's phone. If the codes match, the System sends an invitation to the Recipient's email address. If the codes do not match, the System prompts the Sender to try again.
  • the System displays a page asking the Recipient to log into the System to accept the invitation.
  • the System calls the Recipient's phone number with an authentication code.
  • the Recipient enters the authentication code in the System.
  • the Sender then can tell the recipient the unique string (either face to face, by phone, or by any other means)
  • Sender also selects one or more Acquired Files he or she wants to share.
  • the System displays a page asking the Recipient to log into the System to accept the invitation.
  • the System enables users to manage the user experience by giving them the option to hide or show various elements, including Accounts, Contacts, and Folders.
  • the System enables an Owner to set an Account to "Hide” or "Show.” A "hidden” Account still exists in the System, and the System still collects documents related to that Account (see
  • the System enables an Owner to set a Contact to "Hide” or "Show.”
  • a "hidden” Contact still exists in the System, but does not appear in a list of Contacts with whom to share a document. Also, any documents received from or shared with a "hidden” Contact will not appear in a list of shared or received documents.
  • the System enables an Owner to set a Folder to "Hide” or "Show.”
  • a "hidden” Folder still exists in the System, and still has its documents associated with it, but it but does not appear in the
  • the System enables a user to remove a financial institution that he or she had previously set up in the System. When a user's institution is removed, all documents that were acquired from that institution are permanently deleted from the System, and any documents that were shared with third parties are no longer available to those third parties.
  • the System enables a user to remove an account that the System had previously set up for him or her. When an account is removed in this manner, all documents that were acquired for that account are permanently deleted from the system, and any documents that were shared with third parties are no longer available to those third parties. Furthermore, the System will no longer collect documents pertaining to that account.
  • the System enables an Owner to remove a Contact from his or her Contacts list. Any documents that the Owner has shared with that Contact will no longer be available to that Contact.
  • the System enables an Owner to remove a custom Folder from his or her File Cabinet (see
  • the System provides three methods for acquiring documents: (a) Manual upload; (b) Push or pull via secure peer-to-peer network connection; and (c) Download via secure HTTP or FTP connection.
  • a user can upload a Digital Document to the System manually. Before the document is added to the System, the user needs to manually provide the following descriptive metadata: (a) Originator of the document; (b) Creation date of the document; (c) Account number (Blank is an option); (d) Type of Account (Other is an option); and (e) Type of Document (Other is an option). [0290] The follow steps are undertaken:
  • the System automatically captures and stores the fact that this particular user is the Source for all uploaded documents (the user can not alter the Source information). [0293] 3. The user navigates to the document file to be uploaded, enters the document name and type, and selects the account for the document to be uploaded to in the System. [0294] 4. The user clicks a button to upload the document.
  • the System verifies that the document satisfies the upload policy and scans the document for viruses.
  • the upload policy consists of restrictions on the file format and maximum file size.
  • the System automatically records the user as being the Source for all uploaded documents.
  • the System provides application programming interfaces (APIs), which would specify in detail how third-party software can interact with the System.
  • APIs would also provide secure forms of communication with particular Sources and the Sources would then be able to push new Digital Documents and related contextual data, document authenticity evidence, and/or metadata to the System.
  • the Source indicates to the System which user of the System is the Owner of particular documents.
  • either the Source's computer server or the System would provide a way for a user to indicate that he/she not only wants to receive Digital Documents but that he/she wants them to be sent to the System. If the user indicated his/her consent to the System, then that consent would be transmitted to the Source.
  • the System initiates communication with the Source's computer in order to "pull" documents and related metadata into the System.
  • U.S. patent application no. 1 1/750178 (US 2008/0005024A1) describes an auto download function and an archive function. In the embodiments described in that application, both functions run locally on users' computers.
  • ADAM is an agent that runs on a centralized server.
  • the auto download function is referred to as the Automatic Document Acquisition Module (ADAM).
  • ADAM Automatic Document Acquisition Module
  • the System is also able to receive documents uploaded manually by users (see below for details).
  • ADAM's function is to collect Digital Documents and information about those Digital Documents (document metadata) from document Sources (For example an insurance company's website).
  • ADAM emulates user behavior, such as logging into and navigating around the website, to download documents and collect pertinent, related, data from the Source.
  • Servers typically use a mixture of HTML and JavaScript. When users interact with website pages through a browser, JavaScript may be executed.
  • the System's programmers used the following process to analyze Source websites to program ADAM:
  • ADAM contains specific routines for each Source it supports.
  • ADAM includes a scheduler that automatically determines when to attempt to acquire documents from a particular Source on behalf of a particular Owner. (In an alternative embodiment, the System enables Owners to configure how frequently they want Digital Documents are to be acquired from a particular Source.) Alternatively, a user can initiate the document acquisition process for a given Source on demand.
  • ADAM is able to log in to protected websites that require the presentation of Credentials. Users enter the relevant Credentials into the System in the Account Creation for Supported Sources process. Those Credentials are encrypted and stored by the System and retrieved as needed to access a particular Source's website. ADAM uses a user's Credentials for a particular Source and passes it to the routine specifically designed for that Source to collect Digital Documents that are available on that Source's website for that user.
  • Source-specific routine for that Source may need to be updated to function appropriately. As such, there is a need for human intervention by programmers and quality assurance personnel to monitor the updates of Sources and to adjust Source-specific routine as Sources change. As Source-specific routines are modified the System is updated to replace the old routines with the new routines.
  • User interaction with the server can occur as HTML forms. Programmers analyze forms to extract form fields.
  • a form field is a name/value pair. Field values can be entered directly by the user or modified by JavaScript as a result of user interactions with the web page. The programmers created software components to emulate execution of the JavaScript to arrive at the values the server expects.
  • Links send a get request to the server via HTML or Java script. Programmers analyzed the links and created software components so that ADAM sends the appropriate get request to the server for each link.
  • JavaScript may modify some aspects of the HTML content tree. Those modifications may result in a browser sending a request to a server to retrieve the updated content.
  • the server may track those updates to distinguish human users from automated software components. Therefore the programmers must reproduce this behavior when interacting with Source websites. For example, modifying an SRC attribute of the IMAGE HTML element forces the browser to retrieve an updated image from the server.
  • Servers use cookies to track various user activities. Often cookies are generated or modified by JavaScript as a result of user interactions with the page. The programmers need to determine that behavior to reproduce the behavior in ADAM. [0323] - Descriptive Metadata Acquisition
  • ADAM collects descriptive metadata for each document.
  • the following metadata are collected for each document: Source name, Document date, Acquisition Date, Originator name, Owner name, and hash result.
  • a smaller set of metadata may be collected.
  • ADAM uses the following Sources to collect the metadata about a document: (a) Extracted contents of Digital Documents; and (b) Source web page scrapings [0326] ADAM uses the following items as information sources for metadata: [0327] 1. URL information
  • ADAM can determine the certain metadata from data contained within institution's website URLs. For example, if a document is collected from www.greatbank.com, ADAM would list the Source name as Great Bank. As another example, if ADAM clicks a link called "statements," it could use that information to determine that the document type is a statement. [0328] 2. Text on the website or in the extracted document contents
  • ADAM can identify certain descriptive metadata by searching for certain phrases that are used in particular contexts. When those phrases or data are found, ADAM associates certain descriptive metadata with the relevant document. For example, it may search for the term "Your Bank of America Standard Checking Statement” on documents collected from the Bank of America website. If that exact term is found, ADAM stores the document type as a "Statement” and the account type as a "Checking" account.
  • ADAM can identify certain descriptive metadata based upon the graphical placements of certain data on a page and/or its proximity to other data. In this case, ADAM uses the graphical placement of data or text to locate descriptive metadata. ADAM is programmed to know that certain data or text is located in a particular place on a document or website page from a particular Source and/or of a particular document type and/or on a particular webpage. For example, ADAM could be programmed to look in the upper right-hand corner of a statement from a particular credit card company for the document date. In addition to the location, ADAM can use proximity of items to keywords to find metadata. For example, if a string of 8 digits is located in proximity to the string "account number" then this Component would identify that string of digits to be the account number.
  • the Source-specific routines are created, monitored, and updated on a centralized server and the routines are either pushed to an individual user's local computer whenever there is an update or an individual's computer regularly checks with the central server to find out if updated Source-specific routines are available and downloads any updated routines.
  • Managing Documents With MetadataOnce users have registered with the System, and documents have been added to the System through automatic collection or manual upload, users can view, share, and organize their Digital Documents and metadata using the System's Web site.
  • Fig. 8 illustrates the home page for the System's Web site. The user can click the File Cabinet tab from any location in the System's Web site. The File Cabinet is where users can manage documents.
  • the File Cabinet displays the accounts into which the documents are automatically organized.
  • the System can use the Originator name, account number, account type, document type, and Document Date to automatically present the documents to each user in an organized fashion that is similar to how many users organize their paper documents in a physical filing cabinet.
  • the System organizes the documents into folders; one for each account number from each Originator. It then allows users to search or filter documents within those folders by the Document Date or Document Type. Every document in the System is automatically placed into a single folder (documents are not duplicated across multiple folders).
  • the System enables users to create their own folders (e.g., custom folders) and to organize those folders into a hierarchical structure (e.g., a customized folder structure). Documents can be copied to multiple folders. Documents do not need to be copied to any of the folders. Users can remove documents from a folder without affecting other folders. [0336] Users can manually create and organize folders as follows: [0337] 1. The user clicks the Manage tab.
  • FIG. 9 illustrates the Manage Folders page.
  • users can add, delete, rename, and move folders. Any document can appear in none, one, or multiple folders. Each document must have an Originator, and can have only one Originator. The Originator cannot be changed. ,
  • the System can generate a list of organizational categories (folder names) used by other users, ranked by popularity, as suggestions for organizing the Owner's documents.
  • the System will perform this function as follows: [0340] 1.
  • the System will provide an interface that enables the Owner to share the names of the folders the Owner has created in his or her File Cabinet.
  • the System will also maintain a table containing all Owners' shared folder names and a count of how many times each unique folder name is used.
  • Owner's folder names in the table incrementing the count for existing folder names and adding entries for folder names not already in the table. (See Fig. 10.)
  • the System will provide an interface that enables the Owner to view a list of folder names, displayed in order of popularity (i.e., decreasing order of how many times each folder name is used).
  • the interface will enable the user, when adding a new folder, to click on a folder name in the list and have a folder with that name added to the desired location in the File Cabinet folder structure.
  • the System can enable users to share entire folder structures as suggestions for other users.
  • the System will perform this function as follows:
  • the System will provide an interface that enables an Owner to select a folder in the
  • the interface will also enable the Owner to provide a description or other commentary about the folder structure.
  • the System will store the folder structure and the Owner's description in a database.
  • the System will provide an interface that enables other users to view shared folder structures, to make comments about them, and to rate them (for example without limitation, assigning a "star rating" of 0 to 5 stars).
  • the System will store comments and ratings associated with each shared folder structure, and can display the shared folder structures in order of average rating.
  • the System interface will enable a user to add a shared folder structure to any location in his or her File Cabinet.
  • the System can automatically assign documents into system folders.
  • a system folder is a preconfigured folder that the System provides and which cannot be deleted.
  • the folder hierarchy could have a Taxes system folder that contains tax year folders, such 2006, 2007, and 2008.
  • the System could then assign all tax-related documents received between September 30, 2006 and September 30, 2007 to the 2007 Taxes folder.
  • the System could use the Digital Document's metadata to determine whether a document is tax-related, for example, if the document is of a particular document type, such as 1099s, W2s, KIs, 1098s.
  • a user would also be able to choose to add or remove documents from the system folders independently of the System's automatically assigning documents to a system folder.
  • the user may believe that a particular document, such as a check or credit card receipt, is relevant for his/her 2007 taxes, and could copy that document into the 2007 Taxes folder. If the System automatically added a particular document to a particular system folder and the user later removed that document from the folder, the System would not re-add that document back into that folder at a later date. - [0355] Searching for Documents
  • the user enters the search criteria, such as the account, document type, and/or a custom date, and clicks Apply.
  • the documents that meet the search criteria display.
  • the System will identify a new version of a given acquired document (for example, when a brokerage generates a new version of a 1099 form for a given tax year), and will indicate the most recent version to the Owner.
  • the System will perform this function as follows (see Fig. 15):
  • the System will enable the Owner to compare a list of particular documents received in one time period to a list of corresponding documents received in another time period, for purposes of compiling a list of documents that have not been received in the latter time period. [0369] The System will perform this function as follows (see Fig. 16):
  • the System creates a Taxes folder for each tax year, and automatically populates it with tax -related documents, such as 1099s and K-Is. An owner can assign additional documents to this folder, such as canceled checks for charitable donations or for quarterly estimated taxes.
  • the System will use the documents, descriptive metadata, and contextual data in the previous year's Taxes folder to generate a list of documents that the Owner should expect to receive.
  • the System will enable the Owner to view this list at any time.
  • the System will enable the Owner to delete items from the list; for example, if the Owner closed an account that previously generated a form 1099, the Owner could delete that item from the list because no form 1099 will be forthcoming for that account.
  • step 2 if the System had acquired a form 1099 from a bank for one tax year, the System will create a list including a form 1099 from that bank for the next tax year, and indicate whether or not it has been received. If the System does receive the document, in step 3 above the System would update the list to indicate it had been received. In that way, the Owner can track the status of his or her tax documents and follow up with financial institutions that have not generated needed tax documents.
  • the System would use the fact that documents (such as statements), indicating activity in an account, had been received regarding an account during a tax year in order to indicate to the Owner that the appropriate tax document or documents should be expected, and whether or not they have been received.
  • documents such as statements
  • the System will perform this function as follows (see Fig. 17):
  • the System analyzes the documents received during the tax year, searching for activity in accounts (such as savings, money-market, and brokerage accounts) that should result in a tax document being generated.
  • accounts such as savings, money-market, and brokerage accounts
  • the System will enable the Owner to view this list at any time.
  • the System will enable the Owner to delete items from the list; for example, if the
  • An Owner can instruct the System to automatically share, upon acquisition, all documents meeting certain criteria with one or more third parties.
  • the System will perform this function as follows (see Fig. 18):
  • the System will provide an interface, similar to the Searching interface (see “Searching for Documents” discussed above), that enables an Owner to specify certain metadata values for documents that he or she wants to have automatically shared with one or more Contacts. [0386] 2. The System will also provide an interface that enables an Owner to select the one or more Contacts with which to share documents that meet the criteria specified in step 1 above. [0387] 3. The System will enable the Owner to save the specifications made in steps 1 and 2 with a specific name, as an "automated forwarding entity.” The Owner will be able to save multiple automated forwarding entities, each with different specifications and different names. The Owner will be able to enable or disable individual automated forwarding entities. [0388] 4.
  • the System Each time the System acquires a document for an Owner (see “Document Acquisition” discussed above), the System examines the descriptive metadata (see “Descriptive Metadata Acquisition” discussed above) associated with that document and determines if it meets the criteria for any of the enabled automated forwarding entries for that Owner.
  • all form 1099 documents can be automatically shared with a third- party tax preparer.
  • the Owner would select documents of type "1099," and would select the Contact who is the Owner's tax preparer.
  • the Owner would save these selections as a named automated forwarding entity, ensuring that the automated forwarding entity is enabled (i.e., the System will execute it).
  • the System will compare the document's descriptive metadata against the selections in the saved automated forwarding entity.
  • the document is automatically shared with the selected tax preparer.
  • the Owner can select a time frequency with which to share identified documents (i.e., so that documents meeting the criteria are shared all at once at the end of each time period, rather than shared individually as they are acquired).
  • This embodiment incorporates all the features described in the base Automatic
  • the interface will include a time-frequency selection that enables the Owner to choose how often (for example without limitation, weekly or monthly), to forward documents to the selected Contact or Contacts.
  • step 4 of the base embodiment instead of examining each document as it is acquired, at the end of each time period the System will examine all documents that were acquired during the period, and compare each document against all enabled automated forwarding entities.
  • step 5 of the base embodiment the System will forward all documents that meet the criteria of any of the enabled automated forwarding entities.
  • the Owner can specify a minimum number of documents meeting the criteria that the System should acquire before sharing them. This embodiment incorporates all the features described in the base Automatic
  • the interface will include a minimum-document selection that enables the Owner to specify how many matching documents must be acquired before sharing them.
  • step 5 of the base embodiment the System will maintain a list of documents that meet the criteria for each enabled automated forwarding entity, and share them automatically with the designated Contact or Contacts when the minimum number of documents is reached.
  • This embodiment is similar to the Automatic Forwarding embodiment, except that prior to sharing the document or documents, the System would notify the Owner that one or more documents are ready to be shared, and give the Owner the opportunity to approve or deny sharing for any particular document or for all documents.
  • the System would perform this function as follows (see
  • the System will also provide an interface that enables an Owner to select the one or more Contacts with which to share documents that meet the criteria specified in step 1 above.
  • the System's interface will also enable the Owner to indicate, for a given set of criteria, whether the System should notify the Owner for approval prior to sharing documents.
  • the System will enable the Owner to save the specifications made in steps 1 through 3 with a specific name, as an "automated forwarding entity.”
  • the Owner will be able to save multiple automated forwarding entities, each with different specifications and different names.
  • the Owner will be able to enable or disable individual automated forwarding entities.
  • the System examines the descriptive metadata associated with that document and determines if it meets the criteria for any of the enabled automated forwarding entries for that Owner.
  • System will send the Owner an email notification that there are documents awaiting approval.
  • the System notifies the Owner that there are documents awaiting approval the next time the Owner logs into the System.
  • the System will enable the Owner to view a list of documents that are awaiting approval and the Contact or Contacts to whom they are to be shared.
  • the Owner can choose, with a single click, to approve or deny all documents to all Contacts, or can choose to approve or deny individual documents and individual Contacts.
  • a third-party user can request that all of an Owner's documents meeting certain criteria be shared.
  • the System would perform this function as follows (refer to Fig. 20):
  • the System's interface will also enable the third-party user to select the Owner from the third-party user's list of Contacts (see “Contact Management” discussed above).
  • the System notifies the Owner the next time the Owner logs into the
  • the System enables the Owner to view the contents of the folder created in step 3, and to approve or deny sharing for each document (or for all documents, with a single click). The Owner then saves these approval/denial specifications.
  • a mortgage broker could use the interface in steps 1 and 2 to request all W-2 statements for the last three years for an Owner who is applying for a loan.
  • steps 3 and 4 the System would create a unique folder in the Owners File Cabinet, and assign those W-2 statements to that folder.
  • the System would notify the Owner that the mortgage broker has requested the documents, and in step 6, the Owner would view the list of documents and choose whether or not to share each one. After the Owner makes these selections, in step 7 the System would notify the mortgage broker that the documents have been shared.
  • System Folders above, the System can create folders and automatically assign documents to them, for example without limitation, folders for tax-related documents for each tax year.
  • a third-party user such as a tax preparer, could request all the documents in a system folder (for example, a "2007 Taxes" folder) for a particular Owner.
  • the System will perform this function as follows (see Fig. 21):
  • the System will provide an interface that enables a third-party user to select an Owner for the third-party user's list of Contacts (see "Contact Management" discussed above).
  • the System's interface will also enable the third-party user to select the desired system folder or system folders from a list of system folders in the Owner's File Cabinet. [0423] 3. The System then notifies the Owner by email that a Contact has requested documents.
  • the System notifies the Owner the next time the Owner logs into the
  • the System enables the Owner to view the contents of the requested system folder or system folders, and to approve or deny sharing for each document (or for all documents, with a single click). The Owner then saves these approval/denial specifications.
  • an Owner can give permission to one or more third-party users to conduct a search of the metadata for the Owner's documents (see "Searching for Documents" discussed above). Using the results of the search, the third-party user can select documents that he or she would like to view. The System would then notify the Owner (by email, or when the Owner logs into the System, or by some other means) that the third-party user is requesting access to those documents. The Owner would have the opportunity to approve or deny sharing for any particular document or for all documents. The System will perform this function as follows (see Fig. 22):
  • the System will provide an interface that enables a third-party user to select the
  • the System will also provide an interface, similar to the Searching interface (see
  • System submits a query to the database, requesting a list of matching documents.
  • the database returns a list of matching documents.
  • the System's interface will display these results to the third-party user.
  • the System's interface will enable the third-party user to select those documents he or she wants to have access to, and to request access to those documents.
  • the System notifies the Owner the next time the Owner logs into the
  • the System enables the Owner to view the list of requested documents, and to approve or deny sharing for each document (or for all documents, with a single click). The Owner then saves these approval/denial specifications.
  • Contextual data can be in any format, but typically in a format that is based on Extensible Markup Language (XML).
  • XML Extensible Markup Language
  • Common examples of XML-based contextual data formats include the Open Financial Exchange (OFX) format and the U.S. Internal Revenue Service's standard XML format. Other institution- or industry-standard formats may be used as well.
  • the contextual data is provided by the Source, either embedded with the document image file or in a separate file that the System associates with the document image file.
  • the contextual data can be embedded in the document image file, or the System can derive or infer it from the document image file.
  • the System can search the text for keywords.
  • the System can use optical character recognition and analyze the image for keywords and graphical proximity of labels and values.
  • the contextual data is stored either embedded in the document image file or in a separate file.
  • the contextual data is combined with the document image data, document metadata, and authenticity evidence information in a single file of a proprietary file format that can be written and read only by the System.
  • contextual data for several documents may be provided in a single file.
  • a single contextual data file might contain the data from six or 12 months of monthly statements.
  • the System can analyze the contextual data to determine which contextual data items should be associated with each document image file.
  • the System extracts the required contextual data as follows:
  • the System determines what contextual data is needed.
  • the request will be in the form of a combination of document metadata values (in order to narrow the scope of the search to certain documents) and a certain tag or combination of tags (in order to locate the correct contextual data).
  • the System searches the document metadata for the correct document or documents and then searches the associated contextual data for the requested tags.
  • the System copies the data, and provides that data to the requester (another part of the System or another software program) in an appropriate format.
  • the request (step 1) can come from another software program that communicates directly with the System.
  • the data is returned to the other software program (step 3) in an appropriate format.
  • Tax preparation software used by that tax preparer is integrated with the System.
  • the tax preparation application knows that it needs to find out if any stocks have been sold in the relevant tax year. [0456] 5. The tax preparation application sends a request to the System for brokerage "Trade
  • the System uses document metadata to search all of the Owner's documents that the tax preparer has access to, to select only those documents that are "Trade Confirmations" from the relevant tax year (for example, 2007).
  • the System extracts "Type of Trade” contextual data from each selected document by searching the document for the "Type of Trade” tag.
  • the System extracts "Stock Symbol” contextual data from each selected document by searching the document for the "Stock Symbol” tag and copying the content data (for example, the symbol could be "IBM").
  • the Tax preparation application then sends a request to.the System for brokerage
  • the System uses document metadata to search all of the Owners documents that the
  • Tax Preparer has access to, to select only those documents that are "Trade Confirmations.”
  • the System extracts "Type of Trade” contextual data from each selected document by searching the document for the "Type of Trade” tag.
  • the System extracts "Stock Symbol” contextual data from each selected document by searching the document for the "Stock Symbol” tag.
  • the System extracts "Transaction Amount” contextual data from each selected document by searching the document for the "Transaction Amount” tag and copying the content data
  • the System automatically identifies specific lots of purchased shares of stock that could be designated as "sold" following a share sale transaction. This feature will enable users to plan their capital gains for tax purposes.
  • the System will perform this function as follows
  • the System will enable the user to reorder the list in order of ascending or descending capital gains, and will be able to separate the list into long-term and short-term capital gains lists, • based on the transaction dates and the current Internal Revenue Service definitions of "long-term” and "short-term.”
  • the System will enable the user to add a note to the metadata for a given "buy" Transaction Confirmation document, indicating the number of shares that were sold and the date. This feature will prevent the user's inadvertently designating the same lot of shares for more than one "sell" transaction.
  • the System will enable the user to assign the "sell" Transaction Confirmation document and the applicable "buy” Transaction Confirmation document or documents in the Taxes system folder for the appropriate tax year (see “System Folders” discussed above).
  • step 3 above the System will also search in the contextual data for Statement documents in that account in order to determine if there have been name changes, stock symbol changes, stock splits, or other activity that would affect capital gains calculations, and properly account for these activities when ordering the list of lots (in steps 4 and 5 above).
  • the System uses contextual data from Statement documents in order to export transaction data for use in other software packages, for example without limitation, Quicken and TurboTax (developed by Intuit, Inc.), TaxCut (developed by H&R Block), Microsoft Excel, and
  • the System will search document metadata to determine if any documents of type Statement have been received during the time period. [0490] 2. If Statement documents have been received, the System will inform the Owner (by email, or the next time the user logs in to the System, or by some other means) that the transaction data is ready to be exported.
  • the System will provide an interface that enables the Owner to choose a format, appropriate to his or her external software package, for exporting the data.
  • the System then decrypts (see “Decryption” discussed later below) all Statements acquired during the time period and extracts all transaction information from the contextual data.
  • the System generates a file containing the exported data in the format chosen in step
  • This embodiment is an enhancement to the Third-party Request and Third-party Search and Request automatic document sharing embodiments discussed above.
  • a third- party user can request specific contextual information, along with the documents containing that information, for use in an external software package
  • the information can be exported in a format that can be read by the mortgage broker's software, eliminating the need to manually re-enter the data.
  • the System's interface will additionally enable the third-party user to request data (in addition to the documents themselves) in one or more of several categories, including without limitation assets, debts, and income, in aggregate form (totaled across all applicable financial institutions), individual form (one entry for each institution), or both.
  • the Owner additionally approves sharing of the contextual data, and the System notifies the third-party user that the documents are ready to be shared. [0501] 3.
  • the System gives the third-party user the option to download the requested additional data.
  • the System Upon request from the third-party user, the System generates a file containing the exported data in a format of the third-party user's choosing, appropriate for the third-party user's software package.
  • the third-party user saves the file on his or her local computer, and then uses the target software package to import the data.
  • a mortgage broker who is a third-party user of the System can request information such as total assets, total debts, or total income — information that would be aggregated from several documents each — and import that data into a software package that the mortgage broker uses to evaluate the creditworthiness of an applicant (Owner).
  • the System will use contextual data from an Owner's acquired documents to compile a list of important dates and present it to the Owner.
  • the System will perform this function as follows (see Fig. 25):
  • the System will enable the Owner to mark each item as "Completed,” “Dismissed,” or other status values.
  • the Owner can instruct the System to display only current items, or only items with a particular status, or items in a specified date range, or some combination.
  • the System could notify the Owner of upcoming items by email, text message, or other means.
  • the System will use contextual data from a checking account statement
  • the System decrypts the document (see “Decryption” discussed later below) and analyzes the document's contextual data, extracting all information related to checks (such as check number, date cleared, and amount).
  • the System searches the document metadata for the canceled checks identified in step 2, decrypts the check images, and extracts, from each canceled check image file, the area where the check writer writes the numerical amount of the check.
  • the System displays the information from the statement along with the information extracted from each canceled check, so that the Owner can visually compare the amounts and note any discrepancies.
  • the System will enable the Owner to display any listed canceled check image in its entirety.
  • the System could use handwriting recognition technology to "read" the amount on the canceled check and compare it with the amount on the statement, and alert the Owner of any discrepancies. This could be conducted automatically as a background process.
  • the System could conduct other auditing tasks, such as comparing the date cleared from the statement with the date the check was written, to identify cases where postdated checks were cleared prematurely.
  • the System enables acquired documents to include dynamic advertising content, or any dynamic content (i.e., content that changes each time a user views the document) provided by the Source, in such a way as to preserve the document authenticity evidence data of the static document content.
  • the System analyzes the document's contextual data to determine if the document includes any dynamic content.
  • new dynamic content is superimposed over the original dynamic content, as follows (see Fig. 27):
  • Decryption discussed later below
  • the System analyzes the document's contextual data to determine if it contains dynamic content.
  • the system also runs the hash function on the decrypted document (including the "old" dynamic content, if any), and the two hash functions are compared to verify the authenticity of the document.
  • the System replaces the old dynamic content with new dynamic content, as follows (see Fig. 28):
  • System analyzes the document's contextual data to determine if the document includes any dynamic content.
  • the System replaces the old dynamic content with new dynamic content as follows (see Fig. 29):
  • Decryption discussed later below
  • the System analyzes the document's contextual data to determine if it contains dynamic content.
  • the system also runs the hash function on the decrypted document (including the "old" dynamic content, if any), and the two hash functions are compared to verify the authenticity of the document.
  • Fig. 30 illustrates the Documents to Share/Revoke pane.
  • the System would enable the Owner to hide or cover (redact) certain information on a document prior to sharing it, so that a third-party user could not see or electronically discover that information.
  • the extractable (field-specific) contextual data described in U.S. application serial no. 1 1/750178 (US 2008/0005024A1), paragraph 00044, can relate each piece of information in a document to an area of the document's image file.
  • the Owner redacts portions of a particular document for a particular sharing instance, where the document has extractable contextual data associated with it.
  • the System performs this function as follows (see Fig. 31):
  • the System's interface enables the Owner to select, on the document's image, the portions of the document to redact (by clicking on the affected data values, or by drawing redaction boxes over the desired areas, or by some other means).
  • the System encrypts and stores information about the redacted areas and redacted contextual data in a file (called the "redaction file”) stored separately from, but associated with, the image file.
  • the Owner then proceeds to share the document with one or more Contacts.
  • the System notifies that Contact or Contacts that there are new shared documents available.
  • the System uses the information in the redaction file to apply redactions to appropriate areas of the image, and to delete the extractable contextual data associated with those areas.
  • the System will provide an Owner with an interface that enables the Owner to select from a list of common document fields, including without limitation Address, Telephone Number,
  • the System also provides an interface, similar to the Search interface (see “Searching for Documents” discussed above), that enables the Owner to specify metadata values in order to limit redactions to documents meeting certain criteria.
  • the System also provides an interface that enables the Owner to select particular
  • redaction entity The Owner can create multiple redaction entities.
  • the System enables the Owner to enable or disable each redaction entity.
  • the System then analyzes the extractable contextual data associated with the document to determine if any of the fields selected in step 1 are present in the document.
  • the System creates a copy of the document image file and associated contextual data, determines what portions of the document image file to redact, applies redaction boxes to those portions in the copy of the image file, and deletes the affected data in the copy of the contextual data.
  • the Owner would be able to select only fields to redact (as in step 1 above), and redactions would be applied to these fields in all documents shared with all
  • an Owner can instruct the System to apply redaction, by default, to certain fields on all documents, or all documents meeting certain criteria, prior to sharing.
  • the Owner will have the opportunity (by clicking on affected areas of the document's image, or by some other means) to unredact one or more redacted areas, add areas to redact (as in the Manual Redaction embodiment), or both.
  • the documents have extractable contextual data associated with them.
  • the System will perform this function as follows
  • the System will provide an Owner with an interface that enables the Owner to select from a list of common document fields, including without limitation Address, Telephone Number,
  • the System also provides an interface, similar to the Search interface (see “Searching for Documents” discussed above), that enables the Owner to specify metadata values in order to limit redactions to documents meeting certain criteria.
  • redaction entity The Owner can create multiple redaction entities.
  • the System enables the Owner to enable or disable each redaction entity.
  • the System's interface enables the Owner to unredact areas that are redacted by default (by clicking on the redacted areas, or by some other means), and to select additional portions of the document to redact (by clicking on the affected data values, or by drawing redaction boxes over the desired areas, or by some other means).
  • the System encrypts and stores information about the redacted areas and redacted contextual data in a file (called the "redaction file”) stored separately from, but associated with, the image file.
  • the Owner then proceeds to share the document with one or more Contacts.
  • the System notifies that Contact or Contacts that there are new shared documents available.
  • the System uses the information in the redaction file to apply redactions to appropriate areas of the image, and to delete the extractable contextual data associated with those areas.
  • the system then serves up the redacted copy of the document to the Contact. (In another embodiment, the System would run a second hash function on the redacted image of the document, so as to indicate to the Contact which parts of the redacted document were altered by the redaction process.)
  • the Owner can use an interface that enables a user to select, on the document's image, portions of a document to redact.
  • the document has no extractable contextual data associated with it.
  • the System will perform this function as follows (see Fig. 34):
  • the System's interface enables the Owner to select, on the document's image, the portions of the document to redact (by drawing redaction boxes over the desired areas, or by some other means).
  • the Owner then proceeds to share the document with one or more Contacts.
  • the System notifies that Contact or Contacts that there are new shared documents available.
  • the System uses the information in the redaction file to apply redactions to appropriate areas of the image.
  • an Owner could instruct the System to redact certain areas of all documents of a given document class ("document class" being defined here as a specific document type from a given financial institution; for example, statements from a given brokerage, or cancelled checks from a given bank) or all documents of a given document class meeting certain criteria.
  • document class being defined here as a specific document type from a given financial institution; for example, statements from a given brokerage, or cancelled checks from a given bank
  • all documents of a given document class meeting certain criteria.
  • the System would perform this function as follows (see Fig. 35):
  • the System will supply an interface that enables the user to select, on an image of a representative document from a document class, those areas to redact (by drawing redaction boxes over the desired areas, or by some other means).
  • the System stores the geometric information (position and dimensions) for the redaction boxes.
  • the System uses the stored redaction information file to apply redactions to appropriate areas of the image.
  • This embodiment is similar to the Document-class Redaction embodiment, except that for a given document in a document class to be shared, the System would give the Owner the opportunity to unredact one or more redacted areas, add areas to redact (as in the Manual Redaction embodiment), or both. In this case, the documents have no extractable contextual data associated with them.
  • the System would perform this function as follows (see Fig. 36):
  • the System will supply an interface that enables the user to select, on an image of a representative document from a document class, those areas to redact (by drawing redaction boxes over the desired areas, or by some other means).
  • the System stores the geometric information (position and dimensions) for the redaction boxes.
  • the System's interface enables the Owner to unredact areas that are redacted by default (by clicking on the redacted areas, or by some other means), and to select additional portions of the document to redact (by drawing redaction boxes over the desired areas, or by some other means).
  • the Owner When the Owner is finished making redaction selections, the Owner saves the redacted image. (Alternatively, the Owner could choose to accept the default redactions without making any changes.)
  • the System encrypts and stores information about the redacted areas in a file
  • reaction file stored separately from, but associated with, the image file.
  • the Owner then proceeds to share the document with one or more Contacts.
  • the System notifies that Contact or Contacts that there are new shared documents available.
  • the System uses the information in the redaction file to apply redactions to appropriate areas of the image.
  • the System would allow the Owner to revoke shared documents, which causes the System to discontinue the availability of the document to the Contact.
  • the System would enable the Owner to transfer full ownership rights for a given document to another user.
  • the System would perform this function as follows (see Fig. 37):
  • the System decrypts each document (see “Decryption"), then re-encrypts each document using the new Owner's key (see “Encryption” discussed later below).
  • the System creates a special Account for the new Owner for documents whose ownership has been transferred to the new Owner, in a manner similar to creating an account for an unsupported Source (see “Account Creation for Unsupported Sources” discussed above). In this embodiment, a document must be associated with an Account.
  • the System updates the descriptive metadata associated with the document or documents to indicate the new Owner and new Account.
  • the system notifies the new Owner by email that the previous Owner has transferred ownership of one or more documents to the new Owner.
  • the System notifies the new Owner the next time the new Owner logs into the System.
  • the System would enable the Owner to transfer full ownership rights for all documents in an Account to another user.
  • the System would perform this function as follows:
  • the System provides an interface in which the original Owner can manage Accounts.
  • This interface enables the Owner to select an Account to transfer, and a Contact to whom to transfer the Account.
  • the System creates an Account for the new Owner, and associates this account with the financial institution that the new Owner set up in step 1.
  • the System updates the descriptive metadata associated with the documents to indicate the new Owner and new Account.
  • the system notifies the new Owner by email that the previous Owner has transferred ownership of one or more documents to the new Owner.
  • the System notifies the new Owner the next time the new Owner logs into the System.
  • the disclosed invention collects and/or creates evidence that various users can review to judge whether they believe particular Digital Documents are authentic.
  • the Digital Document Authenticity Evidence process works as follows:
  • the System either collects a Digital Document from a Source or in an alternative embodiment a Digital Document is uploaded or sent by a Source into the System.
  • the System performs a hash function on that Digital Document after it has been encrypted. For more information about encryption, see “Encryption” discussed below.
  • the System associates and stores the following with a particular Digital Document: (a) Its hash result; its Source's name; and (c) its Acquisition Date. [0637] 3. Before serving the document up to a user, the System runs a hash function on that particular Digital Document.
  • the System serves the requested Digital Document up to the user for viewing with an indication that that Digital Document's integrity has been verified. If the Digital Document was altered, the System notifies the Contact with an error message indicating that the Document was altered. [0640] 6. The System also presents to the user that Digital Document's Source's name and the Acquisition Date.
  • the System presents the metadata used for Authenticity
  • Evidence only to users who have directly or indirectly paid an additional fee.
  • the user could directly pay an additional fee per document access, or an annual fee to cover all document accesses; or, the user could have the per-document-access fee paid by the Owner.
  • Encrypted document image files are stored on a secure central file server, with a file name that does not reveal any information about the document (such as the Owner, the document type, financial institution, and so on). If there is contextual data associated with a document image file but located in a separate file, the encrypted contextual data file is also stored on the secure central file server. The location of each file (image and contextual data) is stored in the metadata database as part of the metadata for that document. In an alternative embodiment, an Owner's encrypted document image files would be stored on that Owner's local computer.
  • the metadata for all documents is stored in a database on a secure central server.
  • the document image file, contextual data (if any), associated metadata, and authenticity evidence information could be stored together in a single file, of a proprietary file type that can be read and written only by the System.
  • the disclosed System's storage and encryption architecture is designed to protect the security of users' stored financial institution credentials, documents, and the information contained within those documents.
  • the System stores encrypted documents and users' keys in separate partitions in the data storage server. (In another embodiment, the documents and keys could be stored on separate physical machines.)
  • the System Master Key which is used to encrypt and decrypt users' keys, is stored in encrypted form in a peripheral media device, such as a USB flash memory drive or memory card. An operator who is starting up the Application Server (which handles encryption and decryption of documents, among other tasks) must decrypt the System Master Key and load it into the Application Server's memory.
  • the peripheral media device is the only nonvolatile storage device upon which any form of the System Master Key resides, and the System Master Key is changed on a regular schedule.
  • All communications between the user's Web browser and the Application Server are conducted over a secure (SSL) connection.
  • SSL secure
  • All System servers are protected by a secure firewall.
  • the system network architecture including all routers and switches, is designed to prevent unauthorized access to the System. System access is logged and the logs can be analyzed for suspicious activity.
  • a separate server would handle the encryption and decryption tasks, and the Application Server would take incoming requests and serve decrypted documents to users. Every encryption and decryption transaction is logged. The logs can be analyzed for suspicious behavior.
  • the System runs the hash function on the document. After the encrypted document is stored, a background process periodically decrypts it, loads the decrypted document into the System's memory, runs the hash function on the decrypted document, and compares the hash result with the hash result that was calculated at acquisition. This process verifies that the document has not inadvertently been altered due to data loss or data corruption.
  • the System runs the hash function on the document after it is encrypted. In this case, a background process can periodically confirm that the document has not inadvertently been altered due to data loss or corruption without needing to decrypt the document each time.
  • the application server receives a request over a secure connection from the user's web browser to view an encrypted document.
  • the document identification is encoded in the request URL and would have been generated by a previous operation and presented to the user on a web page.
  • the application server locates the user's account information using session data provided by the browser and using the database, the application server retrieves the location of the document referenced in the request URL. The application server can now access the user's document in the file store but it is still in an encrypted state.
  • the document must be decrypted using the user's personal encryption key that was generated when they first registered with the service.
  • This key is stored in the key store database, encrypted using the System master key.
  • the key store database would be further encrypted by a database encryption scheme.
  • the application server now securely connects to the key store database and asks the database to decrypt and return the user's personal encryption key.
  • the application server receives the key from the database it is still encrypted and must be further decrypted using the System master key.
  • the application server can decrypt the document file and securely pass it back to the user's browser for further viewing and manipulation. The application server then discards the user's decrypted key and logs the transaction for auditing purposes.
  • Persistent Control of Rights to a Shared Document the System would enable to Owner, or a System administrator, to grant and revoke other sharing rights including, without limitation, the abilities to:
  • the System would enable the Owner, or a System administrator, to grant certain rights for pre-specified time periods. For example, a Contact may be able to view a document for one month but would be able to print it out for only one day. The Owner would be able to modify the time periods to either revoke certain rights or to extend certain rights.
  • the System By integrating with other programs, the System would be able to automatically collect or pass on the following with respect to one or more documents: Authenticity Evidence, Integrity Evidence, Contextual Data, Administrative Metadata, Structural Metadata, and/or Descriptive Metadata. Furthermore, the system would empower the Owner to control which users of such other programs would get access to a particular Digital Document or Acquired File. The system could also empower the Owner to determine which users can access which information related to a particular document. [0673] The System's integration would include: 1) a secure means of communicating; 2) a way to pass data, the Acquired File, Administrative data, and/or Digital Documents from the system to a particular software program.
  • the System's integration would include the use of one or more common libraries or definitions for: 1) Contextual Data, 2) Administrative Metadata, 3) Structural Metadata, 4) Descriptive Metadata, 5) Integrity Evidence, and/or 6) Authenticity Evidence.
  • the System can be integrated with other hardware, networks, and software implemented processes that provide: [0675] 1. Tax preparation a. By consumer b. By professional preparer [0676] 2. Accounting a. Budgeting, Cash Flow Tracking i. Consumer ii. Business b. Expense reports or Project costs estimates [0677] 3. Investing a. Tracking Net Worth b. Asset allocation c. Rate of return comparison d. Cost basis tracking e. Expense tracking f. Volatility analysis g. Correlation analysis h. Monte Carlo Analysis
  • USB Token ii. Identity card iii. Out-of-band communication to or from a second device (such as a mobile phone)

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Health & Medical Sciences (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • General Engineering & Computer Science (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Human Resources & Organizations (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Library & Information Science (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • General Business, Economics & Management (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Computational Linguistics (AREA)
  • Medical Informatics (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Storage Device Security (AREA)

Abstract

L'invention porte sur un système d'acquisition et d'authentification de document comprenant une application sur Internet qui, pour le compte de ses utilisateurs, peut automatiquement : a) collecter des documents numériques ; b) créer des métadonnées descriptives standardisées apparentées à chaque document numérique ; c) utiliser ces métadonnées descriptives pour organiser, trier et filtrer les documents numériques collectés ; d) collecter et créer une preuve que des utilisateurs tiers peuvent utiliser pour déterminer l'authenticité de documents numériques particuliers ; et e) protéger la confidentialité des utilisateurs pendant la collecte, le stockage et le partage des documents numériques. L'application sur Internet fournit aux utilisateurs des fonctionnalités comprenant une gestion d'utilisateur, une gestion de source, une acquisition de document automatique et manuelle et une gestion et un partage de document. Le système peut recevoir des documents numériques que des utilisateurs téléversent manuellement dans celui-ci et il permet à des utilisateurs d'entrer manuellement des métadonnées descriptives standardisées. Le système peut ensuite automatiquement gérer les autres fonctions pour les documents numériques.
PCT/US2008/011006 2007-09-21 2008-09-22 Système d'acquisition et d'authentification de document WO2009042113A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CA2700222A CA2700222A1 (fr) 2007-09-21 2008-09-22 Systeme d'acquisition et d'authentification de document

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US99476707P 2007-09-21 2007-09-21
US60/994,767 2007-09-21
US938807P 2007-12-28 2007-12-28
US61/009,388 2007-12-28

Publications (2)

Publication Number Publication Date
WO2009042113A2 true WO2009042113A2 (fr) 2009-04-02
WO2009042113A3 WO2009042113A3 (fr) 2010-08-05

Family

ID=40210474

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2008/011006 WO2009042113A2 (fr) 2007-09-21 2008-09-22 Système d'acquisition et d'authentification de document

Country Status (2)

Country Link
CA (1) CA2700222A1 (fr)
WO (1) WO2009042113A2 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011008355A1 (fr) * 2009-06-11 2011-01-20 Iron Mountain Incoporated Extraction intelligente de biens numériques
CN110059236A (zh) * 2019-03-27 2019-07-26 国网福建省电力有限公司泉州供电公司 一种应用网络爬虫技术进行电力规划收资的数据采集、处理方法
CN110764931A (zh) * 2019-10-22 2020-02-07 携程计算机技术（上海）有限公司 Ota网站上传凭证的处理方法、系统、设备和存储介质
CN113271591A (zh) * 2021-05-25 2021-08-17 广州瀚信通信科技股份有限公司 基于5g切片网络的二标四实数据加密交互方法及装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010039546A1 (en) * 2000-05-05 2001-11-08 Moore Michael R. System and method for obtaining and storing information for deferred browsing
US20020124177A1 (en) * 2001-01-17 2002-09-05 Harper Travis Kelly Methods for encrypting and decrypting electronically stored medical records and other digital documents for secure storage, retrieval and sharing of such documents
US6507351B1 (en) * 1998-12-09 2003-01-14 Donald Brinton Bixler System for managing personal and group networked information
US20050071736A1 (en) * 2003-09-26 2005-03-31 Fuji Xerox Co., Ltd. Comprehensive and intuitive media collection and management tool

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6507351B1 (en) * 1998-12-09 2003-01-14 Donald Brinton Bixler System for managing personal and group networked information
US20010039546A1 (en) * 2000-05-05 2001-11-08 Moore Michael R. System and method for obtaining and storing information for deferred browsing
US20020124177A1 (en) * 2001-01-17 2002-09-05 Harper Travis Kelly Methods for encrypting and decrypting electronically stored medical records and other digital documents for secure storage, retrieval and sharing of such documents
US20050071736A1 (en) * 2003-09-26 2005-03-31 Fuji Xerox Co., Ltd. Comprehensive and intuitive media collection and management tool

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011008355A1 (fr) * 2009-06-11 2011-01-20 Iron Mountain Incoporated Extraction intelligente de biens numériques
US8166038B2 (en) 2009-06-11 2012-04-24 Kaufman Mark A Intelligent retrieval of digital assets
CN110059236A (zh) * 2019-03-27 2019-07-26 国网福建省电力有限公司泉州供电公司 一种应用网络爬虫技术进行电力规划收资的数据采集、处理方法
CN110059236B (zh) * 2019-03-27 2023-05-05 国网福建省电力有限公司泉州供电公司 一种应用网络爬虫技术进行电力规划收资的数据采集、处理方法
CN110764931A (zh) * 2019-10-22 2020-02-07 携程计算机技术（上海）有限公司 Ota网站上传凭证的处理方法、系统、设备和存储介质
CN110764931B (zh) * 2019-10-22 2024-03-26 携程计算机技术（上海）有限公司 Ota网站上传凭证的处理方法、系统、设备和存储介质
CN113271591A (zh) * 2021-05-25 2021-08-17 广州瀚信通信科技股份有限公司 基于5g切片网络的二标四实数据加密交互方法及装置

Also Published As

Publication number Publication date
WO2009042113A3 (fr) 2010-08-05
CA2700222A1 (fr) 2009-04-02

Similar Documents

Publication Publication Date Title
US20090150169A1 (en) Document acquisition and authentication system
US6289460B1 (en) Document management system
US8676683B1 (en) Business transaction facilitation system
US20050033669A1 (en) Philanthropy management system and methods of use and doing business
DE60132495T2 (de) Ein Informationsverwaltungssystem
US20090282006A1 (en) Transaction Management
US7315978B2 (en) System and method for remote collection of data
US20110276493A1 (en) Methods and apparatus for a financial document clearinghouse and secure delivery network
US20020161733A1 (en) Method of creating electronic prosecution experience for patent applicant
US20020116363A1 (en) Method of deleting unnecessary information from a database
US20020111824A1 (en) Method of defining workflow rules for managing intellectual property
US7313540B1 (en) Electronic communication system and method for facilitating financial transaction bidding and reporting processes
US20080005024A1 (en) Document authentication system
Cascarino Auditor's Guide to IT Auditing,+ Software Demo
WO2002027628A2 (fr) Systemes et procedes destines a un organiseur universel personnel integre permettant de planifier un heritage et de stocker des donnees correspondantes
Cascarino Auditor's guide to information systems auditing
WO2013150041A1 (fr) Système informatique et procédé de gestion d'identité en ligne
US20050038683A1 (en) System and method of international patent application
US20120278251A1 (en) System and method for compliant integrated paperless workflow
KR100494975B1 (ko) 스크린 스크래핑 기술을 이용한 고객 자산 관리 방법 및시스템
WO2009042113A2 (fr) Système d'acquisition et d'authentification de document
US11799869B1 (en) Systems and methods to store and manage entity verification information to reduce redundant entity information and redundant submission of requests
US7467107B1 (en) Web-based system and method for hedge fund compliance
Securosis Understanding and Selecting Data Masking Solutions: Creating Secure and Useful Data
NZ544269A (en) Improved philanthropy management system and method of doing business

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08834151

Country of ref document: EP

Kind code of ref document: A2

WWE Wipo information: entry into national phase

Ref document number: 2700222

Country of ref document: CA

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08834151

Country of ref document: EP

Kind code of ref document: A2