Systems and methods for generating and verifying apostilles and government records

Abstract

Systems and methods for generating and validating eApostilles and other Government Records are described. A Publisher or Issuer may receive a Government Record order from a Customer or Member, and prepare the requested Government Record. The Issuer may involve one or more notaries or Government officials to issue the eApostille and / or may rely on a signatory database of known notaries or officials. The Issuer may associate each Government Record with authentication information for the Underlying Document and a record, and retain a database of associated authentication information and records. The publisher or Issuer may provide validation services, receiving a validation request through a validation portal, and provide a validation response through the validation portal indicative of the validity and, in some instances, additional information or documentation

Description

Docket 6819-0058 SYSTEMS AND METHODS FOR GENERATING AND VERIFYING APOSTILLES AND GOVERNMENT RECORDS STATEMENT REGARDING GOVERNMENT SUPPORT

[0001] None. FIELD

[0002] The present disclosure relates to systems and methods for generating and authenticating Government Records, and in particular electronic Government Records. BACKGROUND

[0003] Government Records, such as the Apostille, Vital Records (Birth, Death, and Marriage certificates), and other types of government issued documents (collectively, “Government Records”) have been the corner stone of state credentials for over 100 years. In fact, the first standard certificates for the registration of live births were developed in 1900 by the Bureau of the Census. Since then, government records have evolved not only in design but with the information they have displayed.

[0004] However, while government have added more sophisticated security features to the Government Records, apostilles, vital record and other legal records, remain prone to forgery, along with long process times: to order an apostille and have it delivered to the requesting entity can take 6 weeks to 3 months. In terms of forgery, fake birth certificates are on the rise, according to National Public Radio and agencies like Border Patrol in El Paso, Texas. Often, they are used by foreign nationals to improve their chances of getting US residency and in some cases, even to fake family ties that do not exist.Docket 6819-0058

[0005] Given the presence of the fraudulent Government Records market and / or long processing times, there is also a need to present Government Records in a highly secure format that is verifiable through the Competent Authority. As used herein, a Competent Authority is any person, entity or organization that has the legally delegated or invested authority, capacity, or power to perform a designated function on behalf of a country or government. The Competent Authority varies by country and often depends on the context of the action. For example, in some cases, the Competent Authority may be a court, an administrative agency, or both. With the understanding that a Competent Authority may take the form of, e.g., a Government agency, appointee, or delegate, among others, the terms Competent Authority and Government are used synonymously in the examples set forth below. Secure formats protect Government Records from fraud and misuse, strengthening the value and goodwill associated with the Government Record. Providing a verification mechanism enhances the trust that individuals place in the Government Record. Coupled with more efficient processing times, millions of dollars can be saved in commerce alone.

[0006] More recently, commerce saw significant impact with COVID and the fact that Government could not issue Government Records during many months of the pandemic. This hugely affected a number of industries, including, for example, legal practices, financial institutions, and those needing death certificates related to probate. The list of industries affected by the lack of business continuance was significant. Because governments are also faced with tight budgets this has meant that software solutions are often lacking, out of date or mainly nonexistent to offer effective solutions for business continuance, or the ability to effectively protect, for example, a large array of Personal Identifiable Information (PII), corporate information or estate planning information that the Government would not normally store in relation to, for example, anDocket 6819-0058 Apostille. Antiquated software and infrastructure also leave Government vulnerable to malware and viruses were the public allowed to upload documents to their system for review.

[0007] Governments also have the need to securely share information between agencies. For example, the Secretary of State (SOS), which issues Apostilles, needs to verify the signature of the Clerk from Vital Records who signed a birth certificate, before the SOS can issue an Apostille on that Government Record. Often, these signatures are kept within each agency and when shared are done so through a paper mechanism or by email when requested.

[0008] Often, Government Records contain sensitive PII, and the distribution of these documents is fraught, since the records cannot be sent via unsecured email since it may expose PII to criminals. Often Government Records contain more PII than the Customer needs to share, for example a Birth Certificate may share a mother’s maiden name when all the Receiving Entity is wishing to confirm age. The receiving entity is also likely to have a policy about opening documents due to viruses and malicious software and would not expect such records to be sent via email.

[0009] In the context of apostilles, the “Underlying Document” is a document, often a public document or a credential, that is issued in a country (which can include governments, government agencies, localities, and the like) that is a party to the Hague Convention and will be used in another country that is also party to the Convention. The current environment in Government is that the production, delivery, and authentication of government-issued credentials and other documents and Government Records, have historically revolved around the issuance of paper documents, e.g., certificates, licenses and so on. The process has involved traditional forms of printing, and the use of special paper, embossed seals and then personalizing the credential using the owner’s / customer’s personal information, using such as a laser printer. The distributionDocket 6819-0058 of the paper credential or document, or the “Underlying Document,” has typically involved the customer having to visit their local government office or by U.S. Mail. The authentication of the printed document has often been as simple as a customer presenting the credential to a Receiving Entity and the Receiving Entity reviewing the secure printing used in the production of the Government Record. For more discerning Receiving Entities, additional verification is needed either through notarization of the document, or in some cases a paper Apostille is required for when sharing documents internationally. These processes are often open to fraud, are expensive, and / or may take a significant amount of processing time.

[0010] An Apostille is a form of Authentication / Certification to be used in countries who are signed members as a part of the Hague Convention. It is a legalization standard that allows an Underlying Document to be shared amongst member countries. Commerce relies on Apostilles internationally, for example as proof of their “Good Standing” to conduct business in other countries.

[0011] To date there have been no third-party solutions to produce Government Records that consider the issuance of both digital and paper, the unique workflows of Government and the secure handling and distribution of such records, while ensuring secure communication between all those parties involved in the process, including but not limited to customer, commercial and noncommercial entities, organizations, and the Government.

[0012] According to the State Department, the idea of a digital apostille was first conceived in 2004, and since then, no third party has developed any solution for their issuance. Only one state sought to issue but failed to issue more than a handful of digital Apostilles. Additionally, and according to NAPHSIS, The National Association for Public Health Statistics and Information Systems, and presented at their national conference, June 2023, digital vital records are at least 4-Docket 6819-0058 5 years from becoming reality: like the Secretary of State, Vital Record Agencies know they need digital vital records, but have no clear path to attainment, or the features they may need in the credential or platform while ensuring secure issuance and acceptance.

[0013] What is needed are secure systems and methods to efficiently generate and deliver large quantities of unique and secure electronic credentials for Governments.

[0014] What is also needed is the ability to verify government officials digitized, signatures, Notary Public signatures, and other individuals / entities whose signatures need to be verified against submitted documents.

[0015] What is also needed are secure systems and methods that allow those entities within the Government environment, the general public, notary publics, banks, lawyers, accountants and so forth, to effectively submit requests for certain documents, like apostilles, and allow for secure communications to occur within that system.

[0016] What is also needed is the ability to authenticate a digital Government Record that gives the authenticating / receiving party the needed level of confidence and assurance that the Government Record or Underlying Document is authentic and valid.

[0017] What is also needed is the ability to securely distribute the Government Record, such that it does not give the receiving entity concern in accessing the document (virus) while protecting the Personal Identifiable Information of the owner of the document.

[0018] What is also needed is a secure, web-accessible system that can issue secure verifiable government records from home during unforeseen shutdowns.

[0019] What is needed is a sophisticated infrastructure able to protect the Customer’s data, data that is not normally held by Governments.

[0020] What is also needed is a platform that can distribute Government Records to theDocket 6819-0058 receiving entity in a secure manner, such that the transfer of the credential does not expose personal identifiable information to malicious third parties and only allows the information to be shared with the intended recipient. BRIEF SUMMARY

[0021] This disclosure generally relates to systems and methods for generating and verifying electronic apostilles relating to Underlying Documents and other Government Records.

[0022] In some embodiments, the present approach may take the form of an electronically implemented system for generating an electronic apostille for an underlying document. The system may include a notary signature database having a plurality of electronic signature representations of notary signatures, each electronic signature representation of a notary signature corresponding to a unique known notary; a public official signature database, a plurality of electronic signature representations of public official signatures, each electronic signature representation of a public official signature corresponding to a unique known public official authorized by a competent authority to sign the underlying document; an underlying document receipt interface configured to receive proffered underlying document submissions from a first requesting entity, each proffered underlying document submission associated with a unique underlying document and including a first proffered signature and a document type, the document type identifying the proffered signature as a notary signature or a public official signature; an electronic apostille format database comprising at least one electronic apostille document format having a fields for receiving apostille information, underlying document information, and at least one digital security feature; and a generated electronic apostille database comprising a plurality of generated apostille records, each generated apostille record corresponding to a generated apostille and having information associated with the generated apostille; and an electronic apostille generationDocket 6819-0058 computer configured to receive a proffered underlying document submission from a first requesting entity through the underlying document receipt interface, compare the first proffered signature with signatures in at least one of the notary signature database and the public official database, and either (1) reject the proffered signature as invalid, or (2) validate the proffered signature select, generate an electronic apostille for the first underlying document using an electronic apostille document format from the electronic apostille format database, and generate a generated apostille record for storage in the generated electronic apostille database. In some embodiments, the document type further comprises information describing the proffered signature.

[0023] The electronic apostille document format may include digital security features such as disruptive filaments, a digital certificate ribbon, a three-dimensional competent authority seal, a multi-colored signature woven into disruptive filaments, micro-printing, and a document number. In some embodiments, the electronic apostille document format further comprises a description of any included digital security features. In some embodiments, the electronic apostille document format includes instructions for verifying at least one of an issued electronic apostille and an underlying document. These features allow the recipient and validating entities to have a higher level of confidence in the authenticity of the apostille and underlying document.

[0024] In some embodiments, the electronic apostille format database includes a plurality of competent authority seals and at least one electronic apostille document format includes a field for receiving a competent authority seal. Some embodiments may include an electronic apostille validation request interface configured to receive electronic apostille validation requests and proffered authentication information from a first validating entity, and having a computer processor configured to identify a generated apostille record corresponding to the proffered authentication information, and generate an apostille validation response based on the identifiedDocket 6819-0058 generated apostille record. In some embodiments may be used to serve multiple competent authorities, government agencies, and the like, and feature plurality of electronic apostille validation request interfaces, wherein each electronic apostille validation request interface is uniquely associated with a competent authority. For example, a state department may provide a single electronic apostille validation request interface, or multiple electronic apostille validation request interfaces for each individual agency or department. In some embodiments, the identified generated apostille record is associated with a first competent authority, and the electronic apostille validation request interface is configured to transmit the generated apostille validation response to at least one of the first competent authority, the first requesting entity, and the first validating entity. In some embodiments, the electronic apostille generation computer is further configured to issue a rejection indication in response to rejecting a proffered signature as invalid.

[0025] Some embodiments of the present approach may protect an individual’s personal data. For example, a proffered underlying document submission may include personal identifiable information (PII) of an individual. If that individual does not wish for all of the PII to be visible to later recipients (e.g., validating entities), then the underlying document receipt interface may be configured to receive from that requesting entity a first category of PII for inclusion in an associated generated apostille record. For example, if the requesting entity only wishes for a place of birth to be displayed, and hide other PII (e.g., birth name, birthday, etc.), that individual may select the place of birth as the first category for disclosure in association with the electronic apostille and / or validation responses. Thus, in some embodiments the electronic apostille validation request interface is configured to generate an apostille validation response including the first category of PII.

[0026] Some embodiments of the present approach may take the form of an electronicallyDocket 6819-0058 implemented method for generating an electronic apostille for an underlying document. Such embodiments may involve storing, in a notary signature database, a plurality of electronic signature representations of notary signatures, each electronic signature representation of a notary signature corresponding to a unique known notary; storing, in a public official signature database, a plurality of electronic signature representations of public official signatures, each electronic signature representation of a public official signature corresponding to a unique known public official; receiving an electronic apostille request and proffered underlying document from a first requesting entity, the proffered underlying document including a proffered signature and a document type, the document type identifying the proffered signature as a notary signature or a public official signature; selecting one of the notary signature database and the public official signature database based on the document type; comparing the proffered signature with the selected signature database to confirm the proffered signature corresponds to an electronic signature representation in the selected signature database; generating an apostille request response based on the comparison; and transmitting the apostille request response to the first requesting entity. It should be appreciated that the comparing step may be performed automatically, such as when a competent authority already knows the source of the underlying document (e.g., from the same government agency). Upon confirming the proffered signature corresponds to an electronic signature representation in the selected signature database, the apostille request response may include an electronic apostille associated with the underlying document.

[0027] In some embodiments, generating an apostille request response includes selecting an electronic apostille document format from an electronic apostille format database having a plurality of electronic apostille document formats, each format having a fields for receiving apostille information, underlying document information, and at least one digital security feature;Docket 6819-0058 populating the selected electronic apostille document format with apostille information and underlying document information. The proffered underlying document (i.e., an electronic copy thereof) may be stored in an underlying document database, and providing access to the proffered underlying document in connection with the electronic apostille.

[0028] In some embodiments, a proffered underlying document submission includes a plurality of personal identifiable information (PII) from the first requesting entity, and the first requesting entity may identify a first category of PII for inclusion in an associated generated apostille record as discussed above. In some embodiments, the apostille request response includes an electronic apostille associated with the underlying document and the first category of PII.

[0029] In some embodiments, the electronic apostille includes an apostille verification code, and the apostille verification code and information corresponding to the electronic apostille is added to a generated electronic apostille database. Access to an electronic apostille validation request interface may be provided with the apostille request response. The electronic apostille validation request interface is configured to receive an electronic apostille verification request and proffered apostille verification code from a validating entity, identify the proffered apostille verification code in the electronic apostille database, and transmit an electronic apostille verification response through the electronic apostille verification interface to the validating entity.

[0030] It should be appreciated that the underlying document may be any document that an individual seeks to have notarized, authenticated, or apostilled, including but not limited to a government record, a background check, a criminal record, a medical certificate of good health, a medical license, a passport, a police report, a business filing, an incorporation certificate, an annual report, a vital record, a birth certificate, a death certificate, a marriage certificate, a court record, a title to real property, a title to intangible property, a title to chattels, a recorded title, a recordedDocket 6819-0058 conveyance, a license, a separation agreement, a divorce certificate, and an adoption certificate.

[0031] In some embodiments the present approach may take the form of an electronically implemented method for generating an electronic apostille for an underlying document. The method may involve storing, in a notary signature database, a plurality of electronic signature representations of notary signatures, each electronic signature representation of a notary signature corresponding to a unique known notary. It may further involve storing, in a public official signature database, a plurality of electronic signature representations of public official signatures, each electronic signature representation of a public official signature corresponding to a unique known public official. The method may further involve storing, in a credential recipient personal access key database, a first credential recipient personal access key associated with at least one of the first certified electronic credential record and an authentication information associated with the first certified electronic credential record. Next, the method may involve receiving an electronic apostille request and proffered underlying document a first requesting entity, the proffered underlying document including a proffered signature and a document type, the document type identifying the proffered signature as a notary signature or a public official signature. Next, the method may involve selecting one of the notary signature database and the public official signature database based on the document type. The method may then involve comparing the proffered signature with the selected signature database to confirm the proffered signature corresponds to an electronic signature representation in the selected signature database. Next, the method may involve generating an apostille request response based on the comparison and then transmitting the apostille request response to the first requesting entity. In some embodiments, upon confirming the proffered signature corresponds to an electronic signature representation in the selected signature database, the apostille request response includes an electronic apostille with theDocket 6819-0058 underlying document.

[0032] In some embodiments, the electronically implemented method may further involve storing the proffered underlying document in an underlying document database, and providing access to the proffered underlying document in connection with the electronic apostille.

[0033] In some embodiments, the electronically implemented method may further involve the electronic apostille having an apostille verification code. The apostille verification code may include information corresponding to the electronic apostille to an electronic apostille database. Access to an electronic apostille verification portal may be provided with the apostille request response. The electronic apostille verification portal may be configured to receive an electronic apostille verification request and proffered apostille verification code from an Inquiring Entity, identify the proffered apostille verification code in the electronic apostille database, and transmit an electronic apostille verification message through the electronic apostille verification portal to the Inquiring Entity.

[0034] It is an object of this disclosure to describe secure systems and methods to efficiently generate and deliver large quantities of unique and secure electronic credentials for Governments.

[0035] It is another object of this disclosure to describe systems and methods to provide the ability to verify government officials digitized, signatures, Notary Public signatures, and other individuals / entities whose signatures need to be verified against Underlying Documents.

[0036] It is another object of this disclosure to describe secure systems and methods that allow those entities within the Government environment, the general public, notary publics, banks, lawyers, accountants and so forth, to effectively submit requests for certain documents, like apostilles, and allow for secure communications to occur within that system.Docket 6819-0058

[0037] It is another object of this disclosure to describe secure systems and methods that authenticate a digital Government Record that gives the authenticating / receiving party the needed level of confidence and assurance that the credential is authentic and valid.

[0038] It is another object of this disclosure to describe secure systems and methods for securely distributing Government Records, such that each Receiving Entity maintains confidence in the authenticity and security of the transmitted Government Records, without risk downloading and / or transmitting of malicious code, and the Personal Identifiable Information of the owner of the Government Record and / or set forth in the Government Record remain secure.

[0039] It is another object of this disclosure to describe secure, web-accessible systems and methods that issue secure, verifiable Government Records from home during unforeseen shutdowns.

[0040] It is another object of this disclosure to describe a platform that can create custom Government Records, such that only the desired information is displayed for a Receiving Entity, rather than PII that may not be needed or required.

[0041] It is another object of this disclosure to describe a platform for distributing Government Records to the Receiving Entity in a secure manner, such that the transfer of the credential does not expose personal identifiable information to malicious third parties and only allows the information to be shared with the intended recipient.

[0042] It is another object of this disclosure to describe a infrastructure that can securely protect the PII of the customers while supporting the foregoing objects. DESCRIPTION OF THE DRAWINGS

[0043] Fig.1 shows a sample electronic format of a government record, or example anDocket 6819-0058 Apostille, generated by an embodiment of the present approach.

[0044] Figs.2A and 2B show account creation options presented to a Customer and Notary upon according to an embodiment of the present approach.

[0045] Fig.3 illustrates the process of a Notary creating an account and registering their signature and commission according to an embodiment of the present approach

[0046] Fig. 4 illustrates a process for creating a Customer account according to an embodiment of the present approach.

[0047] Fig. 5 shows the account profile options an Agent or Organization have within their account in an embodiment of the present approach.

[0048] Fig. 6 is a flowchart of a process for a Customer requesting an Apostille of an underlying document in an embodiment of the present approach.

[0049] Fig. 7 shows a process for a Government, including a Government agency or Secretary of State, to create a Government user accounts in an embodiment of the present approach.

[0050] Fig.8 illustrates a menu available to a Government account, and in particular a Secretary of State, according to an embodiment of the present approach.

[0051] Fig. 9 is a flowchart of a process for a Government creating an order for a Customer in their office in an embodiment of the present approach.

[0052] Fig. 10 shows a process for electronically processing an order to generating an eApostille according to an embodiment of the present approach.

[0053] Fig. 11 illustrates a demonstrative process confirming the signature of a Government Record for generating an Apostille, according to an embodiment of the present approach.Docket 6819-0058

[0054] Fig. 12 shows a process for maintaining a signature database according to an embodiment of the present approach.

[0055] Fig. 13 shows a process for rescinding a Government Record according to an embodiment of the present approach.

[0056] Fig.14 shows a process for a Government Agency sharing a Government Record with another agency for processing an order according to an embodiment of the present approach.

[0057] Fig. 15 illustrates a process for transmitting an eApostille according to an embodiment of the present approach.

[0058] Figs. 16A and 16B show a sample verification request of an electronic format Apostille generated by an embodiment of the present approach.

[0059] Fig. 17 shows a sample verification response by the Publisher of an electronic format Apostille generated by an embodiment of the present approach. DESCRIPTION

[0060] The following description is of the best currently contemplated mode of carrying out exemplary embodiments of the invention. The description is not to be taken in a limiting sense and is made merely for the purpose of illustrating the general principles of the invention.

[0061] Unless otherwise stated, terms used herein are intended to have their ordinary meaning as used in the art. For the avoidance of doubt, this description is made using the following terminology.

[0062] Competent Authority: any person, entity or organization that has the legally delegated or invested authority, capacity, or power to perform a designated function. Secure formats protect Government Records from fraud and misuse, strengthening the value and goodwill associated with the Government Record.Docket 6819-0058

[0063] Government Record: a document issued by a Government, which includes and can be one or more of a country (e.g., a federal government), a federal agency, a state, a state agency, a locality or local governmental authority, recording and / or presenting specific information relating to an individual person, persons, corporation(s), real property, intangible property, and / or chattels. Examples include, but are not limited to, Apostilles, Vital Records (e.g., birth certificates, death certificates, marriage certificates), background checks and / or reports, court records, criminal records, police reports, passports, medical certificates such as a certificate of good health, medical licenses, notarizations on a document, business reports and filings, such as certificates of incorporation and annual reports, title to real property, title to intangible property, title to chattels, recorded titles, recorded conveyances, and the like.

[0064] Apostille: a form of Authentication / Certification issued by a Competent Authority or Government to be used in countries who are signed members as a part of the Hague Convention. It is a standard legalization that allows documents to be shared amongst member countries. Commerce relies on Apostilles internationally, for example as proof of their “Good Standing” to conduct business in other countries. An Apostille can be a paper or electronic document that (1) establishes the authenticity of an official signature on another document, which may be another Government Record; (2) the capacity in which the person signing the document acted; and (3) the identity of any stamp or seal affixed to the document. As an example, when a Government’s Department of State authenticates a document with an Apostille, the department is verifying through the Apostille that the person who signed the document is an official of the issuing Government and that Government has given full faith and credit” to the official's seal and signature.

[0065] Underlying Document: a document, often a public document or a credential, that is issued in a country (which can include governments, government agencies, localities, and theDocket 6819-0058 like) that is a party to the Hague Convention and will be used in another country that is also party to the Convention. The Underlying Document may be, e.g., a Government Record, but it should be appreciated that the term is not limited to Government Records as there are several other categories of documents that one may use consistent with the present approach.

[0066] Vital Record: a Government Record made by and normally kept by a Government, that establish one or more pieces of information relating to an individual’s life. Examples include, but are not limited to, birth certificates, death certificates, marriage licenses and certificates, separation agreements, divorce certificates, adoption certificates, etc.

[0067] Notary, or Notary Public: an individual authorized by a Government to perform specific legal functions, such as witnessing a signature on a document.

[0068] Requesting Entity: An individual, corporation, organization or Government entity authorized to request an apostille. As disclosed herein, a Requesting Entity may utilize embodiments of the present approach to submit a request for an apostille, paper or electronic, in connection with an Underlying Document. For example, an executor of a will may request an apostille for a decedent’s death certificate in connection with probate proceedings.

[0069] Receiving Entity: an individual, organization, body, or the like, that receives an apostille in connection with the present approach and may seek to verify that the apostille is authentic and, in some instances, confirm the Underlying Document. For example, a foreign bank may receive an apostille and death certificate and seek to verify the authenticity of the documents before releasing a decedent’s funds to the executor. In such cases, the Receiving Entity may also be a Validating Entity. Validating an apostille and / or Government Record is generally, to provide the Receiving Entity with a reasonable level of confidence and certainty that the apostille and / or Government Record are valid, e.g., that a Government issued the apostille, and / or that the apostilleDocket 6819-0058 is directed to the Underlying Document.

[0070] Government Records, such as an issued Apostille and Underlying Document, Vital Records (birth, death, and marriage certificates), and other types of government issued documents, hereby referred to as Government Records, have been the corner stone of state credentials for over 100 years. In fact, the first standard certificates for the registration of live births were developed in 1900 by the Bureau of the Census. Since then, Government Records have evolved not only in design but with the information they have displayed.

[0071] However, while governments have added more sophisticated security features to the Government Records, apostilles, vital record and other legal records, remain prone to forgery, along with long process times: to order an apostille and have it delivered to the requesting entity can take 6 weeks to 3 months. In terms of forgery, fake birth certificates are on the rise, according to National Public Radio and agencies like Border Patrol in El Paso, Texas. Often, fake birth certificates are used by foreign nationals to improve their chances of getting US residency and in some cases, even to fake family ties that do not exist. Given the presence of the fraudulent Government Records market and / or long processing times, there is also a need to present Government Records in a highly secure format that are verifiable through the Competent Authority: Competent Authority defined as the government agency that has the legally delegated or invested authority, capacity, or power to perform a designated function, such as the issuance of Government Records. Secure formats protect Government Records from fraud and misuse, strengthening the value and goodwill associated with the Government Record. Providing a verification mechanism enhances the trust that individuals place in the Government Record. Coupled with more efficient processing times, millions of dollars can be saved in commerce alone.

[0072] The present approach provides systems and methods that enable the creation,Docket 6819-0058 storage, transmission, use, and authentication, of Government Records. Embodiments of the present approach may take the form of a software platform addressing the needs of governments, including government agencies, the general public, corporations, educational institutions, and other interested parties, that allows for the submission of requests for Government Records and documents pertaining to Government Records, verification of Government Records, and the timely issuance of Government Records in paper and digital formats that are secure, portable, and verifiable.

[0073] Secure, portable, verifiable Government Records may include Apostille, Birth certificates, Death certificates, and Marriage certificates, and other records requiring the secure production by a Government (including a Government agency), and delivery to a requesting party. Embodiments of a platform according to the present approach may include: the ability to produce secure, verifiable government records, both paper and digital formats. The ability to verify signatures and terms of officials, or Notary Publics and other officials. The ability for direct interaction between the customer, which could be a citizen of the state, Notary Publics or other entities and provide the necessary confidence in the Government to have said interactions, while limiting both the liability of having to store large amounts of PII that may be outside the purview of the Government, and the exposure of governments to viruses and other malicious software during that interaction. The ability for commerce and other interested parties to interact with government entities, request documents on behalf of their customers and have a level of interaction that is outside of the U.S. Mail and telecommunications. The ability for entities to securely download government records and credentials without the concern of viruses and malicious software. The ability for entities to be able to receive digital credentials when structure, protocols, procedures, and workflows are not in place to effectively receive digital credentials.Docket 6819-0058

[0074] Embodiments of the present approach may include the ability for members of the public, Customers, to set up verifiable accounts. In some embodiments, Customers may place on- line orders for one or more paper and / or digital Government Records, request that the Government Record be generated with options for distribution. The options for distribution may include, for example, specific recipients and / or categories of recipients, and specific modes of distribution. The options may also include having the digital Government Record transferred directly to one or more other Government agencies, such as for further processing or other use, and / or the requesting entity wishing to review said records and certificates. In some embodiments, the Customer may be given the ability to pay for services using on-line merchant services. In some embodiments, the Customer may be given the ability to access the Customer’s account, view one or more Government Records, view the status of an order, and / or to communicate securely with one or more Government entities involved in the generation, storage, transmission, and / or correction of a Government Record.

[0075] In some embodiments of the present approach, a platform may provide the ability for the Government Agency to verify signatures on a Government Record or other document, confirming that signing individual is a proper official, or Notary Public, or other authorized individual. Embodiments may provide the ability for a Government Agency to have direct on-line communication, including audio and video, between the Customer, Notary Public, and / or other entities. Embodiments may include the ability for the Government Agency to review uploaded documents from an entity, and beneficially limit the exposure of the Government Agency to viruses and other malicious software during that interaction. Some embodiments include the ability to issue invoices to, and receive payment from, entities for the services rendered.

[0076] Some embodiments provide the Government with the ability to prioritize the processing of orders, such as, e.g., orders from certain entities, such as corporations and Notaries,Docket 6819-0058 based on factors such as, e.g., urgency, accuracy and integrity of order history, etc. Some embodiments provide the ability for Government Agencies to produce secure and encrypted records, both paper and digital formats. Some embodiments provide the ability to safely distribute Government Records to or on behalf of the Customer, Notary Public, and / or other entities, to a requesting entity or other authorized recipient, without compromising personal identifiable information and other secure information. Some embodiments include the ability for the Receiving Entity to securely and independently verify the validity (e.g., the state of a record being valid) and authenticity (e.g., the quality of a record being genuine and uncorrupted) of the Government Records through the competent / issuing authority.

[0077] In some embodiments of the present approach, the platform may include the ability for corporations and other interested and authorized parties, such as Notaries, to interact with Government entities, request documents on behalf of their Customers, and have a level of secure on-line interaction that is outside of the U.S. Mail and telecommunications. It should be appreciated that U.S. Mail carries a cost and a risk of being lost or delayed, and telecommunications include security risks Some embodiments include the ability for Receiving Entities to interact with a trusted platform to securely download Government Records and Underlying Documents without the concern of viruses and malicious software. The ability for Receiving Entities to be able to receive digital credentials when structure, protocols, procedures, and workflows are not in place to effectively receive digital credentials.

[0078] Figure 4 illustrates a process for creating a Customer account according to an embodiment of the present approach. As can be seen, in this embodiment a Government domain (e.g., website) provides the user with a link to create an account in order to submit an order for a Government Record, e.g., an Apostille. The link directs the user, a Customer, to a Customer landingDocket 6819-0058 page for entering personal information and prepare an account for generation. The system receives the Customer’s information and issues a user authentication message through a secondary means, such as an email, telephone message, text message, etc., to the Customer. The authentication message includes means for the Customer to authenticate, such as a link to an authentication page, or a code to enter on the Customer landing page or the like. Following authentication, the Customer provides additional information to complete account setup, such as a user name, password, etc. Following completion of account setup, the system generates a unique Customer account identifier (e.g., account number) and activates the account for the user to login and complete the request for the Government Record.

[0079] Traditionally, Government Records have been in paper format having a variety of security features. It should be appreciated that a Government Record may be in electronic format, such as a computer-readable file representative of a credential, that typically has one or more features such that, when presented to a Receiving Entity, the Receiving Entity accepts the Government Record with confidence in its authenticity. Computer-readable files may be in various formats. One example is the Portable Document Format (PDF), identified by the file extension .pdf.

[0080] Fig. 1 illustrates an example digital apostille according to an embodiment of the present approach. This embodiment demonstrates an electronic apostille document format already having information relating to the apostille itself (e.g., the Competent Authority, authorized official signature, apostille number) and the Underlying Document (in this example, a power of attorney). The embodiment includes a variety of digital security features, such as disruptive filaments 101 that hinder alteration, digital certificate ribbon 103, three-dimensional state seal or emblem 105, an apostille or document number 107 and multicolored signature 109 woven into theDocket 6819-0058 security printing and disruptive filaments, and portions of the apostille outline 111 being micro- printed with, e.g., “Official State Document” or other phrases. This embodiment also features key information 113 in four languages, an express association 115 with the Underlying Document (in this instance, a Power of Attorney), an explanation 117 of certain security features, and Publisher Information 119. It should be appreciated that embodiments may feature any combination of these features, among others known or later developed in the art.

[0081] Generally, a PDF is a file format used to present documents in a manner independent of application software, hardware and operating system. Such features may involve document integrity security features and / or document usage security features, for example, to prohibit various forms of tampering and editing, and may include forms of password protection and / or any mechanism that shows the user that the document has been altered, tampered or edited since its original creation. Adobe Digital Signature ribbon Fig. 1, security ribbon 103 is an example of document integrity security features. In some embodiments, the Government Record may include information in a machine-readable .XML file, that may or may not be visible in the paper format or graphical representation of the Government Record. Some embodiments may make such information available during the validation process, described below in more detail.

[0082] Document usage security features may prohibit modification or misuse of the Government Record, such as through Digital Rights Management policies that allow the Government and / or a Publisher to revoke or rescind the Receiving Entity’s use of a Government Record at any point after its generation. For example, if the Government or Publisher determines that an entity fraudulently obtained a Government Record, then Government may use document usage security features to restrict further use of the Government Record, by, as an example, preventing the PDF from opening as a viewable document. In some embodiments, the GovernmentDocket 6819-0058 and / or the Publisher may prevent printing, editing, re-transmission, and other actions, using known methods, including standard, electronic, and / or software print controls, such as may be provided through available software platforms including, for instance, software offered by Adobe.

[0083] Another document usage security feature example, that may be implemented through, for example, Digital Rights Management policies, includes a Validation mechanism such as discussed herein. Validation may be performed through a variety of methods. For instance, a Validating Entity may wish to validate an Apostille with its Underlying Document represented by the Government Record. Validation may include confirming that the Apostille and Underlying Document is authentic, e.g., that the Issuer issued the Apostille and Underlying Document to the Recipient, the Apostille and Underlying Document is or remains valid, and that any information displayed on the Apostille and Underlying Document or Government Record was in fact issued by the Issuer.

[0084] A Validation mechanism may advantageously use a Unique Record Locating Number 121 (URLN, or other information on the Underlying Document or Government Record) to validate the Apostille and Underlying Document. In some embodiments, the Issuer may provide an interface for the Validation mechanism, through which a Validating Entity may input the URLN and receive a validation response, as described in more detail below. The interface may be, for example, a web site for verifying the document, SMS message, e-mail, or other similar electronic communication methods. Additionally, the Government Record may also include various visual security features to make evident any modification to the visual aspects of the Document. Advantageously, the Validation mechanism may be provided by the Competent Authority, such as a web site interface through the Competent Authority’s Internet domain. Validating Entities receive an added degree of confidence through using Validation services provided directly by the CompetentDocket 6819-0058 Authority. In some embodiments, the Validation services are provided through a web site validation portal. The portal may be hosted by the Competent Authority (e.g., through the Competent Authority’s web domain), or in some embodiments the portal may be hosted by a third party, such as the Publisher, and the Competent Authority provides a hyperlink or redirect from its domain to the validation portal.

[0085] Some embodiments may include account options for an entity to create. According to an embodiment of the present approach Figs. 2A and 2B show two account types. Fig. 2A illustrates the account creation process for a customer, which may be an individual or entity seeking apostille services, a Receiving Entity (which may also be a Validating Entity, depending on the desired services), among other platform users. Fig.2B illustrates the account creation process unique for notary publics, or notaries. It should be understood that a notary is a government-appointed official who acts as an impartial witness to the signing of important documents, including Underlying Documents. Generally, notaries are responsible for ensuring that the individuals signing a document are who they claim to be and that they have entered into the agreement willingly and knowingly.

[0086] Some embodiments of the present approach beneficially incorporate the use of notary services. Notaries are appointed by government authorities to provide specific services within the appointing jurisdiction. Notarization of documents is one important service provided by notaries. The valid signature and stamp of a Notary indicates that the identity of parties signing the document have been confirmed, and that the parties are signing willingly and knowingly. Some embodiments may include notary accounts, through which a Notary may register their signature to a database or take other actions through the Issuer relating to the Underlying Document. Fig.3 shows the process for creating a Notary account in an embodiment in the present approach. The process begins at step S301 when a Notary is required to setup an account to ensure the Issuer or Government canDocket 6819-0058 securely communicate with the Notary and for the Notary to register their signature and commission with the Issuer or Government. Some embodiments may include additional steps for the Issuer or Government to confirm the Notary’s signature and commission. Step S302 has the Notary initiate a Uniform Resource Locator (URL) which directs the Notary to a platform, that may be hosted by a Government or third party interface. Step S303 allows the Notary to complete personal information that helps identify the Notary to the Government. Information may include, full name given at birth, notary commission number, maiden name, mailing address, physical address email, phone number, social security number or any other personal identifiable information the Government may require helping identify the Notary. Step S304 confirms a method of communication with the Notary, which may be, e.g., the Notary email address or phone number, by sending a form of communication, S305, such as a unique URL, or a code to the email or phone number and describes the Notary receiving a method of communication confirming the receipt by, for example, selecting the unique URL, or entering a unique code on the platform. Step S306 describes the successful completion of S305 allowing the Notary to create secure credentials for the account, which may include a username and password. Step S307 describes the successful completion of the account and the Notary being provided a unique identification number, for example, a Notary number. S308 describes the ability for the Notary to enter their login credentials to the platform. Step S309 allows the Notary to register, by, for example, uploading their commission certificate, or an exemplar of their signature and registering with the Government. Step S310-S313 describes a process of allowing the Notary to link or establish a relationship between a notary account and a customer account if the Notary has created both accounts. Step S312 has the Notary provide the customer account number and the password to the customer account to link both accounts.Docket 6819-0058

[0087] Some embodiments may include customer accounts, through which a Customer may place orders for Government Records, or take other actions through the Issuer relating to the Underlying Document. Fig.4 shows a process for creating a Customer account in an embodiment of the present approach. The process begins at step S401 when a Customer is required to set up an account to ensure the Issuer or Government can securely communicate with the Customer during the process of ordering a Government Record. Step S402 has the Customer click on a Uniform Resource Locator (URL) which takes the Customer to a platform, that may be hosted by a Government or third party interface. In an embodiment of the present approach step S403 allows the Customer to register an account based on their profile of being an Individual, Agent or Organization. An Individual account may be used by an individual seeking a Government Record, whereas an Agent account may be [AGENT ROLE?]. An Organization account may be [ORGANIZATION ROLE?]. Individual= A member of the general Public. Agent = an entity, for example a Notary or Law Office ordering an Apostille on BEHALF of someone else. Organization: is a For-Profit, or not-for-profit entity, for example, that may need an apostille for its OWN needs. In this embodiment Step S404 provides Customer Type, Agent or Organization with administrative capabilities to the account. Step S405 allows the Customer to complete personal information that helps identify the Customer to the Government. Information may differ based on the profile specified, S403, but may include, full name given at birth, Federal Identification or State ID maiden name, position, mailing address, physical address email, phone number, social security number or any other personal identifiable information the Government may require helping identify the Customer. Step S405 confirms a method of communication with the Customer, which may be, e.g., the Customer email address or phone number, by sending a form of communication, S406, such as a unique URL, or a code to the email or phone number and describes the Customer receiving aDocket 6819-0058 method of communication and confirming the receipt by, for example, click on a unique URL, or entering a unique code on the platform. Step S407 describes the successful completion of S406 allowing the Customer to create secure credentials for the account, which may include a username and password. Step S408 describes the successful completion of the account and the Customer being provided a unique identification number, for example, a Customer number. S409 describes the ability for the Customer to enter their login credentials to the platform.

[0088] In this embodiment Fig.5 illustrates the administrative functions available to an Agent or Organization account. This account status allows the user to link a notary account S501, invite a notary to join the platform S511, and add users S519. For linking an existing notary account, the process may begin with entering certain data S503, such as the notary’s account number and access information. If the information is entered correctly S505, then the notary account is linked S507 to the Agent or Organization account. Otherwise, the platform allows for a repeat attempt S509. For inviting a notary to set up a new account S511, the process begins with entering the notary’s contact information S513, then sends a request S515 to that contact information. Some embodiments may transmit an email or other message to the notary contact information, while others may generate an email or other message for the user to send the notary. For example, the system may generate a unique URL or code and use instructions, from which the notary can use the URL or code to accept an invitation to join the platform. Upon successful completion, the notary becomes registered with a notary account S517. In some embodiments, the notary’s account may be linked to the Agent or Organization account, while in others the link option may be provided to the Agent or Organization account, and / or the notary account. For the option to add users S519, the process begins with selecting the new user’s role and rights within the platform S521, such as whether the new user can invite notaries or other users, make changesDocket 6819-0058 to existing users, etc. The request is then transmitted S523 to contact information provided for the new user, and the new user is added S525 consistent with the predetermined role and rights.

[0089] Fig. 6 is a flowchart of a process for a Customer requesting an Apostille for an underlying document in an embodiment of the present approach. Step S601 starts with the Customer logged into their account. Step S602 describes the ability for the Customer to order an Apostille from multiple State Governments. Step S603 describes level of service and responsiveness of having an Apostille returned to the Customer or sent to the Receiving Entity. Step 604 allows the Customer to choose the type of Apostille they require, in this embodiment either paper or digital. Step S605 allows the Customer to upload the underlying document if they wish to order a digital Apostille. Step S606 allows the Customer to describe the type of underlying document they wish to have Apostilled. The underlying document may be uploaded, for example, as a Portable Document Format (PDF), a Joint Photographic Experts Group (JPEG) or other type of industry recognized computer-generated file format to the platform. Step S607 describes how the Customer may better identify the attributes of the underlying document, for example, the certificate number of a birth certificate, or the applicable person to whom the document was issued, along with any special notes for the order. S608 allows the Customer to enter the delivery address information which may be a physical address or, for example, an email address if a digital apostille is requested. Step S609 allows the Customer to enter any special instructions to the order. Step S610 allows the Customer to attest to the authenticity of the underlying document and submit the order. Step S611 allows the Customer to order another Apostille for a different underlying document. Steps S612-S614 allows the Customer to review the order, complete payment information that may be processed through the platform or through a third-party processing entity and being provided with an order number and summary of the order.Docket 6819-0058

[0090] Fig. 7 shows a process for a Competent Authority, such as an Issuer or Government, including a Government agency or Secretary of State, to add additional users within their account in an embodiment of the present approach. Step S701 starts with the Government Administrator being logged into their account. Step S702 describes the Administrator having the ability to create, for example, a user account with appropriate permission levels for a Government employee and completes personal information profile that may include the employee’s name, government email, position, government phone number. Step S703 describes the event of sending a URL to the employee which allows, S704, the employee to create an account which may include username and password. Step S705 describes the ability for the government employee to enter their login credentials to the platform.

[0091] Fig. 8 illustrates a menu available to a Government account, and in particular a Secretary of State, according to an embodiment of the present approach. Step S801 provides the Government with a link to view the current on-line orders that may have been placed by, for example, a Customer, such as an Individual, an Agent, or an Organization. Step S802 provides the Government with a link to view the current on-line orders that that have been submitted by, for example, a Customer, such as an Individual, an Agent, or an Organization. Step S803 provides the Government with the ability to rescind and cancel an order. Step S804 provides the Government with the ability to place an order on the behalf of a Customer, such as an Individual, an Agent, or an Organization. Step S805 provides the Government with a link to a signature database that stores the signatures, for example, of Government Officials, and Notaries. Said signature database may, for example, be hosted by the Government, or a third party such as a Publisher. Advantageously, the signature database host may have the information technology infrastructure, assets and security to effectively maintain a signature database for one or more Competent Authorities. ThisDocket 6819-0058 advantage is especially beneficial for Competent Authorities that do not have the capability, budget, and / or mandate to operate the information technology infrastructure needed to support the services described herein. Step S804 provides the Government with the ability to maintain stored signatures, by, for example, archiving signatures no longer valid, or whose terms may have ended. Step S806 provides other Government agencies the ability to share records, or documents that are helpful to each other. In this example, it allows a Vital Record, from the Vital Records Office, that may have been ordered by a Customer, such as an Individual to share with the Secretary of State to Apostille. Step S807 provides the Government to control the permissions users have within their agency.

[0092] Fig. 9 shows a process for generating an electronic Apostille according to an embodiment of the present approach. Step S901 describes the Government entering an Apostille order manually, should, for example, the Customer visit the Government counter with a paper, underlying document, and wishes to order an Apostille. Step S902 describes the Government inspecting the underlying document to ensure it meets the necessary requirements, for example the correct signatures and quality of print. Step S903 describes the Government entering, for example, the Customers information, which may include the Customers full name, address, phone number, email, drivers license number, social security number. Step S904 describes the service requested by the Customer. Steps S905-S908 match those of S604-S608 as described in Fig.6. Steps S909-S914 match those of S610-S614 as described in Fig.6.

[0093] Fig. 10 shows a procedure for processing an order and generating an Apostille according to an embodiment of the present approach. Step S1001-S1002 starts with the Government reviewing orders submitted through the on-line platform from, for example the Customer - Individual, Agent, Organization. The format allows the Government to sort ordersDocket 6819-0058 using filters that may include service type, record type, entity type and entity rating. Entity rating is an example of how the Government could associate a rating, based on the accuracy and the past correctness of orders submitted by, for example, the Customer - Individual, Agent or Organization. Step S1003 describes the event of the Government viewing the underlying document such that, for example, the quality, document type, and accuracy of the underlying document is established. Step S1004 describes the Government either accepting or rejecting the underlying document, if rejected, S1005, would generate a list of preloaded and common rejection reasons which is then communicated to, for example, the Customer via the preferred method of communication agreed upon by, for example the Customer, when the account was created as described above. Order status may be updated based on the rejection, for example, “pending”, or “additional information requested”. Step S1006 describes the Government reviewing the signature of the underlying document and needing to compare against the Notary or Official signatures held in the Signature Database, Fig. 11. This is often a required step for issuing an apostille in paper format, and advantageously the present approach permits the Competent Authority to complete the step electronically, instead of resorting to physical copies of official signatures. It should be appreciated that in some embodiments, the signature verification may be automated. For example, a Competent Authority may not need to verify the signature if, for example, a Government Agency, approved by the Competent Authority, submits a Government Record through the platform and the Competent Authority having explicit knowledge of the Government Agency, its relationship with the platform, and of the official signature of the Government Record, has been previously conveyed to the Competent Authority. Step S1007 describes acceptance of the signature, such that the data associated with the signature prepopulates the necessary fields required by the Government Record, for example Apostille, that is procured from either the data as it relates to the NotaryDocket 6819-0058 signature, or the Government official signature that signed the underlying document. Said attributes may include, but is not limited to, the Notary’s name, County Registered, or the County Clerks name and County Registered. Step S1008 describes the format that, for example, the Customer, has requested in the order of the Government Record, which may be paper, or digital. Step S1009 describes the database generating, for example, a unique document number, or Unique Record Locating Number (URLN), or a Quick Response Code (QR Code) which is assigned to the Apostille and may be assigned to each page of the underlying document. S1010 describes the process of creating the Apostille with the underlying documents attached which may be in the format of a PDF. S1011 describes the process of encrypting the Apostille for a digital apostille, for example using a tamper evident software such as Adobe Digital Signing. S1012 describes the ability of the Government to review the Government Record prior to its issuance in either paper or digital format. Step S1013 describes the Apostille PDF and associated data being stored in a database. Step S1014 describes an email notification being sent to the Receiving Entity, S1015, if specified by the Customer, Individual, Agent, Organization, for example, with a copy being sent to the account that initiated the order.

[0094] Fig. 11 illustrates a demonstrative process confirming the signature of a Government Record for generating an Apostille, according to an embodiment of the present approach. Embodiments of the present approach may utilize such a process to generate an Apostille properly signed by the appropriate designee. Step S1101 describes the Competent Authority, in this example a Government, selecting the signature type based on the underlying document being a public document issued by the same Government, or whether the signature to be confirmed is that of a Notary. Step S1102 describes the Government entering the attributes of the signee, that may include the first name, last name, the Notary’s identification number, Clerk IdentificationDocket 6819-0058 Number, County and searching the database S1103. Step S1104 describes the results of the database search. Step S1105 describes whether a match was found and if not, S1106, the Government may choose to request additional information, which may include a signature request from another Government agency, or a rejection to, for example, the Customer, who has to upload the underlying document with an updated signature. Step S1107 describes the Government selecting the signature matching the search attributes which may show an image of the signature, and may also include details of their commission and other associated details, S1108. Step S1109 describes the Government verifying the authenticity of the signature, which may involve verifying the term of the Notary, or by comparing the signature in the database, S1103, against the appropriate signature in the underlying document. Step S1110 describes whether the Government can accept the signature and transfer the signature details to the Apostille S1111 or reject the Apostille request S1112.

[0095] Fig. 12 shows a process for maintaining a signature database according to an embodiment of the present approach. Step S1201 describes the Government adding a signature to the signature database, requesting a signature from another Government Agency, for example Vital Records or verifying a Notary signature against a database. Step S1202 describes the Government having an electronic file of a signature that may have been sent to them electronically, or that the Government scanned from paper to create the electronic file. Step S1203 describes the Government entering the signature attributes into the platform, that may include the full name of the signee, title, term, county or assigned identification number. Step 1204 describes the Government saving the electronic file of the signature and associated signature attributes to the database described in Fig 11. Step S1205 describes the Government requesting a signature from the appropriate Government Agency, for example Vital Records, or the General CourtDocket 6819-0058 Administration. Step S1206 describes the Government detailing the signature attributes for the Government Agency to best identify the signature the Government is requesting. Step S1207 describes the Government submitting the request to the appropriate Agency. Step S1208 describes the Government reviewing a signature uploaded to the platform by a Notary, as described Fig.3. Step S1209 describes the Government verifying the signature and commission of the Notary against another database, Step S1210 describes the Government accepting the Notary signature and commission and approving the signature for future use in the platform database. Step S1212 describes the Government rejecting the signature and communicating to the Notary the reason for rejection through the preferred form of communication specified by the Notary when their account was created.

[0096] Fig. 13 shows a process for rescinding a Government Record, for example an Apostille such that the Government Record may no longer be validated or downloaded by the Customer – Individual, Agent or Organization. S1301 describes the Government locating the order and associated Government Record that must be rescinded. S1302 describes the Government finding the record, selecting and reviewing. S1303 describes the Government initiating a rescind and S1304 requesting the Government confirm the rescind. S1305 removes the Government Record, such an a Apostille, from the database. S1306 provides the Government the ability to reissue the Government Record, S1307-S1308, notifying the Customer, S1309, or cancel the order, S1310 and notify the Customer S1311.

[0097] Fig.14 shows a process of a Government Agency sharing a Government Record with another Government Agency so that it may, for example, and in this embodiment be Apostilled. Step S1401 describes the event of a Government Agency, such as The Office of Vital Records, sharing a Government Record, such as a Birth Certificate with another GovernmentDocket 6819-0058 Agency, such as the Secretary of State (SOS), for an Apostille of the Birth Certificate. S1402 describes the receiving Government Agency reviewing the shared Government Record and verifying the information is sufficient to process an Apostille. Step S1403 describes an event whereby the Government cannot process the request and the Customer, for example, is notified electronically, or through the preferred method as indicated in the order. Step S1404 describes the event whereby the Government can process with further steps being described in Fig.10 S1003.

[0098] Fig.15 illustrates a process for transmitting a Government Record with Apostille according to an embodiment of the present approach. Step S1501 describes a communication, for example an electronic communication, such as electronic mail, being sent to the Receiving Entity, and notifying the Receiving Entity of a Government Record, which they may have requested, is available for them to download. Said communication may include the name of the Customer, a URL embedded with a document number, or URLN as previously described Fig.10, S1009 that allows the Receiving Entity to visit the domain, an administrative structure for organizing, delivering, and accessing services on the internet, delivering the URLN to the issuing Government. Step S1502-S1503 describes the events should the Receiving Entity not initiate a validation within a period of time, which initiates another electronic communication to the Receiving Entity, S1501. Step S1504 describes the instructions for the Receiving Entity to manually navigate to the Government Agency e-Register and manually enter the URLN. Step S1505 describes the Government receiving the URLN from the electronic communication initiated by the Receiving Entity. Step S1506-S1507 describes the event of the Receiving Entity being sent to a third-party domain while the URLN is verified against a third-party database and the existence of a Government Record associated with the URLN. Step S1508 describes an event where the URLN and associated Government Record is not found in the third-party database, and the Receiving Entity is asked toDocket 6819-0058 contact the Government. Step S1509 describes an event where the URLN is found, and the third- party database responds with information. Said information, in this embodiment, may include Customer name, date and state of issuance, underlying document type, and official signature. Step S1510 describes an event where the Government Record can be downloaded to the Receiving Entity through a process of multi-factor authentication. Steps S1511-S1512, describe an event of sending an electronic communication to the Receiving Entity associated with the Customer Order, an electronic code, or a URL, for example, which can be entered at the domain of the third-party to authenticate the Receiving Entity as the valid recipient associated with the Customer Order. Step S1513 describes an event where the correct code is entered, and the Government Record is made available for the Receiving Entity to download. Step S1514 describes an event where the code does not match, and the Receiving Entity is not presented with the Government Documents for download. Step S1515 describes the event that the Customer is notified by electronic means, that the Government Records has been downloaded.

[0099] Fig.1 shows a sample electronic format Apostille (an “e-Apostille”) generated by an embodiment of the present approach. As can be seen, this example includes multiple security features, such as disruptive filaments that hinder alterations to the underlying information, micro printing, a three-dimensional seal, an Apostille number interwoven behind disruptive filaments, a multi-color signature by the Government official interwoven behind disruptive filaments. This embodiment also illustrates a verification portion, including a verification number and website, identity of the Underlying Document (e.g., a “POA” or power of attorney), and an explanation of the same.

[0100] Figs.16A and 16B show a sample verification web page or validation portal of an electronic format Apostille generated by an embodiment of the present approach, and a sampleDocket 6819-0058 Verification in Process response, respectively. Fig.16A is a sample validation portal on, e.g., the Competent Authority’s web domain 1601. The Validating Entity would access the Competent Authority’s web domain 1601 through, in some embodiments, a URL made available on the apostille document after verifying the apostille document’s security layer 1605, and then enter the Verification Number 1603 where prompted on the Competent Authority’s web domain 1601. It should be appreciated that the directions for accessing a validation portal may be provided to the Validating Entity via other means readily available in the art including, for example, email and other messaging services, website publication, and the like. It should also be appreciated that a central Publisher may provide the validation portal, or generate the validation portal for the Issuer to host. For example, the Publisher may provide a website validation portal that the Issuer links to, so that the Validating Entity knows the Publisher’s validation portal is properly affiliated with the Issuer. In such embodiments, the Publisher’s validation portal may display the validation response for the Receiving Entity. As another example, Publisher may provide the back-end validation services through the Issuer’s validation portal, so that the Validating Entity interacts with only the Issuer’s validation portal. It should be appreciated that the Issuer’s validation portal may be in communication with a publisher database that performs the validation services described herein and provides a validation response for display to the Validating Entity through the Issuer’s validation portal, or the display may be provided at the publisher’s portal. In such embodiments, the Validating Entity has an enhanced level of confidence in the results because the validation request was submitted by the Validating Entity directly to the Issuer (through the validation portal), and due to the involvement of the issuer, any validation response, whether displayed by the issuer or by the publisher has enhanced assurance of validity. Fig.16B illustrates an example of a verification process in which the validation portal receives the Verification Number 1603 or other Unique Record LocatingDocket 6819-0058 Number, and then transmits S1611 the originating validation portal URL and URLN to the Publisher’s domain for inquiry S1613 into the Publisher’s database. The interface available to the Validating Entity may include, e.g., the Issuer’s seal or emblem 1615 and the Publisher’s trademark or logo 1617 to increase the Validating Entity’s confidence in the authenticity of the validation response.

[0101] In some embodiments, the Issuer (e.g., Government or other Competent Authority, such as a government agency tasked with verifying Government Records) provides a validation portal in the form of a web page for credential verification. The web page includes steps for a Validating Entity to follow, including verifying the digital signature, validity verification using an Apostille verification number and / or uploading the eApostille for comparison with an original eApostille record residing on a database controlled by the Issuer or Competent Authority, and an option to download the official record or Underlying Document.

[0102] If the validation is successful, then the Issuer’s validation service may transmit a validation response through the validation portal to the Validating Entity. Fig.17 illustrates an embodiment of a validation response. Validation response 1701 may include either or both the Issuer’s seal 1703 (e.g., a state seal), and the Publisher’s trademark or logo 1705. It should be appreciated that lawful use of such marks requires the Issuer and Publisher’s authorization. The validation response 1701 may include, for example, confirmation that the Underlying Document represented by the Government Record is valid and may include additional information as described herein. The validation response may be displayed through the Issuer’s validation portal, or through the Publisher’s portal such that the Validating Entity may observe the successful validation response along with any additional information 1707 relating to the credential that the e-Apostille or Government Record desired Validating Entities to receive. In some embodiments, the validationDocket 6819-0058 response may include additional information 1709 pertaining to the Underlying Document. In some embodiments, the validation response and any additional information 1707 may be printed or otherwise retained by the Validating Entity, to generate a validation transactional record or an Audit Trail. In some embodiments, the validation response may include an electronic file, such as a PDF, of the validation transactional record. The validation transactional record may be a certified electronic document, in which a formal document (such as, for example, a validation confirmation prepared using Issuer letterhead) is delivered to the Validating Entity as, e.g., a PDF document with one or more document integrity security features and / or one or more document usage security features as described above. The validating transactional record may include various information to provide a complete audit trail as the case may require. In some embodiments, the Issuer may determine the information included in a validation transactional record. In some embodiments, the Validating Entity may be given a menu of options for the validation transactional record and the information included therein. The Validating Entity may retain the validation transactional record for record keeping purposes and, if necessary, an audit trail. Additional auditing mechanisms may be provided in some embodiments. Auditing mechanisms may include, for example, digitally signed reports and / or files delivered to the Validating Entity containing the validation response and any additional information, an e-mail including the transaction information, or other forms of transactional record keeping. In some embodiments, the Publisher may retain a validation log. The validation log may include information relating to a validation request, such as, for example, the IP address of the Validating Entity, the identity of the Validating Entity (if known), the result of the validation request, and a record of any information provided in the validation response. In some embodiments, the Publisher may provide a validation log to an Issuer or third party, which the Issuer (or third party) may use for purposes such as identifying potential forgeries, and dataDocket 6819-0058 analytics on credentials and the like.

[0103] Embodiments of the present approach may be employed through a system of servers, secure connections, security systems such as firewalls, computer systems, and databases, to connect the credentialing system to external and internal sources that are required to maintain, deliver, and validate eApostilles and other Government Records.

[0104] Electronic communications may be, for example, a file uploaded via a website or uploaded securely to the Publisher, a direct database transfer, a physical storage device, or other means of secure data transportation as are known in the art.

[0105] Databases may be protected behind a secure firewall, stored offline or offsite, and / or using a form of encryption, as are known in the art. The Authenticating Information may include various combinations of document identifiers, such as a URLN, personal information as it relates to the Recipient, and credential information, as set forth above.

[0106] It should be apparent to one of ordinary skill that systems for implementing the present approach may vary depending on the particular embodiment, and that this disclosure is not intended to be limited to the embodiments described herein.

[0107] As can be seen in the embodiments described above, validation of an e-Apostille and / or Government Record in ways that involve the Issuer, within the vantage of the Validating Entity, as a visible part of the validation process, and in particular as the Validating Entity’s gateway for validation, provides an advantageously high level of confidence that the eApostille or Government Record is valid and authentic. Indeed, third party validation services that do not start with, or involve the Issuer fail to achieve anywhere near a similar level of Validating Entity confidence.

[0108] Embodiments of the present approach may also be configured to display AdditionalDocket 6819-0058 Information. It should be understood that “Additional Information” as used herein may comprise of accompanying information to the Government Record, for example, an application for a work visa of which the Apostille is a part. It should be appreciated that Additional Information could be any data that better helps identify or allow for the processing of a Government Record by the Validating Entity. Such data may include additional Personal Identifying Information (PII) that may be required and is not present in the Government Document. It should also be appreciated that due to the enhanced confidence from including the issuer in the validating request that Additional Information may be shared and accepted by the Validating Entity without the need for a Government Record, or any other type of record.

[0109] As will be appreciated by one of skill in the art, aspects or portions of the present approach may be embodied as a method, system, and at least in part, on a computer readable medium. Accordingly, the present approach may take the form of combination of hardware and software embodiments (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, the present approach may take the form of a computer program product on a computer readable medium having computer-usable program code embodied in the medium. The present approach might also take the form of a combination of such a computer program product with one or more devices, such as a modular sensor brick, systems relating to communications, control, an integrate remote control component, etc.

[0110] Any suitable non-transient computer readable medium may be utilized. The computer-usable or computer-readable medium may be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium. More specific examples (a non-exhaustive list) of the non-Docket 6819-0058 transient computer-readable medium would include the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a device accessed via a network, such as the Internet or an intranet, or a magnetic storage device. Note that the computer-usable or computer-readable medium could even be paper or another suitable medium upon which the program is printed, as the program can be electronically captured, via, for instance, optical scanning of the paper or other medium, then compiled, interpreted, or otherwise processed in a suitable manner, if necessary, and then stored in a computer memory. In the context of this document, a computer-usable or computer-readable medium may be any non-transient medium that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.

[0111] Computer program code for carrying out operations of the present approach may be written in an object oriented programming language such as Java, C++, etc. However, the computer program code for carrying out operations of the present approach may also be written in conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user’s computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user’s computer through a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

[0112] The present approach is described below with reference to flowchart illustrationsDocket 6819-0058 and / or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the approach. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general-purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0113] These computer program instructions may also be stored in a non-transient computer-readable memory, including a networked or cloud accessible memory, that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function / act specified in the flowchart and / or block diagram block or blocks.

[0114] The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to specially configure it to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0115] Any prompts associated with the present approach may be presented and responded to via a graphical user interface (GUI) presented on the display of the mobile communicationsDocket 6819-0058 device or the like. Prompts may also be audible, vibrating, etc. Any flowcharts and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present approach. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and / or flowchart illustration, and combinations of blocks in the block diagrams and / or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

[0116] The terminology used herein is for describing particular embodiments only and is not intended to be limiting of the approach. As used herein, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and / or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0117] The invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. The present embodiments are therefore to be considered in all respects as illustrative and not restrictive, the scope of the invention being indicated by theDocket 6819-0058 claims of the application rather than by the foregoing description, and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein.

Claims

Docket 6819-0058 CLAIMS What is claimed is:

1. An electronically implemented system for generating an electronic apostille for an underlying document, the system comprising: a notary signature database having a plurality of electronic signature representations of notary signatures, each electronic signature representation of a notary signature corresponding to a unique known notary; a public official signature database, a plurality of electronic signature representations of public official signatures, each electronic signature representation of a public official signature corresponding to a unique known public official authorized by a competent authority to sign the underlying document; an underlying document receipt interface configured to receive proffered underlying document submissions from a first requesting entity, each proffered underlying document submission associated with a unique underlying document and including a first proffered signature and a document type, the document type identifying the proffered signature as a notary signature or a public official signature; an electronic apostille format database comprising at least one electronic apostille document format having a fields for receiving apostille information, underlying document information, and at least one digital security feature; a generated electronic apostille database comprising a plurality of generated apostille records, each generated apostille record corresponding to a generated apostille and having information associated with the generated apostille; and an electronic apostille generation computer configured to receive a proffered underlyingDocket 6819-0058 document submission from a first requesting entity through the underlying document receipt interface, compare the first proffered signature with signatures in at least one of the notary signature database and the public official database, and either (1) reject the proffered signature as invalid, or (2) validate the proffered signature select, generate an electronic apostille for the first underlying document using an electronic apostille document format from the electronic apostille format database, and generate a generated apostille record for storage in the generated electronic apostille database.

2. The system of claim 1, wherein the document type further comprises information describing the proffered signature.

3. The system of claim 1, wherein the at least one digital security feature is at least one of disruptive filaments, a digital certificate ribbon, a three-dimensional competent authority seal, a multi-colored signature woven into disruptive filaments, micro-printing, and a document number.

4. The system of claim 1, wherein the at least one electronic apostille document format further comprises a description of the at least one digital security feature.

5. The system of claim 1, wherein the at least one electronic apostille document format further comprises an instruction for verifying at least one of an issued electronic apostille and an underlying document.Docket 6819-0058 6. The system of claim 1, wherein the electronic apostille format database further comprises a plurality of competent authority seals and at least one electronic apostille document format includes a field for receiving a competent authority seal.

7. The system of claim 1, further comprising an electronic apostille validation request interface configured to receive electronic apostille validation requests and proffered authentication information from a first validating entity, and having a computer processor configured to identify a generated apostille record corresponding to the proffered authentication information, and generate an apostille validation response based on the identified generated apostille record.

8. The system of claim 7, comprising a plurality of electronic apostille validation request interfaces, wherein each electronic apostille validation request interface is uniquely associated with a competent authority selected from a plurality of competent authorities.

9. The system of claim 7, wherein the identified generated apostille record is associated with a first competent authority, and the electronic apostille validation request interface is configured to transmit the generated apostille validation response to at least one of the first competent authority, the first requesting entity, and the first validating entity.

10. The system of claim 1, wherein the electronic apostille generation computer is further configured to issue a rejection indication in response to rejecting a proffered signature as invalid.Docket 6819-0058 11. The system of claim 7, wherein a proffered underlying document submission further comprises a plurality of personal identifiable information (PII) from the first requesting entity, and the underlying document receipt interface is configured to receive from the first requesting entity a first category of PII for inclusion in an associated generated apostille record.

12. The system of claim of claim 11, wherein the electronic apostille validation request interface is configured to generate an apostille validation response including the first category of PII.

13. An electronically implemented method for generating an electronic apostille for an underlying document, the method comprising: storing, in a notary signature database, a plurality of electronic signature representations of notary signatures, each electronic signature representation of a notary signature corresponding to a unique known notary; storing, in a public official signature database, a plurality of electronic signature representations of public official signatures, each electronic signature representation of a public official signature corresponding to a unique known public official; receiving an electronic apostille request and proffered underlying document from a first requesting entity, the proffered underlying document including a proffered signature and a document type, the document type identifying the proffered signature as a notary signature or a public official signature; selecting one of the notary signature database and the public official signature database based on the document type;Docket 6819-0058 comparing the proffered signature with the selected signature database to confirm the proffered signature corresponds to an electronic signature representation in the selected signature database; generating an apostille request response based on the comparison; and transmitting the apostille request response to the first requesting entity; wherein, upon confirming the proffered signature corresponds to an electronic signature representation in the selected signature database, the apostille request response includes an electronic apostille associated with the underlying document.

14. The method of claim 13, wherein the generating an apostille request response further comprises selecting an electronic apostille document format from an electronic apostille format database having a plurality of electronic apostille document formats, each format having a fields for receiving apostille information, underlying document information, and at least one digital security feature; populating the selected electronic apostille document format with apostille information and underlying document information.

15. The method of claim 13, further comprising storing the proffered underlying document in an underlying document database, and providing access to the proffered underlying document in connection with the electronic apostille.

16. The method of claim 15, wherein a proffered underlying document submission further comprises a plurality of personal identifiable information (PII) from the first requesting entity, and further comprising receiving from the first requesting entity a first category of PII forDocket 6819-0058 inclusion in an associated generated apostille record.

17. The method of claim 16, wherein the apostille request response includes an electronic apostille associated with the underlying document and the first category of PII.

18. The method of claim 13, wherein the electronic apostille includes an apostille verification code, and further comprising: adding the apostille verification code and information corresponding to the electronic apostille to a generated electronic apostille database; and providing access to an electronic apostille validation request interface with the apostille request response, wherein the electronic apostille validation request interface is configured to receive an electronic apostille verification request and proffered apostille verification code from a validating entity, identify the proffered apostille verification code in the electronic apostille database, and transmit an electronic apostille verification response through the electronic apostille verification interface to the validating entity.

19. The method of claim 18, wherein a proffered underlying document submission further comprises a plurality of personal identifiable information (PII) from the first requesting entity, and further comprising receiving from the first requesting entity a first category of PII for inclusion in an associated generated apostille record, and the electronic apostille verification response includes the first category of PII.

20. The method of claim 13, wherein the underlying document is selected from the group consisting of a government record, a background check, a criminal record, a medicalDocket 6819-0058 certificate of good health, a medical license, a passport, a police report, a business filing, an incorporation certificate, an annual report, a vital record, a birth certificate, a death certificate, a marriage certificate, a court record, a title to real property, a title to intangible property, a title to chattels, a recorded title, a recorded conveyance, a license, a separation agreement, a divorce certificate, and an adoption certificate.

Images