JP2019521537A - System and method for securely storing user information in a user profile - Google Patents

Abstract

A method for storing a first data object includes, on a client device, a first data object, a first fragment associated with a first original record locator, and a second associated with a second original record locator. The first original record locator is obfuscated on the client device to generate a first obfuscated record locator, and the second original record locator is obfuscated on the second Generating the obfuscated record locator, encrypting the first fragment using the first encryption key and encrypting the second fragment using the second encryption key on the client device And, at least in the first plurality of storage locations, a first encrypted fragment and a corresponding first obfuscated record locator, and a second encrypted fragment and And storing the second obfuscated record locator. [Selection] Figure 2

Description

  The various embodiments described herein relate generally to the field of electronic management of information, and more particularly to secure storage and protection of user information in user profiles. Furthermore, the various embodiments described herein relate generally to the field of electronic data security, and in particular, secure storage, management of data, and data at client endpoints and in transit, authentication information and encryption. It relates to the transmission of keys.

  As more and more communications, services and transactions are done digitally through networks such as the Internet, the vision of a paperless modern society is quickly becoming reality. Paper copies of letters, financial instruments, receipts, contracts and other legal documents are diminishing as the electronic methods of securely transmitting, updating and accessing these documents increase. In addition to electronic transmission and access of documents and letters, the process of electronic submission of information is also common, such as online shopping or loans, credit cards, medical insurance applications, university or job applications etc. It is getting worse.

  However, much of the information needed for these forms is common to other forms, and the user manually repeats the process of capturing form input with the same information over and over again. The possibility of collecting, organizing, updating, using and reapplying the input information required in these electronic documents, forms and applications remains very difficult. Several applications have been developed to store certain basic information about the user, such as the user's name, address and financial information, but organize, access and apply this stored information to added online activities The ability remains very limited, particularly when detailed input information and / or calculations are required to complete the form, such as university applications and family legal filings.

  There are several programs or applications that allow the user to follow financial information, budgets, forecasts, account payment accounts etc. While these tools can save time and provide effective tools such as budgeting, they can be used in a specific format or by a specific form such as personal information, financial information, forecasting, classified spending Do not address many situations where users are required to provide etc.

  For example, when someone gets divorced, they have to provide the court with detailed personal and financial information both in the past and in need of it. This information must be provided in a very specific state-ordered format using a particular form, which must be updated and submitted to courts at various times during the divorce process, which may be long over time It may continue. For example, Figure 1 shows one page of income and expense declarations in a California divorce case, which both the petitioner and the defendant must complete. The amount and complexity of the information required for such forms usually requires an individual, such as a divorced person or a lawyer, to complete the form, and obtaining all the required information, and Even performing the calculation of the information to obtain the desired price takes a considerable amount of time. In another example, when a user desires a loan, such as a car loan or a mortgage, the organization offering the loan often asks the user to provide and update specific financial records and information organized in a specific format .

  Even those who are well organized and financially savvy using currently available personal finance software tools find that completing and updating these forms can be cumbersome, time consuming, confusing and error prone. Applicable forms and other applicable items require more than basic financial information. Also, because forms can have a significant impact on whether applicants are eligible for financial assistance, loans, etc. or to receive desirable outcomes in divorce or other legal proceedings, these forms should There is an important need to complete exactly.

  These same difficulties also apply to other important life events such as college applications and / or college payments. The university application process is a very worrying time for students, and often their parents. There is a great deal of detailed information needed to complete university applications and economic aid applications, including but not limited to papers, transcripts, letters of recommendation, activities, photographs, etc. Also, university application and economic assistance opportunities have many different deadlines. It is very difficult to organize and keep track of all information, deadlines and filed applications.

  Furthermore, the security of electronic data is of paramount importance to individuals and nearly every conceivable entity and governmental agency. Numerous amounts of electronic data are generated, stored and transmitted on a fixed basis. Also, the scope of electronic data today inevitably attracts bothersome people, to personal information and information to be carefully handled.

  Conventional data security solutions are relatively static. For example, one or more data security mechanisms (eg, password protection, encryption settings) may be located at specific data storage locations. The same data security mechanism may remain in place until a significant security breach is detected, at which point the entire data store may have been tampered with.

  Data stored based on standard relational data models are particularly vulnerable to unauthorized access. Individual data records (eg, name, address, social security number, credit card number and bank account number) stored in separate storage locations indicate logical relationships between data records (eg, associated with the same user) ) Usually accompanied by a shared record locator. For example, individual data records may be associated with the same user identification number. As such, unauthorized access to any one of the data records may expose sufficient information (i.e., a user identification number) to access the remainder of the data record.

  Although numerous data security methods are available, the flexible roster of uninterrupted integrated and complementary data security solutions in a single data storage location continues to be very difficult. For example, although the combination of security solutions usually increases data security, nonconformities between different solutions may actually create additional security risks.

  Also, in order for users to be able to store and retrieve data, there must be a way to identify the users and protect their data from access by other users. Conventionally, this is performed by "front end" software, and the user is authenticated and authorized through login.

  The conventional login process is associated with a number of reported shortcomings. For example, in many systems, the login step is generally regarded as part of the user interface (UI) and is an entity separate from the security bubble. The problem is magnified in cases where in-house developers with limited security knowledge attempt to create a custom login authentication and authorization system. As such, once a malicious user successfully completes the login process, that user can potentially have access to other users' data.

  However, these problems are further compounded by the fact that much of the data generated today is generated or accessed at client endpoints, such as computers, laptops, smartphones, tablets, Internet of Things devices, etc. Even though the aforementioned problems can be solved for storing and retrieving data at the server, there is a further problem of protecting data at the endpoint. Thus, any solution to the above problem should take into account the fact that the client's endpoint must also be protected.

Key exchange method For establishing a reliable communication link between two devices and encrypting / decrypting transmitted data, such as passing a symmetric shared secret key or a public / private asymmetric key in current use There are many forms of key exchange methodology. Symmetric encryption uses the same key for both data encryption and decryption through multiple algorithms such as AES, Blowfish, DES, and Skipjack, and is usually faster than asymmetric encryption. It is often used when high volume data encryption and high data throughput are required. In contrast, asymmetric encryption uses a pair of public and private keys, where the public key is usually used to encrypt data, and the private key is used to decrypt data. Asymmetric key algorithms can be 1000 times slower than symmetric key algorithms, and thus, more generally, for key management or initial device authentication without the continuous exchange of key pairs that would require huge resource capacity. Applied.

Encrypted Data Transmission In a general scenario where large objects need to be encrypted and sent to multiple client destinations, and each client should have a uniquely encrypted copy. The conventional approach is to encrypt the original object with different keys for each client. If there are N clients and it multiplies the encryption of each object by the amount of time T, then the total encryption time is N × T.

Data Encryption Rate Currently, there are several approaches to increase performance (the rate at which data can be encrypted). One approach is to use hardware based acceleration. The 128-bit and 256-bit AES ciphers can be accelerated 4 to 8 times (if available on Intel and AMD processors) through AES-NI hardware encryption. It is also possible to reduce the size of the key at the expense of security. AES with 256-bit keys is about 40% slower than AES with 128-bit keys. Another strategy is to use another encryption algorithm such as Blowfish, which allows for 20% speed improvement.

Encryption Key Management Encryption keys are typically used for data encryption or other key encryption, and other keys are then used for data encryption, the latter generally being the key encryption key. It is known as (KEK). Managing keys and who has access to keys can be a formidable task. Key management software (KMS) attempts to make this task easier by providing user and management access to all of the keys needed. KMS may also provide backup and redundancy services that protect copies of keys in the event of catastrophic server failure. Since no access to the encrypted data is possible except when the KMS is always operating, the uptime of the user is maintained when the replacement KMS is quickly turned around.

Compound Security Keys The concept of compound keys is widely known and used in many scenarios. For example, Alice and Bob's compound key for unlocking a file provides them the ability to unlock the file, but only if both of them unlock it at the same time. Neither Bob nor Alice can unlock the file independently. These composite keys are usually static, but must be rewritten by the administrator when changes are required.

Data Access Restrictions When it is necessary to restrict access to data, the commonly used approach is to configure access at the user level, and / or groups of users with different roles and permissions, each assigned To establish. This ensures that user A does not have access to, for example, user B's data. Another approach commonly used for databases is to develop database query statements for any number of limitations before enabling access to data. The problem with all these solutions is that they do not provide a simple way to have fine control at the data item level, and these limitations themselves are not widely encrypted.

Hacking hackers spend an average of 200 days in the system before they are discovered. While inside, they observe the traffic and make various attempts to identify additional authentication information, usernames, passwords, etc. Access logs and behavioral analysis are several ways in which the detection effort is focused. Also, "honeypot" files, databases, or servers are strategically placed in an attempt to slow hackers.

Ransomware Ransomware is software that is secretly installed on a computer that runs an encryption algorithm that applies to all files that appear to the computer, including those on networked drives and cloud folders. The objective is to make the affected file unusable until the victim pays the ransom, and a decryption key is provided at the time of payment. Some products attempt to quickly identify the signature of an attack based on features such as ransomware software or the appearance of a file with an extension known to be generated by multiple file renaming activities. Another approach involves click blocking software that prevents the user from clicking on the email attachment (the largest source of attack). Finally, there are many malware solutions that monitor abnormal process execution that may be an infected signature.

  The most effective solution to protect against ransomware is to back up all files, and regularly check that you have a few days worth of backups. There are various products that perform backups on an automatic schedule. However, many backup systems use an installed drive for backup. If ransomware can view the file, it can view all the drives including the file used for backup. There are several ways to protect your backup drive, such as setting up proper access credentials and protocols. Ransomware is continually developing and adapting, and many of these solutions have eliminated the position of the offender.

Retrieving Encrypted Data There are a number of approaches to retrieving encrypted data, such as homomorphic encryption, which allows for the pre-indexing or evaluation of search fields and thus the retrieval of encrypted data. The biggest difficulty is to keep the search process slow, or to bring about security flaws, and maintain performance within all accessible limitations and methods. In any case, these methods vary widely in practice and rarely follow the standard. These custom implementations make it difficult to use third party search tools.

Data Encryption Data is conventionally encrypted while in any number of states. For example, the entire hard drive may be encrypted for stationary data. In another example, active data may be encrypted as it travels through a secure https connection. Data in the database may be encrypted using a method that preserves the original table format while the data in the individual fields are encrypted in place. Other special scenarios include encryption of a single desktop folder or installed disk drive.

  In all these cases, the data to be encrypted is not organized in the format and is very different from their original footprint. The encrypted data is transferred to the storage device using the same data and file hierarchy as the original data, if it simply replaces the original data at the predetermined position or is replicated to another medium. In cases such as data sharding and erasure coding algorithms, other techniques exist to reorganize data storage formats. They distribute the original data, which may also be encrypted. However, the distribution and storage format follows the rigid protocol imposed by the basic algorithm, thereby making it difficult to add higher level functionality and integration with existing legacy formats and / or third party solutions Do.

  Disclosed herein are systems and methods for securely storing user information in a user profile that prevents access to the information and minimizes the amount of information disclosed during a security breach. . Information pertaining to the user is obtained from one or more sources through electronic means, and then the information is classified into specific categories using field mapping and other techniques, which are then organized into user profiles, in a database Stored safely. The information collected and organized includes identification and contact information, financial information, health information, education and occupation information, family information, business information, lifestyle information, and historical information about any of the listed categories. May be (but not limited to). The user profile may be encrypted and stored remotely in a cloud-based system at a remote server, and portions of the profile may be separately encrypted and stored in separate locations, unauthorized access to portions of information You may minimize the risk of The fields of data in the user profile are also individually encrypted with separate encryption keys and stored separately in separate data stores, databases, or separate database tables, a single encryption key or a single encryption key The amount of information that may be exposed by unauthorized access to a database or database table may be minimized.

  In one aspect of the invention, a system for securely storing user information from a user profile comprises a profile creation unit for creating a user profile of user information comprising a plurality of fields and a plurality of values for a plurality of fields, The information in the profile is separated into partitions, which are stored separately in separate data stores, databases or database tables.

  In another aspect of the present invention, a method of securely storing user information from a user profile comprises: creating a user profile of user information including a plurality of fields and a plurality of values for the plurality of fields; The step of separating the information of (1) into separate partitions, and the step of storing the separated partitions in separate data stores, databases or database tables.

  Also disclosed herein is a system and method for secure storage, transmission and management of disclosed data, authentication information and encryption keys, including from client endpoints and client endpoints. is there. According to one aspect, a first data object storage system relates a secure platform comprising a plurality of storage locations, one or more processors, and a first data object to a first true record locator The first original record locator and the second original fragment associated with the second original record locator, obfuscating the first original record locator to generate a first obfuscated record locator, Obfuscate the two original record locators to generate a second obfuscated record locator, encrypt the first fragment using the first encryption key, and generate the second obfuscated record locator using the second encryption key Encrypting the two fragments, in at least a first plurality of storage locations, the first encrypted fragments and corresponding first obfuscated record locators, and a second encryption Comprising a client device comprising one or more processors configured to store the fragments and the second obfuscated record locator.

  Other features and advantages will be apparent from the following description of the preferred embodiments in conjunction with the accompanying drawings.

  Various embodiments disclosed herein are described in detail with reference to the figures described below. The figures are provided for the purpose of illustration only and merely show typical or exemplary embodiments. These figures are provided to facilitate the reader's understanding and should not be considered limiting the breadth, scope, or applicability of the embodiments. It should be noted that these figures are not necessarily drawn to scale for the sake of clarity and ease of explanation.

It is an image of the income and expense declaration form used in the divorce procedure. FIG. 1 is a block diagram illustrating a system for acquiring, classifying and capturing personal information on an electronic form, in accordance with various aspects of the present disclosure. FIG. 5 further illustrates a system for acquiring, classifying and capturing personal information on an electronic form, according to various aspects in accordance with various aspects of the present disclosure. 6 is an illustration of operations involved in field capture of a document, in accordance with various aspects of the present disclosure. 5 is a screen shot of a graphical user interface illustrating a browser extension implementing the system of the present invention, in accordance with various aspects of the present disclosure. 7 is an image of a database table listing field identification numbers, field names and field values, in accordance with various aspects of the present disclosure. 7 is an image of a database table of forms stored in an autocomplete system, according to various aspects of the present disclosure. 7 is an image of a database table that lists field names and field values on each form document stored in the system, in accordance with various aspects of the present disclosure. 7 is a screen shot of a graphical user interface illustrating a web interface for selecting a category of documents to pre-populate user information in accordance with various aspects of the present disclosure. 5 is a screen shot of a graphical user interface showing a web interface for selecting a particular document to pre-populate user information in accordance with various aspects of the present disclosure. FIG. 10 illustrates a graphical user interface of a form with unique field names that can be automatically identified and stored in a system database, in accordance with various aspects of the present disclosure. FIG. 10C shows a graphical user interface of the form of FIG. 10A with unique field values stored in a system database captured in fields, in accordance with various aspects of the present disclosure. FIG. 10B is an image of a database table storing field identifiers, field names and field values for unique fields in the forms shown in FIGS. 10A and 10B, according to various aspects of the present disclosure. 5 is a flowchart illustrating a method of obtaining, classifying and capturing personal information on an electronic form, in accordance with various aspects of the present disclosure. FIG. 16 is a block diagram illustrating an embodiment of a computer / server system on which embodiments in accordance with various aspects of the present disclosure may be implemented. No. 14 / 863,294, copy of FIG. 1, the disclosure of which is incorporated herein by reference in its entirety. No. 14 / 970,466, copy of FIG. 1, the disclosure of which is incorporated herein by reference in its entirety. No. 62 / 281,097, the disclosure of which is incorporated herein by reference in its entirety. Figure 5 is a reproduction of Figure 4 of US Provisional Application No. 62 / 281,097. 7 is a flow chart illustrating a key exchange method in accordance with various aspects of the present disclosure. FIG. 7 is a sequence diagram illustrating an encrypted data transmission sequence in accordance with various aspects of the present disclosure. 7 is a flowchart illustrating a method of pre-slicing data to speed up encryption in accordance with various aspects of the present disclosure. 7 is a flowchart illustrating a method of rejoining data files, according to various aspects of the present disclosure. 7 is a flow chart illustrating a method of managing encryption keys in accordance with various aspects of the present disclosure. 7 is a flowchart illustrating a method of evaluating a composite key, in accordance with various aspects of the present disclosure. 7 is a flowchart illustrating a method of restricting data access in accordance with various aspects of the present disclosure. 7 is a flow chart illustrating a method of detecting and responding to a hacking attack in accordance with various aspects of the present disclosure. 7 is a flowchart illustrating a method of detecting and responding to a ransomware attack, in accordance with various aspects of the present disclosure. 7 is a flowchart illustrating a method of enabling search on encrypted data in accordance with various aspects of the present disclosure. FIG. 7 is a flow chart illustrating a method of using a virtual decryption container storing encrypted data in accordance with various aspects of the present disclosure.

  The various embodiments described above are further elaborated in connection with the foregoing figures of the illustrative embodiments and the following detailed description of the illustrative embodiments.

  The embodiments described herein may be an online shopping account form, a loan, a credit card, a medical insurance, a university or job application, a government mandated document required for legal proceedings (such as divorce or bankruptcy) And provide the collection, organization and use of information to automatically complete, update and submit complex electronic documents and online forms such as, and the business and business owners or forms required by them. Information is obtained from multiple different sources, classified through field mapping and other information classification techniques, to form an organized database of information related to users known as information security zones. The information is securely stored in one or more user data stores or databases by encryption and separation techniques to ensure the security of the information. A form database is used to store electronic forms and documents, as well as field information needed to complete the forms or documents. The user automatically populates the fields of the online form or electronic document with the user's information by selecting the document from the forms database or by using a browser plug-in that captures the online form displayed in the web browser As accessible. The system also integrates with third party services and websites to allow users to keep information in a highly secure database while capturing information at the third party site via a secure connection to the user database It may be

  When the user's database forms a user profile including, for example, identification information, financial information, health information, contact information and past user information that ensure that the form is classified with high accuracy and the form is taken with the correct information The techniques described herein provide the ability to quickly, accurately complete, update and transmit any type of foam on any type of computing device. The user maintains full control of any download, transmission, editing or deletion of the user's information and only needs to enter and confirm the user's information once, rather than repeating the same process over and over again.

  The systems and methods described herein may be used by individuals, groups, associations, governments, or entities for various types of information gathering, management and input. An individual user may import an online form on the user's desktop, tablet, smartphone, etc., and can immediately complete the form. In one embodiment, the system may be provided as a mobile application running on a smartphone, tablet or other portable electronic device, which will allow the user to complete forms or other documents . The ability to easily capture information with portable electronic devices is particularly advantageous in the difficulty of entering information using small display screens and touch screen devices. An entity may organize and store information for completing forms such as human resource forms, construction permit forms, elevator license forms, etc. in various jurisdictions. The examples provided herein primarily relate to the use of systems and methods for individual users, but the benefits and applications extend to groups, associations, governments or entities of users of any size and type.

  Once the user enters the information, it is stored within the user's secure area, and the user then uses it forever to supply information or complete any form that requires the repetition of the same information As possible, this solution is unique. Non-limiting examples are: new patient forms for health care, university admissions, scholarship applications, financial aid applications, loan applications, medical questionnaires, job applications, insurance forms, legal declarations or procedure documents, government Includes benefits or service requests, personal health records, e-commerce account forms, membership applications and more.

  FIG. 2 illustrates one embodiment of a system 100 for acquiring, classifying and capturing information on an electronic form, according to one embodiment of the present invention. Information is obtained from one or more information sources 102a-102c, such as an existing form 102a, a third party application interface 102b, or a manual user input 102c. The information is then transmitted to the communication interface 104 and then classified by the server 106 and stored in one or more data stores, locations or system data stores 108 as user profiles of the user's information. The communication interface 104 may be in a local area network (LAN) with the information source 102 or may be remote from the information source 102 through a connection via the Internet or other wide area network (WAN) It is possible. The communication interface 104 also classifies information identifying fields and fields applicable to the information, a classification unit 106a, a profile creation unit 106b for creating a user profile with the classified information, and at least one form field. It has one or more information processing units within the server 106 that process the collected information, including an information capture unit 106c that captures at least one form field or database of the electronic form by matching the received information. It may further comprise a field comparison unit 106d and a user activity collecting unit 106e 104, the functions of which will be described further below. Depending on the overall system design, any of the aforementioned units 104 can be located in separate servers or in a single server. The user can then request to complete one or more forms 112 using information in the user's profile through any type of device 110a-110c. The user can use any type of device, including laptop computer 110a, desktop computer 110b, or portable electronic device 110c such as a tablet or smartphone.

  The user completes the one or more forms 112a-112c, such as the image viewer 112a, the form 112b displayed on the Internet browser application, or the form 110c displayed by the application 112c executing on the portable electronic device 110c. It can interact with the communication interface 104 through 110. The form may also be directly in a browser window via the HTML 5-CSS 3 or application 112 c interfacing with the server 106, or through one or more graphical user interfaces (GUIs) 114 generated by the server 106 and displayed on the device 110 c. It is possible to display. As shown herein, forms can be captured directly on the user's device via browser extensions, add-on browser applications, or application programming interfaces (APIs) that interact with third party services or applications.

  FIG. 3 is an illustration of a system flow diagram that illustrates the security protocol of one configuration of the system. A user 116 can access the system through the various devices 110 described above, which are connected to the communication interface 104 by the Internet 118. Multiple types, locations, devices, servers, etc. can be used separately between the various firewalls to enhance protection of user profile information to ensure privacy and security. It is possible to display to the user a GUI showing basic information which is initially regarded as the public facing home site 104a of the communication interface 104, which is also protected by the initial firewall 120a. The first firewall 120a can provide system-wide security and allows access to the user interface and experience level (UI / UX) 104b of the interface. The UI / UX 104b includes a web and interface server 106f connected with the form and application output data store 108a. The second firewall 120b can protect a third partition of the communication interface known as the data access layer 104c. The data access layer 104c may have a business model logic application server 106g connected to a data store server 106h, and the business model logic application server 106g may be mapped to a secure client data element and historical archive data store 108b. It can be configured to manage the input form data store 108c. A separate ID and authentication server 106i can also be included in the data access layer 104c, with server 106i connected to the identity data store server 106j and server 106j able to manage the secure client identity element data store 108d It is.

  4 accesses field 402 of form 404 by accessing information stored in secure client identity element data store 108d and secure client data element data store 108b through data store management software such as information capture unit 106c. One embodiment of the capturing step is shown, wherein separate client identity data stores and client information data stores are used to obtain the information needed to populate the electronic form.

  Details of systems and methods are further provided herein in connection with specific components and functions.

I. Information and Form Collection Information can be obtained from multiple different sources and multiple different formats to obtain a complete set of user information. For example, by completing with the user a "master form" specifically designed to collect the information that many forms need in different categories (ie loan applications, online shopping, university applications, divorce proceedings, etc.) , User information can be obtained. User information can also be from existing electronic records or non-electronic records such as financial institution databases, electronic health records, third party information aggregation services (such as Mint.com®), or the user is a web based user of the system Collectable by following simple instructions in the interface. Users can use these existing electronics so that relevant information can be obtained and the system can use specific application programming interfaces (APIs) to communicate with third party sites to obtain field and content information. It may be necessary to grant access to one or more of the records. For existing electronic records, it is fully conceivable that the information has already been classified, for example in a database, by specific field names or identifications, so that virtually no additional information classification is required. However, due to the complexity of many forms, such as divorce settlements and financial schedules, the system is able to repeat additional calculations and reorganize the classification to match the required output of the form. For non-electronic records, users may be able to scan or photograph non-electronic documents and have fields and field values extracted through various techniques such as image processing and content extraction software.

  In one embodiment, information can be obtained when a user manually completes an electronic form or document. For example, as shown in FIG. 5, when the user completes the form 112b displayed on the Internet browser application, the application will form 112b in the user's database for future use with the same or other forms. It is possible to have a browser extension 502 that allows capturing, extracting, organizing, classifying and updating fields 504 and field contents 506. The browser extension 502 can provide a pop-up menu 508 and a copy button 510 for copying fields into the user profile, as well as a field input button 512 for capturing data from the user profile into the form 112b. Information can also be extracted and captured for the purpose of completing forms across multiple pages. Blank forms and documents and other user information can also be uploaded directly to the system, where forms or documents and their fields can be captured, mapped and stored as templates. For example, credit card application forms may be uploaded to the system and stored in the document library data store with identified form fields, thereby allowing them to be stored in the data store, either manually or using automatic mapping techniques. It can be mapped to the corresponding user field.

  Completed forms and documents can also be uploaded directly to the system where they can capture and extract forms or documents, fields and field contents. For example, a credit card statement or mortgage statement can be uploaded to the system, and the fields and field contents can be extracted and stored in the user's data store, but not because the document itself is not a form is there. However, if a credit card application or mortgage application has been uploaded, the document itself may be extracted and stored in addition to the fields and content to assist users and other users in filling out the form in the future .

  FIG. 6 illustrates one embodiment of data store table 602 and field information collected from forms entered into the system. Information is stored in this table when the information is sent from the form running on the server. The information comes from this table when applied to the form "pulled out" from the server. The form can be a form as shown in FIG. 1 and can be completed by the user such that the form field already has the entered value. As shown in FIG. 6, each field 604 on the form is provided with a unique numeric identifier 606 (customerFieldDefaults_Id) to distinguish it from the other fields. As shown in the right two columns, each field is further given a predetermined field name 608 (fieldName) and a field value 610 (fieldValue). The field name may be the form's own encrypted name, or if it is on the website or on an electronic form with field name metadata that has already identified the field name based on the programmer who generated the original form, It can be extracted from the form. Field values (if available) clearly correspond to the contents of the field. The association between field names (known as name-value pairs) and field values is important for content classification and formation of user profiles.

  FIG. 7 shows a document library table 702, which stores a list of documents 704 stored in the system. For each of the documents, a document identification 706 (documen_id), a document title 708, and a path 710 to the document in the associated database are provided. FIG. 8 shows a database table 802, which stores field names 804 (fieldName) of each document in the document library table of FIG. Note that there is an option to set default values for each field. For example, this year's tax form may have a 2013 default entry. The commonFieldName 806 is a human readable version of the fieldName 804 in the case where the fieldName is unclear or not well named by the original form designer. commonFieldName 806 allows the system to quickly match that field to the field names found in common customer storage locations. The commonFieldName 806 provides more reliable deterministic field mappings and field names found in the user profile.

  Unique field names and values are stored and organized in the system for future use. FIGS. 10A and 10B are an illustration of an online form 1002 having a unique billing code field 1004 in the "billing" section 1006, where the code field should be a unique 33 digit code. If the user has not pre-entered the code into the system (which is unlikely given the unique code for the particular form), the user completes the form 1002 for the first time, as shown in FIG. 10B. It is necessary to manually enter field value 1008 in field 1004 when doing so. As shown in the table of FIG. 11, the system pulls the information on field 1004 (and the value 1008 entered by the user in that field) into the system and lists them in database table 1100. As shown in FIG. 11, there are two inputs generated for this field, one corresponding to the field name 1102 (number) and one corresponding to the field value 1104 (number of 33 digits). In one embodiment, additional line inputs (not shown) are generated to associate radio buttons next to fields with fields and field values. This is useful as the system recognizes that the radio button is activated / selected when entering field values when the form is captured in the future.

  In another embodiment, third party services and websites may provide information about the forms and documents provided on their site for storage in the system, such as field names and other documents or form identification information. It is. Thus, if the user is using a third party service and needs to complete a form or document of the third party service, the user will incorporate it into the form or document at the third party site, so from the user data store to the third party service It can be requested to obtain the user's information. Third party services can then hold their customized forms or documents on their website or application, and the third party services provide field information to the system, so the user is captured in the forms or documents. You can ensure that the content exactly corresponds to the content that each field needs. Also, because the information is stored in the system's data store rather than in the third party service's data store, the user is provided with additional security for the information, reducing the opportunity for the information to be stolen from the third party service or site. .

  In another embodiment, third party services may be used within their website or application so that information stored within the application or at a third party server may be shared and used with the system to complete forms and other documents. It is possible to integrate the realized system. Similarly, integration provides the sharing of user information with third party sites or applications to complete forms or documents at third party sites.

  Other sources of information may be used or envisioned, as would be apparent to one skilled in the art. Collecting user information from various sources and compiling that information into an organized list of information that can be used to capture any type of field or supplemental information on any form, as described further below. An information source is thereby used to form the respective user profile.

II. Organization and storage of information The information obtained from the various sources of information mentioned above is used to form the user profile of the individual's user, which is ideally for the user's financial position, contact information, health information and history information Have comprehensive information. User profiles include user's name, date of birth, age, current and past address, phone number, email address, social security or government identification number, employment information (current and history), income, height, weight, race It can include bank account numbers, balances, usernames, passwords, educational information, health risks, allergies, medications, etc. This list is by no means comprehensive. User profiles may also include information not directly related to the user, such as emergency contact names and phone numbers, family name and relationships, service provider contact information and notes, work contact information, business prospects, CRM etc. It is possible to have. The user profile may also store other metadata selected for that information, or stored date.

  Access to the system can be provided by the application interface through software executing on a computing device such as a desktop or laptop or through an application executing on a portable electronic device such as a tablet or smartphone. Also, the system is accessible through a web-based application interface, where all user information is securely stored, for example, in a secure server facility in a cloud-based network.

  In one embodiment, in order to enhance security by minimizing the risk of hacking to one of the data store locations, within the location of at least two or three separate data stores intentionally separated. Can store information. The data store may be, for example, a document library data store that stores forms and document templates, field information and other form characteristics, for example customer personal storage location data that stores information including fields and field values for each particular user. A store, eg a user identification data store storing user identification information (separate from other information for security reasons) and information about customer orders, and a completed form storing previously completed forms for fields and values that were once completed It can be divided into data stores of different documents.

  As described immediately above, it is possible that the information may be classified into different categories so that the information is accurately captured or captured in the appropriate fields of the form. As discussed further below, the potential risk of stealing rich personal information is mitigated by specialized, proprietary encryption and storage techniques that prevent the information from being stolen and that it is useful even if it is stolen .

Field Mapping Identifying which information belongs to which field in a form is one of the most difficult aspects of populating the form. Although many information fields contain names that easily and immediately identify the values belonging to that particular field, some names are misleadingly named and some fields have slightly different names between different forms Some fields have the same name in the same document, and some fields have multiple values associated with the same field.

  There are at least three main situations in which information is to be entered, operating the subsequent field mapping technique. In the first situation, the document library stores standard document templates, which can be copied into the user's workspace and entered on demand. In this case, the document library will store the document's fillable fields and possible default values in the "Fields" table. In the second situation, fields and their unique values are applied and mapped to blank documents. This unique set of user information, over time, becomes a large repository of information. In the third situation, the actual fields and values assigned to the document are entered and stored by the user so that the values are fixed to the completed document. Several techniques to solve these problems are described below.

  The first solution involves examining the fields of the document and associating and estimating the "best fit" field names. In one embodiment, this is completed by the use of the "for" attribute of the website field code that associates the form label with the field box on the page. For example, the field box with an ambiguous name "box00455x" may be encrypted with "labelfor =" firstname "so that confusing names and fields can be associated with the label for" First Name ".

  For situations where there are multiple fields in the document or form with identical or similar field names, it is possible to use the fields of the document in which each field appears to see if the value of each field should be different. Thus, the system data store can store the "field section" input as a category in the data store for each field so that fields with the same name can be clarified based on which column they are in It is.

  In some cases, field names are completely random and show nothing as to how they map to other fields or specific field values. Field names may be encoded for computer and other systems that read a particular code with a specialized number or letter key code. For example, the "First Name" field may be named "fn0045586". For PDF documents stored in the document library, an additional "helper" attribute called "commonFieldName" can be added to the field record. When the document is entered, it is possible to manually convert the poorly named fields into something that is easily mapped. In this "First Name" example, the system can record FieldName records as "fn0045586" and "commonFieldName" as "First Name". When the user selects this document, the latest technology recognizes "commonFieldName" and easily maps it to one of the user's field names that most closely matches "First Name".

  System can be configured to provide a user selectable drop down menu or other selection method which value to enter into a particular field in situations where the user has multiple values associated with the same field name It is. In another embodiment, the fields are populated with the most recently used or most frequently used values.

  In another embodiment, different forms can have different ways of referring to the same user field name. Documents can name fields in one way, while other documents can name the same fields in other ways. For example, the first document may have a field named "First Name" while the second document may have a field named "fname", and the third document may It has fields named "firstname", which all refer to the same field and should have the same value or content. To enable this association, the "userFieldCollections" record is provided in the user's FieldDefaults table in the system data store, which lists the various field names that are synonymous.

  For example, there are a plurality of fields stored in data stores each having the same value over time. For example, suppose that these three "firstname" fields all have the value "Arthur". The background process performed by the field comparison unit 106d of FIG. 2 periodically examines the data store for other fields with a value of "Arthur" and identifies those fields as duplicates in the "userFieldCollections" table. Is possible. This table captures various field names of synonym based on their common content. When any one of these fields encounters a subsequent form, the appropriate value "Arthur" is used.

  In the second approach, the system can preset the "userFieldCollections" table with generally grouped field values. For example, when a field called "firstname" is first encountered, "firstname" and "FirstName" are stored in the table. When a subsequent field called "FirstName" is encountered, its value will already be stored and will be easily located through the "userFieldCollections" table.

  In one example, when there are commonly labeled field names, such as the field name labeled "myFirstName" and other fields (likely other forms) labeled "customerFirstName" , A problem arises. Since these field names clearly correspond to the same information (user's first name), in order to map "myFirstName" to "customerFirstName", the existing fields mapped from other users are learned, and then the user's Machine learning classified documents can be applied to assign recommended mappings between fields and document fields.

Separation of Identification Information In order to protect the user's information from the possibility of theft and misuse, the system separates the user's identifiable information from other information of the user. For example, the user's name, social security number, date of birth, employer identification etc. are stored in a data store separate from the user's other information such as the user's credit card number, bank account, education, rating etc. . The identifiable information also allows any logical connection to other identifiable information of the same user so that each identification field is effectively stored in its own secure area within the data store It is stored without accompanying. Each item of user information is further individually encrypted, and then the other information without indexing, organizing or categorizing the table such that the table can not itself provide any useful information about the user Can be stored anonymously in the table.

  The separation of each of the information in such a way that the encrypted information can only be decrypted with the key, and optionally in some cases the key can not be misused to unlock the other item Are generated separately for each item The key is stored in a separate data store and can only be obtained when the user logs in with the correct password. Thus, by separating the information making up the identity of the user, it is possible to determine the user's information sufficient to achieve the identity theft simply by accessing the database and the tables listed therein. It is impossible. As one example, the user's Social Security Number (SSN), stored by itself and separated from other information (such as the user's name), is not useful for lasting the stealing of identification information. Given that the SSN is further encrypted to an unrecognized series of letters and numbers, the system provides two highly secure methods of protecting the information stored in the data store. In one embodiment, three separate data store locations are used to obtain information, each location can be connected to the network using a different server, and the servers can be behind different firewalls It is possible. The first data store is configurable to store the user's username and password. If the username and password are successfully entered, a secret key is generated which is then provided to a second location, which is simply used by each user to store the secret key. In order for the third location to hold the actual information and to retrieve it through the encrypted mapping to reassociate the secure area of information, the lock must be released with the secret key from the second location.

Automatic User Profile Update This type of separation, i.e. dividing the data into multiple pieces as described above, occurs in each piece of information as well. In other words, each strip of information can be split into substrips, each individually encrypted with a unique key, and / or a separate location without logical connection to other substrips. Stored in In one embodiment, the system can be configured to automatically classify and store any input information in the user profile without specific instructions from the user. Also, as user information continues to be acquired during the user's normal activity, the newly entered information acts to update existing information, or the same information fields that the user can select when subsequently populating in a form Added to the list of values.

  The user's information can be stored in its own data store location known as the personal information security zone, and in a table called "customerFieldDefaults" of that location. The customerFieldDefaults table usually holds the latest information of the user.

Obtaining User Information In one embodiment, existing user profile data can be analyzed to obtain additional relevant information. Additional relevant information can be obtained by performing comparisons or calculations of existing data, such as analyzing financial data to determine budgets for consolidation and normal spending. Also, additional relevant information can be obtained from external sources to provide the user with a more complete image of a particular aspect of the user profile. For example, if the user enters a list of assets including the vehicle age, format and model into the user's user profile, the system can obtain the estimated value of the vehicle from an external data store or third party service. In another example, when the user enters the title of a collectable work of art, the system can obtain additional information of the work of art such as artist, year of creation and estimated value. This information can be used to fill out an insurance application for the item or a bill in case of loss.

Analysis of User Information In one embodiment, the user activity collection unit 106e of FIG. 2 monitors user activity during system use (such as information entry, form filling, etc.) and is predetermined based on user activity and information. Store the generated explanatory code in the location of the generated, collected and separated data store. The code may correspond to the user's current life status, demographic profile, preferences, financial balance, and other parameters associated with the user's account, but collect and disclose the user's specific information Or do not leak. These codes can then be used to determine marketing and other strategies targeted for the user to market and service third-party products, which is the user's need for those products or services. And aim better and better at your wishes. The code can also provide a confidence value on the likelihood that the code will adapt to the user, based on factors related to the type of form, use of other related forms, etc.

  For example, a user completing a university application may generate a code regarding the likelihood that the user is going to enter university, which then provides an opportunity to market the university-related products or services to the user. As the user completes the university application and the financial assistance application, the confidence value for the code indicating that the user is about to enter university may jump higher. This can be used to display to the user in the graphical user interface advertisements targeted to the user's living status, such as university advertisements.

Archive Storage of Captured Information Each time the user populates the form with information, the system can store a reference to the final version of the form in a table of specific data store locations known as customerFieldContent. In particular, forms are not stored in a single data store location throughout. Instead, a reference to a form or a record locator is stored. The information stored in the form can be locked, and other user information is updated, except when the user specifically accesses the completed form to edit the form itself and generate a new version. Is not updated when The completed form stored can be stamped with time and date so as to generate a completed archive of the user's activities in the system.

Sharing Family Information and Group Plan / Corporate Plan Information In one embodiment, the user's information can be shared with other related groups that may wish to share part of the user's profile. For example, spouses, children, parents, siblings and sisters and other family members share similar information that is more widely updated when one of the items is changed, such as address, phone number, family history, etc. It is possible. This provides convenience by avoiding repeated input of information among members of the family, enables comprehensive updating of the information to be shared, and members of the family are like FAFSA (federal aid free application). Make it possible to work together by The FAFSA application has certain fields that the student completes and other fields that the parents need to complete. Another example is that a child applying to a university can access shared family information that other siblings have already entered into their siblings 'user profiles, such as address, parents' names, occupation, etc. In addition, if the family moves away, the home address updated by one of the family members will be updated or provided to other family members in the same group that also have the same home address previously listed. Ru. Similarly, various employees of a company can work together to complete a company's organization or other entries or reports. In another example, a database of health records for one generation of a family can be transferred to a second generation to provide information on potential genetic health information for the second generation.

  Information from each family / company member can be stored in a separate secure area of the database to enable family or company sharing options, and each member can maintain the privacy of their separate information As such, the database will form a link between shared information between family / corporate members.

III. Populating Electronic Forms Selecting a Stored Form When the user is ready to complete a form or document, the user can select one of several methods. If the form or document is stored in a form database at the system server, the user may select document category 902 or a particular category, as shown in the attached graphical user interface of web-based application interface 900 of FIGS. 9A and 9B. A form can be selected from the list of documents 904. The user can also search the form using a search tool or browse through the categories 902 and find the form based on the type of form (financial, academic, health care, etc.).

Application Extension As shown in the attached illustration of the browser extension drop-down menu graphical user interface of FIG. 5, in one embodiment an application extension for quick access to capture a form being viewed in an application window Department is provided. The extension can be displayed in an icon, menu item, completion or application menu or some other alternative, and when the icon is selected, there is an option to bring the information from the user profile into the field displayed in the application window A window opens. The application may be an internet browser, word processor, image viewer, spreadsheet or presentation software, but these examples and all examples and embodiments herein are not limited thereto.

  As described above in Section I, in another embodiment, the application extension may also be used to extract or supplement information from the form, document or web page displayed in the application window. With this extracted information, the user's personal information database may be uploaded.

  In another embodiment, the application extension may also store user-stored contacts while viewing a third party website such as a LinkedIn®, Facebook® or Zillow® website. , And can be used to display and modify contact related information regarding form fields recognized by the CRM and / or the system. In one example of this embodiment, while viewing one of their LinkedIn® contacts to the user, the information is exchanged with the other users of LinkedIn® or LinkedIn®. Pop-up or drop-down windows are shown that allow you to view, modify or directly add unique and private information about special contacts back into their personal user database without necessarily sharing. Basically, the user augments the LinkedIn information in the user's personal notes on the contacts and securely stores the information in his information database for personal use. In another example, to a user who is deemed to run a real estate business, Zillow. A pop-up or drop-down window is shown while viewing a specific list of com®, which allows them to view, modify, or modify unique and private information about that particular property. Allow to add directly to. This allows real estate business users to gather valuable business information (eg display of specific real estate listings, list of details, list of clients where the schedule is displayed), which makes them more effective in their own business Make it possible to

Third-Party Application Integration Third-party service providers can also include access to the system within their own applications, such as web-based applications or mobile applications running on portable electronic devices. For example, a website run by an educational institution will have a system for applying for admission so that when loading the admission application, the user can log in and then access their information and retrieve the admission application directly through the website. It is possible to integrate access to these applications. Also, the Internet shopping website uses a button, link or authentication dialog for the user to select and then retrieve their information on the payment screen when the user is ready to check out and purchase goods or services from the website It is possible to integrate access to system databases as possible.

  Integration with third-party applications means that third-party service providers can not view or store user information and instead simply request it from the system database at checkout when the transaction is complete and then delete it Additional security can be provided to the user.

  Applications can be delivered as stand-alone products or web-based products and services. In one embodiment, the application can be provided as a portable document format (PDF) fill application, and the application is operative to capture information into the PDF document. The PDF entry can be a web based application or can be integrated as a browser extension as described above. The application can also be provided as a web-based form fill designed to complete forms and documents found online. The system can also be provided as a mobile application that runs on a smartphone, tablet or other portable electronic device that will allow the user to complete forms or other documents. The ability to easily capture information with portable electronic devices is particularly advantageous for the difficulty of entering information using small display screens and touch screen devices. For example, users who use their mobile devices to shop often find it difficult to enter all of their contact and payment information on a small screen (in addition to need to remember it) ). The ability to quickly complete these e-commerce form fields is particularly advantageous for mobile users. In another example, a user coming to a First Aid or First Aid room may need to fill out some forms, instead providing a website to access the forms, and using the system of the present invention to form fields It is possible to capture and submit forms online. Mobile based applications can be stand-alone or integrated into other mobile applications or native device applications. For example, in one embodiment, a portable electronic device's camera allows the user to take a picture of a blank form or document and use the system to capture form fields before sending the completed document. It can be integrated with

  In another embodiment, the third party application is configured to provide partial or complete transfer of user profile data from the system to a third party user profile without the need for the user to view the form in fields in the third party user profile. Integrate with system and user profiles. For example, users who participate in third party services, such as social media services or e-commerce services, simply request to transfer their user profile generated on the system to third party applications and corresponding servers and databases , You may be asked to complete the user profile. The user may only need to select the option of transferring all their user profile information to the third party user profile immediately, without having to look at the web-based forms corresponding to the user profile. Immediate transfer allows the third party application to send a list of field names to the server, and the server then accesses the database table to identify the value stored in the user profile or the value corresponding to the matching field name. It can be completed. The matching field values are then transferred back to the third party application server and database to complete the third party user profile.

  Additional transfer methods can be provided to automatically transfer selected user profile information to other forms, databases, devices or destinations, where the user can transfer form fields and content to where they are filled in or elsewhere When done, you won't have to review it manually.

Form Completion Indicators In one embodiment, the user can be provided with a form completion indicator, which indicates how many forms can be filled out from the information in the user profile. The form completion indicator can be displayed alongside the list of user selectable forms, so that the user can determine which form is the easiest to populate based on the form completion indicator. The indicator may be a symbol, a color or just a numerical value indicating the percentage of the field of the form to be filled in from the information stored in the user profile. The form completion indicator is updated in real time and helps the user to select a form database or online web form that is the easiest to retrieve automatically and has almost no manual input. The completion indicator may also provide the user with an indication of how many of the predefined categories have been mapped or how much work is required to complete an unfilled field.

Manual Input Interface The system captures every field that has information about it, but some fields may have no value or have multiple values, in which case the fields are not filled in automatically. In this situation, the user has to take some action to populate the field. One embodiment of capturing form fields can be assisted by voice, touch, gesture or input device, or any combination of the three. Voice and touch input eliminate the need for any manual typing of any information entered into the form. Voice input is available through the microphone on the computing device, while touch and gesture input is possible through the touch screen, touch pad, image capture device or motion capture device. The input device includes a mouse, a stylus or other peripheral device connected with a computing device that allows selection on the graphical user interface.

  In one embodiment, manual entry of values into the field can be completed by displaying a separate window, such as a pop-up or drop-down menu, with the user having a choice of values to select on the speech, touch or input device It is. The interaction can include one or more separate input types, such as touching a field on the touch screen to create a window and then uttering the name of the desired value from the list of field values . The form entry field can also display a window with hints or notes associated with the system database to assist the user in completing the form. In one embodiment, a touch input on the field initiates an audio input while a "touch and hold" input initiates the display of a separate window with multiple available values.

  Manual whenever the value of a field is missing in the user profile, or even when the system is designed to select the most suitable value from multiple available values based on one or more criteria The need for input arises. If the value does not exist, or to override the automatically filled in value, the user can be provided with an option to manually enter the value in certain fields. For example, users may have in their user profile, as if the form field labeled "food allergy" is too special for the system to determine which value of the listed allergy should be entered automatically. Several different allergies (ie eggs, bees and cats) can be listed. The system can use data from previous user input by other users to determine that "egg" is the most likely candidate. However, the user is then offered the option to select the field to generate the separated window, and then, for example, if the user is allergic to food made with honey, by adding "bees" or "honey" to the list Choose from a list of allergies, to correct the selection. If the user does not have field values stored for the field name "allergy", select a category and provide a list of choices in one or more drill down menus or just speak the desired value The voice recognition software can then prompt the user to manually enter field values with a physical keyboard or touch screen keyboard interface by interpreting voice commands and having the user enter appropriate values. The user also speaks a partial keyword for the form field, which then displays a separate window with available values including the partial keyword. A search algorithm can be provided to associate keywords with available related values.

  As mentioned above, one application of touch and voice input would be the ability to touch a particular form field and then speak the value to be entered into the field. Alternatively, if the system can not identify the field name, the user can first speak the field's name, which causes the system to populate the value for the field name spoken from the user profile. If there is no field value for the field name, the user can then also speak the value for the field. If the entered value is a new value, the system stores the value in the user's profile for future use. In one example, a user filling out a car insurance claim and having to enter a vehicle identification number (VIN) touches the field box labeled "VIN" and then "VIN number" or similar instruction The system database then populates the field with the stored VIN number. In another embodiment, the selection of the value captured in one field can also capture the value in the associated field. For example, during the e-commerce accounting phase, the online merchant prompts the user to enter a credit card by displaying a field with such a name. Users touch the field on their mobile touch device, speak the word "Chase Visa", and the user's Chase Visa card number, name on that card, card expiration date and card security code (CSV) are all accounted Fill in the relevant fields on the form. The advantage of the user is that it is not necessary to store any personal credit card numbers in every online merchant, yet it is possible to experience a quick and secure shopping account. Also, when a user's credit card is expired, exchanged or renewed, the card changes are all securely stored in one place in the system database, so the user only needs to update their vendor sites to update them. You do not have to remember to visit.

  In another embodiment, if the field has multiple available values, the user can touch or speak the field name and then touch, speak or one of the list of values displayed in the drop down menu etc. It is selectable by mouse input. Similarly, if multiple fields have the same name but in different fields of the form, the user can speak the field name and then the field name to select a value for the particular field desired. Additional features include the ability to touch or speak form fields and then search for values using keywords.

  In addition to gestures, touch and voice input, manual input of field values is also possible through certain types of movement in devices comprised of gyroscopes or accelerometers capable of detecting directional movement and velocity. In one embodiment, the user can shake the device (such as a smartphone or a tablet) to cause the user interface to find or capture a particular field. For example, the user can shake the device to capture a blank form, more specific gestures such as vertical tilt, find specific field names, windows, and (credit card field names and It provides the user with several choices of field values to populate within field names (such as a list of different credit cards selectable for electronic transactions).

  In another embodiment, if the entire form or one or more fields within the form were not completely mapped and / or stored in the system, then the user may touch or touch each unmapped field name It is possible to associate this form field with a database field by speaking and then touching or uttering categories, subcategories, and specific category database fields. The system also uses machine intelligence algorithms to collect multiple user mappings of form fields and associate them with database fields, and then store the associated field mappings with the forms in the form database, thereby all users of the system It is possible to provide a correctly mapped new form to use. This embodiment allows system users to add and map new forms that are not currently in the system independently, for the benefit of all system users. It also maps web form fields to database category fields for web forms that have not yet been mapped (associated) in the system by the system user, for the benefit of all system users. Make it possible.

Storing Modifications In one embodiment, if the user manually changes the field value for a particular field after the system has populated the field, the system indicates the changed value and the newly entered value is the system database, preferably, Stores in the information safe zone of the user profile. Thus, users can automatically update their profile while information is entered into the form.

Methods and Applications Although several applications of the system and method have been described above, application of the system and method should not be considered as limited thereto. The systems and methods may be particularly applied to the completion of complex forms and documents having various form fields, requiring a significant amount of information, or having similar or misleading names and field identifiers. University applications, loan applications, income and expense declarations for family legal issues, health care forms and many forms required by small business owners and by them are by use of the exemplary system described herein. It is an application that can result in considerable improvements in time savings and information accuracy (reducing frustration or reducing redundancy, of course).

  One embodiment of a method of obtaining, classifying and capturing electronic forms is illustrated in the flow chart of FIG. In a first step 202, information is obtained from one or more information sources, such as existing forms, third party APIs, and the like. The information is then classified at step 204 to determine at least one field to which the information belongs and to associate that information with the at least one field. Thereafter, at step 206, the plurality of associated information is collected into a user profile and securely stored in one or more databases. At step 208, when the user requests to complete the form through one of the client interfaces, the information in the user profile is matched with the form fields on the form and the information is captured on the form. At step 210, if the user manually enters values into any of the form fields, and these values differ from the user's information currently stored in their secure database, then these new values will be the user's secure database It is stored inside. The user profile can optionally be updated to reflect the new value as the default or primary value of the field.

IV. Computer-Implemented Embodiments FIG. 13 is a block diagram that illustrates an embodiment of a computer / server system 1300 in which the methodology of the present invention may be implemented. As known to those skilled in the art, system 1300 includes a computer / server platform 1301 that includes a processor 1302 and a memory 1303 that operate to execute instructions. The term "computer-readable storage medium" as used herein refers to any tangible medium, such as a disk or semiconductor memory, involved in providing the processor 1302 instructions for execution. Computer platform 1301 also receives input from a plurality of input devices 1304, such as a keyboard, a mouse, a touch device, or verbal instructions. The computer platform 1301 may also be connected to a removable storage device 1305, such as a portable hard drive, optical media (CD or DVD), disk media or any other tangible media readable by computer executable code It is possible. The computer platform may further connect to network resources 1306 that connect to the Internet or other components of a local, public or private network. Network resources 1306 can provide instructions and information to the computer platform from remote locations on network 1307. The connection to the network resource 1306 can be by a wireless protocol such as 802.11 standard, Bluetooth or cellular protocol, or by a physical transmission medium such as cable or fiber optics. The network resources may have storage for storing information and executable instructions at a location separate from the computer platform 1301. The computer interacts with display 1308 to output information to the user, as well as request additional instructions and input from the user. Thus, the display 1308 can function as an input device 1304 that interacts with the user.

V. Additional Features The specific embodiments disclosed herein provide methods and systems that provide secure storage and management of data, authentication information and encryption keys, including, among other things, client endpoint protection. After reading this description, it will be clear how the described embodiments are carried out in various alternative implementations. Furthermore, although various embodiments are described herein, it is understood that these embodiments are shown by way of example only and not limitation. As such, this detailed description of various alternative embodiments should not be construed as limiting the scope of the appended claims.

  The disclosure of co-pending U.S. Patent Application Serial No. 14 / 863,294 (the '294 application) is incorporated herein by reference in its entirety. The '294 application, as described therein, describes secure high-speed data storage, access, recovery and transmission systems and methods including data fragmentation, discrete encryption and distribution. For example, as described in the '294 application, data in medical records can first be separated, for example so that the various fields are not logically related. The separated fields can then be broken down into sub-fields or parts (fragments). It is possible to obfuscate these sub-fields so that they can not easily determine their contents even if they are going to intercept or access the contents of the sub-fields thereafter. These sub-fields can then be individually encrypted, for example using different encryption keys for each sub-field or fragment. The individually encrypted sub-fields can then be "fragmented" and stored in different storage devices or locations.

  FIG. 14 is a copy of FIG. 1 of the '294 application, showing an example system in which the described process can be performed. However, as described with reference to FIG. 14, in response to instructions or requests initiated on the client device or endpoint 110, the process typically occurs on the secure platform 120. The secure platform 120 then stores the encrypted fragments in various storage devices or locations 140-170. Although the location 140 can be local or locally connected to the device 140, the process described in the '294 application does not necessarily handle the link from the endpoint 110 to the platform 120.

  The disclosure of co-pending U.S. Patent Application Serial No. 14 / 970,466 (the '466 application) described in its entirety by reference and illustrated a diffracted data recovery system and method through the process of the' 294 application. As incorporated herein. FIG. 15 is a copy of FIG. 1 of the '466 application, showing a system for performing the diffracted data recovery described therein. As described with reference to FIG. 15, the diffracted data recovery may include a local or storage device or location 140 locally connected to endpoint 110, but the process described therein is Typically, no link is applied between endpoint 110 and servers 120 and 180.

  The disclosure of U.S. Provisional Patent Application Serial No. 62 / 281,097 ('097 application) (now expired) is incorporated herein by reference in its entirety. The '097 application describes a secure storage and management system and method of authentication information and encryption keys. FIG. 16 is a copy of FIG. 1 of the '097 application, showing a system in which the process described therein can be performed. As described with reference to FIG. 16, secure storage and management of authentication information and encryption keys may include a storage device or location 140 locally or locally connected to the endpoint 110, but The process described therein typically does not apply a link between endpoint 110 and servers 120 and 180.

  With the systems and methods described herein, the processes described in the '294,' 466 and '097 applications as shown in FIGS. 14-16 are performed at the tip, ie, the endpoint 110 of the client. It is possible. For example, as described in the attached, data can be stored and retrieved locally or in different parts of the locally connected storage device 140, or data can be saved and stored in a plurality of storage devices 140 to 170. As such, an application can be loaded into device 110. Thus, when a user of device 110 creates a document, video, photo, etc., the user can invoke an application to store the document or file. This is a distributed way of storing all the steps described above or in the appendices, storing them in different places in the storage device 140 or in different places on the memory 140-170 as described above and for example in the '294 application. May include the execution of Similarly, the application can perform diffractive retrieval of data or files as described in the '466 application, and can enhance management of authentication information and encryption keys as described in the' 097 application.

  Thus, when data is stored on multiple storage devices, the transmission of that data to those devices is also protected by the fact that the process separates and encrypts all fragments before transmission for storage . In other words, all data elements are fragmented and protected in the device before they are sent. The main advantage of this is that a regular "open" connection can be used without the need to protect the communication channel. For example, instead of using slow and expensive TLS protected browser transmission, a faster unencrypted channel may be used. Data packets contain protected fragments. This applies to all types of transmission, not just browser-based, and can be wireless, FTP, Bluetooth, etc.

  When a user is in a document or file on their device 110 as shown in FIGS. 14-16, the application, the associated application or web browser, so that they can simply press a button, icon etc. It can be displayed as a toolbar in a toolbar or a button in a drop-down menu, and can store a document. Documents or files may then be shown on device 110 in a manner that indicates that they have been stored using the processes described above and in the '294,' 466 and / or '097 applications. When the user accesses the document or file again, the retrieval process described above and in the '294 application, the' 466 application and / or the '097 application can be performed automatically. In one embodiment, the user can also select various distribution preferences as to where all or some of the fragments are stored.

  In another embodiment, for example, a right click on a file can be used to select the described storage process. In yet another embodiment, the application can automatically determine that the file should be stored using such a process. In yet other embodiments, defaults can be set for all files, specific files, specific types of files, etc., to use such processes.

  Oftentimes, the user of the device 110 shown in FIGS. 14-16 will eventually complete some form of remote storage, often referred to as cloud storage, to store at least some of the files generated on the device 110. I want to use it. The application (s) running on the server (s) associated with such cloud storage services may be for example the '294 application,' 466 in a manner similar to that described in the '294 application. It is configurable to carry out the process described in the application and / or the '097 application. However, as mentioned above, the link between the device 110 and such a server will not necessarily be secure. However, as described herein, it is possible to first locally execute the processes described prior to transferring data to the cloud or intermediate endpoint. Before finalizing it, for example, in the cloud, there may be many intermediate "endpoints". A single client to the cloud is just one topology. For example, to secure data prior to transmission, there may be a network of nodes that all communicate with each other using the systems and methods each described. Fragments can then be distributed and stored on the cloud service. Thus, even if the data were blocked during transport, it would not be useful.

  In one embodiment, the application can be configured to execute the described process automatically when the user attempts to store or retrieve data in the cloud storage service. Also, the application can be configured to detect that the document or file is inactive, ie, not interacting with the document or file for a specific amount of time, and then the described process is automatically executed to protect the document. is there. When the user subsequently reconnects to the document or file, an appropriate process can be performed that allows access to the document or file.

  In one embodiment, the described process may be performed locally, for example on a file, and then re-executed when the file is transferred, for example to a cloud and / or an intermediate device.

  In one embodiment, sharing and co-creation of stored documents using the described process may be enabled using, for example, the authentication and credential management process described in the '097 application. Thus, specific individuals can be granted access, which will then be managed, for example, using a secure key generated based on the authentication information assigned to those individuals.

  Another important advantage comes from the process described when the local storage device is a non-secure storage device such as a USB drive. In such cases, even if the data is accessed by a wicked individual or institution, it is possible to ensure that the data is stored on the device using the described process, and the data is not available. Note that in one embodiment, a local application configured to execute a process described at the local level can be on such a local storage device, eg, a USB storage device. It should.

  In one embodiment, the local application is also configurable to provide email attachment protection. Sending attachments by e-mail is dangerous, as the attached document can be intercepted and read by any knowledgeable hacker. The processes described herein can be performed in such a way as to protect such attachments from being read by anyone other than the intended recipient. In general, local applications do not interact with the email traffic or the encryption of the email itself body. Instead, senders of attachments in local applications can execute (and thereby send them to a public cloud server) the process described in the document they intended to attach. The application can then generate an access link to the document link. The access link can then be emailed to the recipient instead of the actual document. Recipients can then click on the access link they received to download and decrypt the original document. This may, of course, require that the recipient also have such a local application that enables the recipient's device to capture the attachments according to the described process.

  In other embodiments, local applications such as those described above can also control and continuously "see" or "play" frames or sections of digital media (documents, books, audio, video, etc.) You can In such an embodiment, the authorized and authenticated subscribers of the device 110 as shown in FIGS. 14-16, or the user, may receive the separation sent to them when the medium is displayed (or executed). It is only possible to take out and see consecutive frames or sections. Also, after the subscriber has progressed to the next frame or section, previously executed frames or sections may be automatically restored or permanently deleted using the described process. Thus, only one minimal amount of digital media can be decoded and assembled for subscriber consumption in any one instance, thereby minimizing infringing or unauthorized consumption. Optionally, this can be extended to also limit the amount of consecutive frames or intervals that are allowed to transmit further through the consumption feedback mechanism back to the transmitting source to the authenticated and authorized subscribers from the transmitting source. is there. Its value is to more safely distribute all types of digital media, from the consumer to the most sensitive data.

  Thus, prior to transmission, such a digital medium is divided into self-contained sections or frames, and then the described process of fragmentation / encryption / distribution of the sections or frames respectively is illustrated in FIGS. Applied prior to transmission to the device 110 at the tip shown in FIG. After retrieval, each section or frame can be sent at one time in a continuous technique that reconstructs the underlying fragments that make up the section or frame.

  As noted in FIG. 4 of the '097 application, what has been reproduced herein as FIG. 17 is wired according to various embodiments that can be used to implement the client device 110 shown in FIGS. 14-16. Or, it is a block diagram which shows the radio | wireless system 550. FIG. Thus, this system 550 will not be described in detail here.

VI. Key Exchange Method When a new device (such as an IoT device) is added to the network, a method is needed to authenticate that device. Various aspects of the present disclosure provide an integrated method of any number of key exchange methods, including an embedded key exchange process of the device to facilitate this operation. This function enables authenticated communication between the devices, for example in the case of data streaming between the two devices. Once communication is established between the two devices, key exchange methods and frequency of exchanges are dynamically changed based on performance requirements and in response to a number of conditions, such as but not limited to data security threat levels. May be The encryption engine may dynamically interoperate or be layered with other key exchange solutions including private / public exchange (eg but not limited to the Diffie-Hellman protocol used in TLS between devices). A higher level of security may be obtained by using secure keys for a given set of data and maximizing the key rotation rate.

  FIG. 18 is a flowchart illustrating a method 1800 of key exchange in accordance with various aspects of the present disclosure. Referring to FIG. 18, at block 1810, each device, eg, the first device and the second device, may establish a shared key based on the current encryption algorithm parameters and the seed. Those skilled in the art will appreciate that more than two devices may be used without departing from the scope of the present disclosure.

  At block 1815, the data set on the first device may be encrypted using the shared key, and at block 1820, the first device may transmit the encrypted data to the second device. At block 1825, the second device may decrypt the data set using the shared key. At block 1830, a rekey criterion may be determined indicating whether the key should be regenerated. At block 1835, rekeying criteria may be evaluated for each data set. At block 1840, it may be determined whether the rekey criteria are met. In response to the determination (1840-N) that the rekeying criteria are not met, a situation may be monitored at block 1845 to indicate when the key should be rekeyed until at block 1840 the rekeying criteria are met. In response to the determination (1840-Y) that the re-keying criteria are met, a new encryption algorithm parameter may be generated at block 1850 for the next key, and the method may continue at block 1810. The rekeying criteria may identify available encryption algorithms and specific parameters for the encryption algorithms.

VII. Encrypted Data Transmission According to various aspects of the present disclosure, encrypted data may be transmitted with unique encryption across multiple client destinations simultaneously, including but not limited to streams, file systems and / or clouds. You may The encrypted data may be moved to any number of destinations, such as a stream format decrypted to a video player, or a set of fragments securely stored on a file system or cloud. Items to be encrypted store files (eg, Word documents, photo files, virtual machine files, etc.), key-value pairs (eg, simple strings like JSON, or form data, application settings and preferences) It is possible to have any number of data formats including, but not limited to, other formats suitable to do) and streams (eg, video or data feeds).

  According to various aspects of the present disclosure, each object may be broken into smaller fragments that allow for a reduction in the total transmission time of each object, T, and in some cases more than is conventionally possible. Allows up to 15 times faster transmission time. Object fragments may be encrypted only once, while increasing security by using a unique key for each client. This approach may provide performance benefits even while transmitting encrypted data to multiple client destinations. Each destination may have a unique decryption key to access the data. Multiple secure output streams to multiple destinations may be generated while minimizing hardware resource requirements. Data fragmentation, encryption and transmission between computing devices can achieve low latency and complete data encryption. According to various aspects of the present disclosure, the approach is tailored to help multiple clients maintain unique secret keys among their respective clients and encrypt the manifest differently for each intended client. You may

  FIG. 19 is a sequence diagram illustrating a transmission sequence 1900 of encrypted data in accordance with various aspects of the present disclosure. Referring to FIG. 19, at block 1910, client software executing on the respective client 1902, 1903 communicates with the server 1901 to begin the key exchange process. At block 1915, the server 1901 receives a block of data, eg, one frame of a video stream, an audio sample, etc., from a source that may be a file or data sensor, including but not limited to camera, video, and / or audio sensors. Load At block 1920, the server 1901 decomposes the data to create data fragments. At block 1925, the server generates a manifest of each of the clients 1902, 1903, which includes, among other data, a unique encryption key for each of the data fragments. At block 1930, server 1901 uses key exchange information from each client 1902, 1903 to create a unique secret key for each client 1902, 1903. At block 1935, the server 1901 encrypts the manifest with a unique secret key for each client 1902, 1903.

  At block 1940, the server 1901 sends the encrypted manifest to each of the clients 1902, 1903. Those skilled in the art will appreciate that different data may be sent to each client 1902, 1903 so that different manifests may be generated by server 1901 and sent to each of clients 1902, 1903. At block 1945, the server 1901 encrypts the data fragment and sends the encrypted data fragment to the intended client 1902, 1903. At block 1950, client software executing on the client 1902, 1903 waits to receive the manifest and decrypts the manifest using the unique secret key. At block 1955, each client 1902, 1903 responds to the server 1901 with an acknowledgment of receipt of the manifest. At block 1960, each client 1902, 1903 waits for the encrypted data fragment and decrypts each data fragment using the data contained in the manifest. At block 1965, each client 1902, 1903 sends a secret key seed for the next manifest to the server 1901.

  The sequence of FIG. 19 may be repeated for each block of data read from the client. The data fragments may be received by the client in any order, reordered and processed in the correct order. At all initiations at block 1920, the server may repeat the sequence for the next block of data. For each block of data, the client waits to receive the corresponding manifest. If the server does not receive a manifest reception acknowledgment response from the client, the server holds the next block of data until a response is received or until the timeout interval expires. If the client receives an incomplete or incorrect manifest, it may notify the server to resend the current manifest encrypted with the new secret key. If the client receives an incomplete or incorrect data fragment, it may notify the server to resend the current block of data.

VIII. Data Encryption Speed According to various aspects of the present disclosure, the preprocessor may pre-slice or split large files into smaller pieces prior to the fragmentation and encryption process. A companion post processor may recombine files after decoding and defragmentation. By breaking the data object into smaller fragments and encrypting those individual fragments across multiple processor threads, speed advantage without reducing key size or otherwise compromising security level (For example, 5 times to 15 times) can be obtained. "Slicing", ie breaking large files into smaller pieces before fragmentation and encryption, and recombining them after defragmentation and decryption, can improve performance and is very large Data objects can be processed on devices with limited memory.

  FIG. 20A is a flowchart illustrating a method 2000 of pre-slicing data to speed up encryption in accordance with various aspects of the present disclosure. Referring to FIG. 20A, at block 2010, data slicing criteria may be determined. At block 2015, data objects may be evaluated for slicing based on the determined slicing criteria. At block 2020, it may be determined whether the data object is sliceable. In response to the determination (2020-Y) that the data object is sliceable, at block 2025 the server may split or "slice" the data object into smaller pieces of data, and at block 2030 each data slice It may be encrypted and sent. At block 2035, the server may decompose each data slice into data fragments and may encrypt the data fragments. Data may be separated and distributed for storage at one or more storage locations.

  FIG. 20B is a flowchart illustrating a method 2050 of rejoining data files in accordance with various aspects of the present disclosure. Referring to FIG. 20B, at block 2060, the encrypted data fragment may be decrypted. At block 2065, the decoded data fragments may be defragmented and recombined into data slices. At block 2070, slices may be recombined into data objects.

IX. Management of Encryption Keys In accordance with various aspects of the present disclosure, a system may distribute keys to a key store within a local operating system. In some cases, for example, in the event of a network outage, the device may not be able to access remote users and keys or similar licensing services. The remote service may be used to verify user activation credentials, such as username and password at login. In the case where remote services are not available, the client software may validate the user credentials locally by accessing an encrypted keystore on the local device. The system may capture and manage this local keystore as a backup for resiliency to network outages.

  The system may supply key management (KM) software that includes all predicted states of the function in the field. However, when communication to the key management server is lost, not because the key management server is down, but because the remote device can not connect to it as a result of network outages or some other connection problem. Given the assumption that system client software is running on a laptop or other network capable device such as a computing device and the connection to the key management server is lost, the client software should Continue encryption / decryption. The client software creates a local keystore on the active device as a backup in case the remote key management server is lost. The local key store can be configured to hold the specific key or key encryption key needed by the user, including any additional user authentication information needed. The key store itself may be encrypted and only authorized users may be available.

  FIG. 21 is a flowchart illustrating a method 2100 of managing encryption keys in accordance with various aspects of the present disclosure. Referring to FIG. 21, at block 2110, it may be determined whether a connection to the key management server is possible. In response to the determination (2110-Y) that a connection to the key management server is possible, at block 2115 the client may communicate with the key management server to access the encryption key.

  In response to the determination (2110-N) that a connection to the key management server is not possible, block 2120 may determine whether the client has permission to use the local keystore. In response to the determination (2120-Y) that the client has permission to use the local keystore, the client may access the encryption key from the local keystore. In response to the determination (2120-N) that the client does not have permission to use the local keystore, block 2130 may stop encrypting the data.

X. Compound Security Key In accordance with various aspects of the present disclosure, users and key technologies may assist compound keys using AND / OR Boolean logic. The system extends the notion of compound keys by introducing dynamic expressions to control key access requirements. Compound keys can be formed using several subkeys. For a composite key to be valid, the entire subkey should be all present and positive (Boolean AND), or at least one of the subkey should be present and positive (Boolean OR). There may be any combination of Boolean configurations used to form a valid key.

  According to various aspects of the present disclosure, dynamic expressions may be used to control key access requirements. The key may have any combination of Boolean expressions to limit or control the function of the key. For example, the access representation of the key may be written as (Alice AND (Bob OR Carl)), allowing Alice to unlock the file only if done in concert with either Bob or Carl. The composite key may also include other conditions that are not limited in type, including geolocation, time, and hash checksum, as well as the username. For example, (Alice AND (Bob OR Carl) AND ACCESS TIME IS EQUAL BUSINES SHOURS) may add a restriction of business hours only. Furthermore, the representation of key access may include dynamic conditions, which may change based on external circumstances (eg, but not limited to high threat levels or not). For example, (Alice AND (Bob OR Carl) AND SECURITY LEVEL IS EQUAL (NORMAL OR LOW)) allows access only when the security status is normal or low. These expressions allow high-precision reactive access control to keep data safe automatically, even in rapid situation changes such as during a hacker attack. Those skilled in the art will appreciate that other combinations may be used without departing from the scope of the present disclosure.

  FIG. 22 is a flowchart illustrating a method 2200 of evaluating composite keys in accordance with various aspects of the present disclosure. Referring to FIG. 22, at block 2210, for each data access attempt, an access representation of security keys may be determined. For example, the access representation may include any combination of Boolean representation and / or external context. At block 2215, the access representation of the security key may be evaluated, including any required external context. At block 2220, it may be determined whether the access expression and / or the external context is satisfied.

  At block 2225, in response to a determination that the access expression and / or the external context is not satisfied (2220-N), the security key may be rejected and the data access may be denied. At block 2230, in response to the determination that the access expression and / or the external situation is satisfied (2220-Y), the access key may be approved to grant data access.

XI. Data Access Restrictions According to various aspects of the present disclosure, encrypted data includes user role, compound key, location, access time, length of access time, order of access to other keys, but It may have several non-limiting access restrictions. Alternatively, valid user sessions may restrict access to data when certain conditions are not met. These conditions can be arbitrarily formed and assigned to any data item. For example, if a particular data item is to be accessed by the user only within a particular geographical area and at a particular time, the system allows the user to access this data file if those conditions are not fulfilled. do not do. The system may provide some "pre-prepared" type restrictions for convenience, but may add additional restrictions.

  The system may add access restrictions at the data element level. This approach can maximize flexibility and can have its own set of access restrictions, where each data item, eg a social security number, can differ from other social security numbers . Also, access restrictions can be arbitrary and may be represented as Boolean expressions and represented as metadata. All access restrictions are fragmented, encrypted, segregated and distributed to prevent hackers from finding or changing restrictions.

  FIG. 23 is a flowchart illustrating a data access restriction method 2300 in accordance with various aspects of the present disclosure. Referring to FIG. 23, at block 2310, a data access request may be initiated. At block 2315, access restrictions and / or data access conditions may be determined. The access restrictions / status may include, but is not limited to, the user's role, compound key, location, access time, length of access time, order of access to other keys. At block 2320, access restrictions and / or conditions may be assessed. At block 2325, it may be determined if access restrictions / conditions are met.

  At block 2330, the access to the data may be denied in response to the determination (2235-N) that the access restrictions / conditions are not met. At block 2335, in response to the determination (2235-Y) that the access restriction / condition is satisfied, access to the data may be permitted.

XII. Hacking According to various aspects of the present disclosure, rapid detection techniques assist “honeypot keys” that, when used, trigger specific actions such as, but not limited to, alerts, key rotation, etc. The honeypot key is the exposed key left behind by the hacker and / or the fraudulent software to find out.

  Valid access keys and authentication information are required for the user to properly access protected data in the system. The fast detection algorithm triggers an exception event if an incorrect key is used to access any data. The key may include a "honey pot" key that is left for the hacker to attempt to find and use, as well as a "compulsory key" that is forced and legitimate users enter. Exception events triggered by a fraudulent or incorrect key can be used to automatically rotate the key, shut out the user, and alert security personnel.

  FIG. 24 is a flowchart illustrating a method 2400 of detecting and reacting to a hacking attack in accordance with various aspects of the present disclosure. Referring to FIG. 24, at block 2410, a data access request may be initiated and received by the system. At block 2420, the access key provided with the data access request may be validated. For example, a fast detection algorithm may be applied to the access key. At block 2430, it may be determined whether the access key is valid for the requested data. At block 2440, in response to the determination (2430-Y) that the access key is valid, access to the requested data may be granted.

At block 2450, in response to the determination (2430-N) that the access key is not valid,
Access to requested data may be denied. At block 2460, a reaction protocol may be initiated. For example, the reaction protocol may completely log out the user who initiated the data access request, may only deny access to the requested data item, or may only allow access to a limited set of data You may Alternatively or additionally, the protocol may notify the administrator of the system that attempted to access an invalid access key and / or encryption key rotation and / or system shutdown.

XIII. Ransomware In accordance with various aspects of the present disclosure, anti-lansom encryption protection is used by the system to determine if the system was unexpectedly changed before the data was manipulated, such as creating a backup archive, for example. You may include the "Canary file" to be used. The system assumes that a ransomware attack will occur, and therefore performs a regular backup for recovery. However, damaged files infected with ransomware virus should not be backed up. For companies that use a system that archives users 'hard drives on a network, "Canary Files" are used, which are small files scattered among users' hard drives. If any of these canary files are lost or changed, it is an indication that the drive has been tampered with. Before performing a backup, the system checks the canary file, thereby preventing the backup of the infected drive (and the possibility of overwriting the last successful backup). To recover from the attack it is possible to decrypt the last successful archive and replace the contents of the infected hard drive.

  FIG. 25 is a flowchart illustrating a method 2500 of detecting and responding to ransomware attacks in accordance with various aspects of the present disclosure. Referring to FIG. 25, at block 2510, upon initial access of a disk drive by the system, the system may install one or more canary files. For example, small known files may be scattered into the disk drive. At block 2520, a status check of the disk drive may be performed by verifying whether the canary file is valid. For example, the installed canary file may be compared to the expected number and content of the canary file. A lost or changed canary file may be an indication that a disk drive has been tampered with.

  At block 2530, it may be determined whether the disk drive has been infected with ransomware. For example, the system may determine if any of the canary files have been lost or changed. At block 2540, in response to the determination (2530-N) that the disk drive has not been infected, the contents of the disk drive may be encrypted and backed up to another disk drive.

  At block 2550, in response to determining that the disk drive has become infected (2530-Y), backup of the disk drive may be abandoned. Disc drive backup discourages overwriting the last known good copy of the disc drive contents. At block 2560, an alert may be triggered to notify the administrator of the disk drive infection. At block 2570, the contents of the disk drive may be restored from the previously backed up version.

XIV. Retrieval of Encrypted Data According to various aspects of the present disclosure, an accelerated access record (AAR) for pre-indexing of data is stored separately from the data to be indexed to provide analysis and reports. It may be used by third party software. AAR is an optimized search record that can be integrated into third party search tools that provide advanced analysis and reporting. These search records may be stored separately on another server by the system for security purposes. This second server, which also runs system security software, can have a separate authentication layer that enables third party access and / or third party search tools.

  FIG. 26 is a flowchart illustrating a method 2600 of enabling retrieval of encrypted data in accordance with various aspects of the present disclosure. Referring to FIG. 26, at block 2610, data is stored on a disk in the system. At block 2620, the data may be checked to determine if the data should be searchable. At block 2640, in response to the determination (2630-N) that the data should not be searchable, the system may encrypt and backup the disc content.

  At block 2650, in response to the determination (2630-Y) that the data should be searchable, the system may add an accelerated access record (AAR) to the remote server drive on the system. At block 2660, when data is retrieved, the AAR may be accessed for retrieval of encrypted content.

XV. Data Encryption According to various aspects of the present disclosure, all data encrypted by the system may be stored and organized into a set of user-definable locations called virtual decryption containers (VCCs). . The encrypted data may be distributed across multiple data stores in VCC. These VCCs may range from a single device, such as a USB stick (not limited to it) to multiple data centers, and may have dynamically configurable locations. Unauthorized transfer of these VCCs to other devices can be detected by the system and can initiate several actions, including disabling access and key rotation.

It may be configured such that VCC resides on a single drive, or on multiple drives and formats across multiple data centers. The flexibility of this approach stems from the ability of the system to virtualize storage so that it does not know how or where the application stores encrypted data. The application interacts only with the system for data transmission for encryption and retrieval for decryption of that data. The system may manage the location of one or more storage devices. Some advantages of this approach may include the following.
VCC may reside throughout a single hard drive to facilitate secure transmission to other hard drives. For example, it is possible to put VCC on a USB stick and keep it fully encrypted until such time as the system is used to access that VCC.
VCC may have markers that limit its use in certain circumstances. For example, VCC can be encoded to operate only when placed on a specific drive or hardware MAC address or some signature ID. VCC can be restricted to operate only when accessed from a specific location or at a certain time or day. The system can not encrypt or decrypt data except when these VCC conditions are met.
VCC eliminates the need for the application to recognize what the underlying storage medium is and what the particular API for that medium is. For example, there are a number of cloud data stores like Amazon S3 and MS Azure, all with unique APIs that must be integrated into the application before the Amazon S3 and MS Azure services are available. The system may provide a single API for all those storage options including direct device storage.
• Replication and backup options are facilitated through the use of VCC, and there may be various options. For example, if VCC is stored across a single device, such as a tablet computer, it may be replicated periodically as a backup and stored away from the device. If VCC spans multiple storage locations, the system may be configured to replicate each storage request to parallel VCCs in real time. The underlying data stores (eg, the Amazon S3 cloud) may also have their own backup processes made available, which work seamlessly with the system.

  FIG. 27 is a flowchart illustrating a method 2700 of using a virtual decryption container for storage of encrypted data in accordance with various aspects of the present disclosure. Referring to FIG. 27, at block 2710, a setup configuration file may be defined that includes pathnames to each of the available storage locations. The storage location may be the hard disk drive of the device, a drive installed within the LAN or across a WAN remote from the cloud service endpoint, or a combination thereof. The setup configuration file may also define other system options.

  At block 2720, the system may be started and at block 2740 VCC may be established. For example, the system may read the setup configuration file and establish VCC for subsequent access. At block 2750, the system may be accessed to encrypt or decrypt data. For example, an application that requires data encryption or decryption may make an API call to the system. At block 2760, the data may be encrypted or decrypted as requested by the application by VCC. For example, the system may perform application requests by encrypting data and storing it in VCC, or retrieving and decrypting data stored in VCC.

XVI. Additional Features According to various aspects of the present disclosure, the system may have a security engine with the ability to meet regulatory restrictions. The system may be configured with a restricted AES-128 or lower cipher not exported. Alternatively, the system may be configured to use a FIPS 140-2 library or an external cryptographic hardware product. The system is not tied to any cryptographic ciphers, and thus adapts to the needs and needs of the user and grows with it. For example, for users in countries where strong cryptographic libraries can not be exported to the system, the system may be configured with libraries authorized by US export law.

  In addition, the system may operate as a centralized server or encryption device, and may have the ability to execute on the endpoint device for data protection once stored. According to the present disclosure, data fragments may have tamper detection upon receipt to eliminate the possibility of hackers changing data during transit. The system authenticates individual fragments as they are received. Several methods, including but not limited to GCM based AES-256 encryption, may be used to perform this authentication. Fragments that do not pass this authentication are identified as being tampered with and rejected. Depending on the configuration, FHOOSH reacts in various ways, such as key rotation, connection termination, or fragment retransmission.

  While various embodiments have been described above, it should be understood that they are presented by way of example only and not limitation. The scope should not be limited by any of the above described exemplary embodiments. Where this document refers to techniques which are obvious or known to the person skilled in the art, such techniques include those which are obvious or known to the person skilled in the art now or in the future. Also, the described embodiments are not limited to the example basic design concepts or configurations shown, but the desired functionality may be implemented using various alternative basic design concepts and configurations. As will become apparent to those skilled in the art after reading this document, the illustrated embodiments and their alternatives may be implemented without limitation to the illustrated examples. Those skilled in the art will also understand how alternative functional, logical or physical partitioning and configuration can be used to perform the desired functions of the described embodiments.

  Furthermore, although an item, ingredient or component may be described or claimed in the singular, the plural is considered to be within the scope unless a limitation to the singular is explicitly stated. The presence of words and phrases such as "one or more", "at least", and "other words" or "like" other such words in some cases are intended to spread such ranges Where a phrase may be missing, it should not be read to mean that the narrower case is intended or required.

Claims (85)

On the client device, decomposing the first data object into a first fragment associated with the first original record locator and a second fragment associated with the second original record locator;
On the client device, the first original record locator is obfuscated to generate a first obfuscated record locator, and the second original record locator is obfuscated to a second obfuscation. Generating a record locator,
Encrypting the first fragment on the client device using a first encryption key and encrypting the second fragment using a second encryption key;
The first encrypted fragment and the corresponding first obfuscated record locator and the second encrypted fragment and the second obfuscation in at least a first plurality of storage locations Storing the first data object, including storing a consolidated record locator.   The method of claim 1, wherein the first data object is decomposed by application of a decomposition function.   3. The method of claim 2, further comprising selecting the decomposition function based at least in part on one or more variable storage parameters.   The one or more variable storage parameters may be: username, user passphrase, current security model, type of the first data object, size of the first data object, one or more security requirements 4. The method of claim 3, comprising at least one of a condition and one or more performance requirements.   3. The method of claim 2, further comprising changing the one or more variable storage parameters in response to detection of a trigger.   The claim, wherein the trigger comprises a security breach for one or more of the first data object, the second data object, the first plurality of storage locations, and the second plurality of storage locations. The method described in 5.   Determining the first encryption key based on at least a portion of the first original record locator, and determining the second encryption key based on at least a part of the second original record locator The method of claim 1, further comprising   The method of claim 7, wherein the first encryption key and the second encryption key are further determined based at least in part on one or more variable storage parameters.   The one or more variable storage parameters may be: username, user passphrase, current security model, type of the first data object, size of the first data object, one or more security requirements 9. The method of claim 8, comprising at least one of a condition and one or more performance requirements.   9. The method of claim 8, further comprising changing the one or more variable storage parameters in response to detection of a trigger.   11. The method of claim 10, wherein the trigger comprises a security breach for one or more of the first data object, the second data object, the first plurality of storage locations, and the second plurality of storage locations. The method described in.   The method of claim 1, further comprising obfuscating each of the first fragment and the second fragment prior to encryption of the first fragment and the second fragment.   The first fragment is encrypted with the second encryption key using the first encryption key, and the second fragment is a third encryption key using the second encryption key The method according to claim 1, wherein the third encryption key is used to encrypt a third fragment of the first data object. Obfuscating each of the first original record locator and the second original record locator,
Changing each of the first original record locator and the second original record locator;
The method of claim 1, comprising applying an obfuscation function to each of the first original record locator and the second original record locator.   15. The method of claim 14, wherein each of the first original record locator and the second original record locator is obfuscated based at least in part on one or more variable storage parameters.   The one or more variable storage parameters may be: username, user passphrase, current security model, type of the first data object, size of the first data object, one or more security requirements 16. The method of claim 15, comprising at least one of a condition and one or more performance requirements.   16. The method of claim 15, further comprising changing the one or more variable storage parameters in response to detection of a trigger.   28. The method according to claim 27, wherein the trigger comprises a security breach for one or more of the first data object, the second data object, the first plurality of storage locations, and the second plurality of storage locations. The method described in.   The first encrypted fragment and the corresponding first obfuscated record locator, and the second encrypted fragment, based at least in part on one or more variable storage parameters The method of claim 1, further comprising: identifying at least the first plurality of storage locations to store the second obfuscated record locator.   The one or more variable storage parameters may be: username, user passphrase, current security model, type of the first data object, size of the first data object, one or more security requirements 21. The method of claim 19, comprising at least one of a condition and one or more performance requirements.   20. The method of claim 19, further comprising changing the one or more variable storage parameters in response to detection of a trigger.   An index of the sequence of the first fragment and the second fragment of the first data object, the first encryption key and the second encryption key, the first obfuscated record locator, and The method of claim 1, further comprising generating a data map including the second obfuscated record locator and at least one or more of the first plurality of storage locations.   23. The method of claim 22, further comprising encrypting the data map and storing the encrypted data map.   23. The method of claim 22, further comprising changing the content of the data map based on at least a portion of one or variable storage parameters.   The one or more variable storage parameters may be: username, user passphrase, current security model, type of the first data object, size of the first data object, one or more security requirements 25. The method of claim 24, comprising at least one of a condition and one or more performance requirements. With multiple storage locations,
A secure platform comprising the one or more processors;
Decompose the first data object into a first fragment associated with the first original record locator and a second fragment associated with the second original record locator;
Obfuscate the first original record locator to generate a first obfuscated record locator, obfuscate the second original record locator to generate a second obfuscated record locator,
Encrypting the first fragment using a first encryption key and encrypting the second fragment using a second encryption key;
In at least a first plurality of storage locations, said first encrypted fragment and corresponding first obfuscated record locator, and said second encrypted fragment and said second obfuscation CLAIMS: 1. A storage system for a first data object, comprising: a client device comprising one or more processors configured to store stored record locators.   27. The system of claim 26, wherein the one or more processors are configured to apply a decomposition function to decompose the first data object.   28. The system of claim 27, wherein the one or more processors are further configured to select the decomposition function based at least in part on one or more variable storage parameters.   The one or more variable storage parameters may be: username, user passphrase, current security model, type of the first data object, size of the first data object, one or more security requirements 29. The system of claim 28, comprising at least one of a condition and one or more performance requirements.   28. The system of claim 27, wherein the one or more processors are further configured to change the one or more variable storage parameters in response to detection of a trigger.   31. The system according to claim 30, wherein the trigger comprises a security breach for one or more of the first data object, the second data object, the first plurality of storage locations, and the second plurality of storage locations. The system described in.   The one or more processors determine the first encryption key based at least in part on the first primary record locator, and the first one or more processors are based on at least one part of the second primary record locator 27. The system of claim 26, further configured to determine an encryption key of two.   The one or more processors are further configured to determine the first encryption key and the second encryption key based at least in part on one or more variable storage parameters, The system of claim 32.   The one or more variable storage parameters may be: username, user passphrase, current security model, type of the first data object, size of the first data object, one or more security requirements 34. The system of claim 33, comprising at least one of a condition and one or more performance requirements.   34. The system of claim 33, wherein the one or more processors are further configured to change the one or more variable storage parameters in response to detection of a trigger.   The trigger may include a security breach for one or more of the first data object, the second data object, the first plurality of storage locations, and the second plurality of storage locations. The system described in.   The one or more processors are further configured to obfuscate each of the first fragment and the second fragment prior to encryption of the first fragment and the second fragment; The system of claim 26.   The first fragment is encrypted with the second encryption key using the first encryption key, and the second fragment is a third encryption key using the second encryption key The system according to claim 26, wherein the third encryption key is used to encrypt a third fragment of the first data object. Said one or more processors for obfuscating each of said first original record locator and said second original record locator,
Modify each of the first original record locator and the second original record locator,
27. The system of claim 26, configured to apply an obfuscation function to each of the first original record locator and the second original record locator.   The one or more processors obfuscate each of the first original record locator and the second original record locator based at least in part on one or more variable storage parameters 40. The system of claim 39, further configured.   The one or more variable storage parameters may be: username, user passphrase, current security model, type of the first data object, size of the first data object, one or more security requirements 41. The system of claim 40, comprising at least one of a condition and one or more performance requirements.   51. The system of claim 50, wherein the one or more processors are further configured to change the one or more variable storage parameters in response to detection of a trigger.   The trigger may comprise a security breach for one or more of the first data object, the second data object, the first plurality of storage locations, and the second plurality of storage locations. The system described in.   The first encrypted fragment and the corresponding first obfuscated record locator, wherein the one or more processors are based at least in part on one or more variable storage parameters; 27. The system of claim 26, further configured to identify at least the first plurality of storage locations storing the second encrypted fragment and the second obfuscated record locator.   The one or more variable storage parameters may be: username, user passphrase, current security model, type of the first data object, size of the first data object, one or more security requirements 45. The system of claim 44, including at least one of a condition and one or more performance requirements.   45. The system of claim 44, wherein the one or more processors are further configured to change the one or more variable storage parameters in response to detection of a trigger.   The one or more processors may include an index of the sequence of the first fragment and the second fragment of the first data object, the first encryption key and the second encryption key, Claimed is further configured to generate a data map having one obfuscated record locator and the second obfuscated record locator, and at least one of the first plurality of storage locations. The system according to Item 26.   48. The system of claim 47, wherein the one or more processors are further configured to encrypt the data map and store the encrypted data map.   48. The system of claim 47, wherein the one or more processors are further configured to change the contents of the data map based on at least a portion of one or variable storage parameters.   The one or more variable storage parameters may be: username, user passphrase, current security model, type of the first data object, size of the first data object, one or more security requirements 50. The system of claim 49, comprising at least one of a condition and one or more performance requirements. Retrieving a data map including at least a first portion of information needed to retrieve and reconstruct the data object;
Performing one or more calculations to dynamically retrieve at least a second portion of the information needed to retrieve and reconstruct the data object;
Retrieving the data object from at least a first plurality of data storage locations, based on one or more of the information contained in the data map and the information dynamically obtained through one or more calculations Reconfiguring the data object, and retrieving the data object.   The information needed to retrieve and reconstruct the data object is an index of a sequence of fragments of the data object, an encryption key used to encrypt each of the fragments, the fragments 52. The method of claim 51, comprising an obfuscated record locator associated with each of at least the first plurality of storage locations where each of the plurality of fragments is stored.   52. The system of claim 51, wherein the one or more calculations are performed to dynamically retrieve a portion of the information needed to retrieve and reconstruct the data object not included in the data map. the method of.   Determination of a decomposition function to which the one or more calculations are applied to decompose the data object into a plurality of fragments, determination of obfuscated record locators associated with each of the plurality of fragments, the plurality of fragments 52. The method of claim 51, comprising: calculating an encryption key to be used for each encryption of and identifying at least the first plurality of storage locations where each of the plurality of fragments is stored.   The range of calculations required for the modification of the contents of the data map to be performed to dynamically obtain the second portion of the information required for retrieval and reconstruction of the data object In the alternative, the content of the data map includes: username, user passphrase, current security model, type of data object, size of data object, one or more security requirements, and one or more performances 52. The method of claim 51, wherein the method is modified based on one or more of the requirements. A first data store and a second data store,
A client device configured to send a request to retrieve user data stored in the first data store;
Storing user authentication information and data store authentication information in the second data store separated from the user's data stored in the first data store;
Receiving the request from the client device to retrieve user data stored in the first data store;
Responding to the request for retrieving user data, retrieving from the second data store user authentication information associated with the user of the client device and data store authentication information associated with the first data store;
Retrieving user data from the first data store using the user authentication information of the user of the client device and data store authentication information of the first data store;
A system for storing and managing authentication information and encryption keys, comprising: a secure key platform configured to provide data of the user to the client device.   The secure key platform is further configured to register the client device including by verifying and recording one or more of: browser type, plug-in, hardware settings, and location. The system of claim 1.   The secure key platform is further configured to register the client device by asking one or more difficult questions and storing responses to the one or more difficult questions. System described.   The client device is further configured to attempt to log into the secure key platform, and the secure key platform retrieves the user authentication information and the data store authentication information, using the user authentication information and the data store authentication information. The system of claim 1, further configured to authenticate the client device prior to retrieving user data from the first data store.   5. The system of claim 4, wherein the secure key platform is configured to automatically retrieve the user authentication information in response to successful authentication of the client device.   The secure key platform may include a username provided by the user, a password provided by the user, a response to at least one difficult question provided by the user, a type of browser of the client device, the client device To authenticate the client device based on one or more of: a plug-in of the client device, a hardware configuration of the client device, a localization of the client device, and an Internet Protocol (IP) address at which the client device attempts the login. The system of claim 4 configured.   The system of claim 1, wherein the user authentication information comprises a first pass phrase.   The system of claim 7, wherein the user's data stored in the first data store is encrypted using the first passphrase.   A first pass phrase controls access to a second pass phrase, the user data stored in the first data store being encrypted using the second pass phrase The system according to Item 7. Decompose the user's data into multiple segments,
The system of claim 1, further comprising a secure object platform configured to store the plurality of segments of the decomposed user's data across a plurality of data stores including the first data store. Establishing communication for data streaming between the first device and the second device;
Establishing a shared key,
Exchanging the shared key between the first device and the second device;
Encrypting the data set by the first device using the shared key;
Decrypting the data set by the second device using the shared key;
Evaluating rekeying criteria to determine whether the shared key should be regenerated;
In response to the determination that the shared key should be regenerated,
Generate a new shared key,
Encrypting the next set of data with the first device using the new shared key.   The method of claim 1, wherein the establishing of a shared key comprises providing encryption algorithm parameters and seeds for the encryption algorithm.   The method of claim 1, wherein the exchange of the shared key comprises the integration of multiple key exchange methods.   4. The method of claim 3, further comprising dynamically changing at least one of a key exchange method and key exchange frequency.   5. The method of claim 4, wherein at least one of a key exchange method and key exchange frequency is dynamically changed based on performance requirements and security threat levels of the first device or the second device.   The method according to claim 1, wherein the rekeying criteria are evaluated to determine whether the shared key should be regenerated.   7. The method of claim 6, wherein a rekeying criterion identifies an available encryption algorithm and specific parameters for the encryption algorithm.   7. The method of claim 6, further comprising monitoring of a situation indicating when the shared key should be regenerated until the rekeying criteria are met.   The method of claim 1, wherein generating the new shared key comprises providing new encryption algorithm parameters for the shared key.   The method of claim 1, further comprising providing a high degree of security by using secure keys and maximizing the rate of key rotation of the data set. Communication interface,
Establish communication for data streaming between the first device and the second device,
Establish a shared key,
Exchanging the shared key between the first device and the second device;
Encrypting the data set by the first device using the shared key, the second device decrypting the data set using the shared key,
Evaluating rekeying criteria to determine if the shared key should be regenerated,
In response to the determination that the shared key should be regenerated,
Generate a new shared key,
An authenticated communication system between devices, comprising: a processor configured to encrypt the next data set by the first device using the new shared key.   The system of claim 11, wherein the processor is further configured to establish a shared key by providing encryption algorithm parameters and seeds for the encryption algorithm.   The system of claim 11, wherein the processor is further configured to integrate multiple key exchange methods for exchange of the shared key.   The system of claim 13, wherein the processor is further configured to dynamically change at least one of key exchange method and frequency of key exchange.   15. The system of claim 14, wherein at least one of the key exchange method and key exchange frequency is dynamically changed based on performance requirements and security threat levels of the first device or the second device. .   12. The system of claim 11, further configured to evaluate rekeying criteria to determine whether the shared key should be regenerated.   17. The system of claim 16, wherein rekeying criteria identify possible encryption algorithms and specific parameters for the encryption algorithms.   17. The system of claim 16, wherein the processor is further configured to monitor a situation indicating when the shared key should be regenerated until rekey criteria are met.   The system of claim 11, wherein the processor is further configured to provide new encryption algorithm parameters for generation of the shared key. The processor is further configured to provide a high degree of security by using secure keys and maximizing the rate of key rotation for the data set.
The system of claim 11, further comprising:

Images