ORCHESTRATION LAYER FOR A MULTI-TIER ARCHITECTURE

Abstract

An orchestrated services layer system for a multi-tier architecture is provided. The system may include an electronic signature application programming interface (API) and an electronic signature framework. The API may receive a request for electronic signature relating to a specific transaction. The request may include an identi-authenti object that authenticates and identifies a customer, customer identification data and transaction data. The API may retrieve a template associated with the transaction data. The API may transfer the request, or a portion of the request and the template to a framework. The framework may prepare a document-to-sign by adding personalized customer information to the document, selecting a type of electronic signature and adding signature tags to the document. The framework may return the ready-to-sign document to the API. The API may forward, for signature, the ready-to-sign document to a channel associated with the customer.

Claims

1. A method for providing an orchestrated services layer, the method comprising: receiving authentication and identification information from a customer via a communications channel; creating an identi-authenti object at the communications channel, said identi-authenti object authenticating and identifying the customer; generating a request, said request for transmission through the communications channel, for an electronic signature, said request relating to a specific transaction; requesting identification data relating to the customer, said identification data for use with satisfying the request; receiving the identification data relating to the customer; transmitting data relating to the specific transaction, a set of identification data relating to the customer and the identi-authenti object to the orchestrated services layer; receiving, at an application programming interface included within the orchestrated services layer, data relating to the specific transaction, the set of identification data relating to the customer and the identi-authenti object; identifying, at the application programming interface, a transaction identifier for the specific transaction; transmitting the transaction identifier from the application programming interface to a document services hub; transmitting the transaction identifier from the document services hub to a document services repository; retrieving, from the document services repository, a template appropriate for the transaction identifier; transmitting the template from the document services repository to the document services hub; transmitting the template from document services hub to the application programming interface; transmitting, from the application programming interface to a framework included in the orchestrated services layer, the template, the set of identification data relating to the customer and the identi-authenti object; preparing a document-to-sign at the framework, the preparing comprising: adding the set of identification data of the customer to the document-to-sign; adding signature tags to the document-to-sign; and selecting a type of electronic signature for the document-to-sign; transmitting the document-to-sign from the framework to the application programming interface; transmitting the document-to-sign from the application programming interface to the communications channel; and receiving an electronic signature from the customer at the communications channel, said electronic signature that converts the document-to-sign into a signed document.

2. The method of claim 1, wherein the communications channel is a banking center, mobile application or online application.

3. The method of claim 1, wherein data used to create the identi-authenti object is based on the communications channel.

4. The method of claim 3, wherein the communications channel is a physical banking center, and the identifying includes presenting identification documentation at the banking center.

5. The method of claim 3, wherein the communications channel is a remote communications channel, and the identifying includes entering a username and password.

6. The method of claim 1, wherein the identification information received from the customer and the set of identification data relating to the customer is different data.

7. The method of claim 1, wherein the set of identification data relating to the customer includes at least a portion of the identification information received from the customer.

8. The method of claim 1, further comprising, prior to electronically signing the document-to-sign, acknowledging, by the customer at the communications channel, a file that constitutes a signature.

9. The method of claim 8, wherein the file includes an image or a signature font.

10. The method of claim 1, wherein the type of electronic signature for the document-to-sign is either a technical signature comprising geographic location awareness, a check-the-box signature or an acknowledgement signature.

11. The method of claim 1, further comprising: forwarding a signed document comprising the document-to-sign and the electronic signature from the communications channel to the application programming interface; forwarding the signed document from the application programming interface to the document services hub; forwarding, for storage, the signed document, from the document services hub to the document services repository; and storing the signed document at the document services repository.

12. The method of claim 1, further comprising storing the identi-authenti object with the signed document at the document services repository.

13. An orchestrated services layer system comprising: an electronic signature application programming interface (API); and an electronic signature framework; wherein: the API receives a request from a communications channel, the request for an electronic signature relating to a specific transaction, the request comprising: an identi-authenti object that authenticates and identifies a customer; a set of identification data relating to the customer; and a set of data relating to the specific transaction; the API identifies a transaction identifier for the specific transaction; the API transmits the transaction identifier to a document services hub in communication with a document services repository; the API receives a template that corresponds to the transaction identifier from the document services hub in communication with the document services repository; the API transfers the template, the set of identification data relating to the customer and identi-authenti object to the framework; to prepare a document-to-sign, the framework: adds, to the template, the set of identification data relating to the customer; adds, to the template, signature tags; selects a type of electronic signature for the document-to-sign, the selection based on the specific transaction and the set of identification data relating to the customer; the framework transfers the document-to-sign to the API; and the API forwards the document-to-sign to the communications channel for electronic signature by the customer.

14. The system of claim 13, wherein: the API receives a signed document, said signed document comprising the document-to-sign and the electronic signature, from the communications channel; and the API forwards the signed document to the document services hub in communication with the document services repository for storage.

15. The system of claim 14, wherein the identi-authenti object is stored with the signed document at the document services repository.

16. The system of claim 13, wherein the type of electronic signature for the document-to-sign is either a technical signature comprising geographic location awareness, a check-the-box signature or a identify acknowledgement signature.

17. An orchestrated services layer system comprising: an electronic signature application programming interface (API); and an electronic signature framework; wherein: the API receives a request from a communications channel, the request for a remote electronic signature relating to a specific transaction, the request comprising: an identi-authenti object that authenticates and identifies a customer; a set of identification data relating to the customer; and a set of data relating to the specific transaction; the API identifies a transaction identifier for the specific transaction; the API transmits the transaction identifier to a document services hub in communication with a document services repository; the API receives a template that corresponds to the transaction identifier from the document services hub in communication with the document services repository; the API transfers the template, the set of identification data relating to the customer and identi-authenti object to the framework; to prepare a document-to-sign, the framework: adds, to the template, the set of identification data relating to the customer; adds, to the template, signature tags; selects a type of electronic signature for the document-to-sign, the selection based on the specific transaction and the set of identification data relating to the customer; the framework transfers the document-to-sign to the API; the API forwards the document-to-sign to the document services hub in communication with the document services repository for storage; and the API instructs the document services hub to transmit a message to a mobile device associated with the customer, the message comprising a link to access the document-to-sign stored in the document services repository.

18. The system of claim 17, wherein: upon signing the document-to-sign on the mobile device, the API receives a signed document, said signed document comprising the document-to-sign and the electronic signature, from the mobile device; and the API forwards the signed document to the document services hub in communication with the document services repository for storage.

19. The system of claim 18, wherein the identi-authenti object is stored with the signed document at the document services repository.

20. The system of claim 17, wherein the type of electronic signature for the document-to-sign is either a technical signature comprising geographic location awareness, a check-the-box signature or a identify acknowledgement signature.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0030] The objects and advantages of the invention will be apparent upon consideration of the following detailed description, taken in conjunction with the accompanying drawings, in which like reference characters refer to like parts throughout, and in which:

[0031] FIG. 1 shows an illustrative diagram in accordance with principles of the disclosure;

[0032] FIG. 2 shows another illustrative diagram in accordance with principles of the disclosure;

[0033] FIG. 3 shows yet another illustrative diagram in accordance with principles of the disclosure;

[0034] FIG. 4 shows still another illustrative diagram in accordance with principles of the disclosure; and

[0035] FIG. 5 shows still yet another illustrative diagram in accordance with principles of the disclosure.

DETAILED DESCRIPTION OF THE DISCLOSURE

[0036] Apparatus, methods and systems for providing an orchestrated services layer is provided. Methods may include receiving authentication and identification information from a customer via a communications channel.

[0037] Methods may include creating an identi-authenti object at the communications channel. The communications channel may be a banking center, mobile application, online application or other suitable communications channel. The identi-authenti object may authenticate and identify the customer. The data used to create the identi-authenti object may be based on the communications channel.

[0038] When the communications channel is a physical banking center, the identifying the customer may include presenting identification documentation at the banking center. When the communications channel is a remote communications channel, the identifying may include entering a username and password.

[0039] Methods may include generating a request for an electronic signature. The request may relate to a specific transaction. The request may be for transmission through the communications channel.

[0040] Methods may include requesting identification data relating to the customer. The identification data may be for use with satisfying the request. Methods may include receiving the identification data relating to the customer. The identification data relating to the customer may be different from the identification information received from the customer. The identification data relating to the customer may include at least a portion of the identification information received from the customer.

[0041] Methods may include transmitting data relating to the specific transaction, a set of identification data relating to the customer and the identi-authenti object to the orchestrated services layer.

[0042] Methods may include receiving, at an API included in the orchestrated services layer, data relating to the specific transaction, the set of identification data relating the customer and the identi-authenti object.

[0043] Methods may include identifying, at the API, a transaction identifier for the specific transaction. Methods may include transmitting the transaction identifier from the API to a document services hub.

[0044] Methods may include transmitting the transaction identifier from the document services hub to a document services repository. Methods may include retrieving, from the document services repository, a template appropriate for the transaction identifier.

[0045] Methods may include transmitting the template from the document services repository to the document services hub. Methods may include transmitting the template from the document services hub to the API.

[0046] Methods may include transmitting, from the API to a framework included in the orchestrated services layer, the template, the set of identification data relating to the customer and the identi-authenti object.

[0047] Methods may include preparing a document-to-sign at the framework. The preparing may include adding the set of identification data of the customer to the document-to-sign. The preparing may include adding signature tags to the document-to-sign. The preparing may include selecting a type of electronic signature for the document-to-sign. The type of electronic signature may be a technical signature comprising geographic location awareness. The type of electronic signature may be a check-the-box signature. The type of electronic signature may be an acknowledgement signature. The type of electronic signature may include a combination of various types of electronic signatures. The type of signature selected may be based both on the document and the signer.

[0048] Methods may include transmitting the document-to-sign from the framework to the API. Methods may include transmitting the document-to-sign from the API to the communications channel. Methods may include receiving an electronic signature from the customer at the communications channel.

[0049] Methods may include, prior to electronically signing the document-to-sign, acknowledging, by the customer at the communications channel, a file that constitutes a signature. The file may include an image or a signature font.

[0050] Methods may include forwarding a signed document to the API. The signed document may include the document-to-sign and the electronic signature.

[0051] Methods may include forwarding the signed document from the API to the document services hub. Methods may include forwarding, for storage, the signed document, from the document services hub to the document services repository. Methods may include storing the signed document at the document services repository.

[0052] At times, the identi-authenti object and the signed document may be stored at the document services repository.

[0053] Apparatus and methods described herein are illustrative. Apparatus and methods in accordance with this disclosure will now be described in connection with the figures, which form a part hereof. The figures show illustrative features of apparatus and method steps in accordance with the principles of this disclosure. It is to be understood that other embodiments may be utilized and that structural, functional and procedural modifications may be made without departing from the scope and spirit of the present disclosure.

[0054] The steps of methods may be performed in an order other than the order shown or described herein. Embodiments may omit steps shown or described in connection with illustrative methods. Embodiments may include steps that are neither shown nor described in connection with illustrative methods.

[0055] Illustrative method steps may be combined. For example, an illustrative method may include steps shown in connection with another illustrative method.

[0056] Apparatus may omit features shown or described in connection with illustrative apparatus. Embodiments may include features that are neither shown nor described in connection with the illustrative apparatus. Features of illustrative apparatus may be combined. For example, an illustrative embodiment may include features shown in connection with another illustrative embodiment.

[0057] FIG. 1 shows an illustrative diagram. Customer 107 may be associated with mobile device 108. Customer 107 may want to sign a document. The document may be part of one of a variety of processes. Such processes may include becoming involved in a business relationship (contract administration), opening an account or any other suitable processes.

[0058] In order to enable customer 107 to sign a document, customer 107 may be required to identify and authenticate itself (shown at 104). The identification and authentication process may create an identi-authenti object. Authentication may involve authenticating via an identifier, one-time password (OTP) and/or login credentials, as shown at 106. Additional considerations may involve biometric (finger or face), any mark, font or symbol, image, etc., or voice print. Biometrics, such as finger or face, any mark, font or symbol, image, etc. or voice print may be used to authenticate customer 107.

[0059] An identi-authenti object may be created once customer 107 is identified and authenticated. The identi-authenti object may prove that the customer has been both identified and authenticated. The identi-authenti object may be used continuously and/or consistently throughout the process, so there is no need for re-identification and/or re-authentication at a later point in the process.

[0060] The identification and authentication may occur at a plurality of channels. One channel may be banking or financial center, as shown at 110. Another channel may be an online banking module. Yet another channel may be an automated teller machine. It should be noted that any suitable channel may interface with the orchestration layer.

[0061] The channel may transmit a signature request to electronic signature orchestration services 124. The signature request may include information relating to the authentication. The signature request may include information relating to the signer. The information relating to the signer may be referred to as metadata. The metadata may include the signer's name and address as well as any other suitable information. The metadata may also include information relating to what the signer has acknowledged as its signature, as shown at 102. For example, if the signer is using a particular signature font, if the signer is using an object, or if the signer is using a picture. The metadata relating to what the signer has acknowledged as its signature can be retrieved at each signing ceremony or it can be acknowledged a single time and stored for future use. In the event that the metadata is stored, the system may generate an audit log. The audit log may include information as to what the user acknowledged as its signature. Each time the user utilizes the signature, the information relating to the specific signing may be added to the audit log. As such, the audit log may be updated each time the user utilizes the stored signature.

[0062] The identi-authenti object as well as what the user acknowledged as its signature may be stored in electronic signature database 136. Electronic signature database 136 may be used to register electronic signature session, as shown at 148. Electronic signature database 136 may also be used to connect the signature acknowledgement with the identi-authenti object. Electronic signature database 136 may also store the audit log and the unencrypted document hash value. The updates to the status or state of the audit log may also be stored at electronic signature database 136.

[0063] The signature request may also include information relating to the document to be signed. The signature request may also include the identi-authenti object.

[0064] Electronic signature orchestrated services 124 may include both electronic signature application programming interface (API) 126 and electronic signature framework 128. Electronic signature API 126 may decide based on a series of coded aspects, such as lookup table, as to what type of signature is required for the current use case. Upon the decisioning, electronic signature API 126 may return to the calling application, a list of required data elements. The data elements may include metadata relating to the signer.

[0065] Once the data elements are received, electronic signature API 126 may communicate with electronic signature framework 128. Electronic signature framework 128 may include a utility for document creation. In certain embodiments, the utility for document creation may utilize at least three elements to create the document, the first element may include a template identifier, the second element may include data relating to the signer and the third element may include signature tags to be placed on the document. Each of the three elements may be orchestrated as one call, as shown at 134.

[0066] It should be noted that the request from the channel to the orchestrated services layer may include a template identifier and/or data to prefill onto the document, as shown at 130. Electronic signature framework 128 may align documents (such as, for example, portable document formats (PDFs)) with signature tags and prefill data, as shown at 132.

[0067] Upon receipt of a request for document, electronic signature API 126 may retrieve a template from document content and record services 116. The template may correspond to a template identifier received from the channel. The template may refer to a specific document, such as a loan contract. Document content and record services 116 may be a document storage and retrieval system. Document content and record services 116 may include various applications. The applications may include document management technology services 118, content services layer 120, and capture, ingestion and indexing services 122.

[0068] Document content and record services 116 may communicate with document content and record repositories 140 to retrieve the document template. Document content and record repositories 140 may include one or more applications: enterprise content management 142, global content archive 144 and work in progress for enterprise content management 146. It should be noted, as shown at 138, that document templates may be stored by one or more entities, or sub-entities, within the repository, prior to initialization of a signature request.

[0069] Because the orchestration layer serves multiple channels, there may be different process flows for each of the channels. A first process flow may involve a customer at a banking center. A second process flow may involve a customer using an online or mobile application.

[0070] When a signature request is initiated at a banking center, such as in the first process flow. A customer may be currently at the center. The template may be retrieved from the repository and forwarded from document content and record services 116 to electronic signature orchestration services 124. Electronic signature orchestration services 124 may forward the template to electronic signature framework 128 for document preparation, including personalizing the document using the received metadata and adding signature tags. Electronic signature framework 128 may forward the ready-to-sign document back to the electronic signature API 126. Electronic signature API 126 may forward the ready-to-sign document to the channel, as shown at 110. Customer 107 may provide an electronic signature at an electronic device within the channel. The signed document may be forward from channel 110 to electronic signature API 126, to capture, ingestion and indexing services 122 within document content and record services 116. Capture, ingestion and indexing services 122 may forward to signed documents to be stored within document content and record repositories 140.

[0071] When a signature request is initiated with a remote customer, such as one that is associated with mobile device 108, the doc-to-sign is stored at document content and record repositories 140 simultaneous to being transmitted to the customer. As such, when the customer decides to open the electronic signature notification, the system retrieves the doc-to-sign from document content and record repositories 140 and presents the document to the customer.

[0072] Additionally, events may be used to notify the sub-entity involved in the signing document. For example, when the document is ready to be signed, messaging integration engine 114, may generate the event, as the document ready to be signed event. Messaging integration engine 114 may be a message queue events handler.

[0073] An event may be generated when the uniform resource locator (URL) or short message service (SMS) is transmitted from customer notification engine 112 to the customer's device. The electronic signature API 126 may also generate an event when the customer signs the document. Each of these events may be reported to the sub-entity involved in the signing of the document.

[0074] FIG. 2 shows an illustrative diagram. The illustrative diagram shows requests and responses within customer identification and authentication, document-to-sign preparation and presentation of document-to-sign to customer processes. The illustrative diagram shows communications between customer 202, channel 204, orchestrated services layerAPI 206, orchestrated services layerframework 208, document content and record services 210 and document content and record repositories 212.

[0075] Customer 202 may identify and authenticate at channel 204, as shown at 214. Customer 202 may initiate a transaction that involves an electronic signature, as shown at 216.

[0076] Channel 204 may identify a transaction type, as shown at 218. A document identifier may identify the transaction type. Channel 204 may request a document and an electronic signature from the API at orchestrated services layer 206.

[0077] The API at orchestrated services layer 206 may request, from document content and record services 210, a template that corresponds to the identified transaction type, as shown at 222.

[0078] Document content and record services 210 may retrieve a template from document content and record repositories 212, as shown at 224. Document content and record repositories 212 may return a template to document content and record services, as shown at 226.

[0079] Document content and record services 210 may return the template to the API at orchestrated services layer 206, as shown at 228.

[0080] The API at orchestrated services layer 206 may request a document from the framework at orchestrated services layer 208, as shown at 230. The framework at orchestrated services layer 208 may create a document with customer prefilled metadata and add signature tags, as shown at 232.

[0081] The framework at orchestrated services layer 208 may return a ready-to-sign document to the API at orchestrated services layer 206, as shown at 234. Orchestrated services layer 206 may return the ready-to-sign document to channel 204, as shown at 236. Channel 204 may present the ready-to-sign document to customer 202, as shown at 238.

[0082] FIG. 3 shows an illustrative diagram. The illustrative diagram shows requests and responses that occur within storing a signed document process. The illustrative diagram shows communications between customer 302, channel 304, orchestrated services layerAPI 306, orchestrated services layerframework 308, document content and record services 310 and document content and record repositories 312.

[0083] Customer 302 may sign a document at channel 304, as shown at 314. Channel 304 may forward the document-to-be-stored to the API at orchestrated services layer 306, as shown at 316. API at orchestrated services layer 306 may forward the document-to-be-stored to document content and record services 310, as shown at 318. Document content and record services 310 may store the signed document at document content and record repositories 312, as shown at 320.

[0084] FIG. 4 shows an illustrative diagram. The illustrative diagram shows requests and responses that may occur within storing a document-to-be-signed for remote signing process and retrieving the document-to-be-signed at the remote signing process. The illustrative diagram shows communications between customer 402, channel 404, orchestrated services layerAPI 406, orchestrated services layerframework 408, document content and record services 410 and document content and record repositories 412.

[0085] Framework at orchestrated services layer 408 may create a ready-to-sign document, as shown at 414. The ready-to-sign document may be returned from framework at orchestrated services layer 408 to API 406, as shown at 416. API 406 may forward the document-to-sign to document content and record services 410 for storage, as shown at 418. Document content and record services 410 may store the document-to-sign at document content and record repositories 412, as shown at 420.

[0086] Document content and record services 410 may notify customer 402 of the document-to-sign via one or more applications, as shown at 422. The one or more applications may include forwarding an SMS or URL to a phone number or email address associated with customer 402.

[0087] Upon opening of the SMS or URL, customer 402 may connect to document content and record services 410 to retrieve the document-to-sign, as shown at 424. Document content and record services 410 may retrieve the document to sign from document content and record repositories 412, as shown at 428. Document content and record repositories 412 may return the document to sign to document content and record services 410, as shown at 430. Document content and record repositories 412 may return the document-to-sign to customer 402, as shown at 426.

[0088] FIG. 5 shows an illustrative diagram. The illustrative diagram shows electronic signature reconciliation. For a specific document identifier, step 502 queries whether the entity attempted to retrieve a signature. When the answer to step 502 is yes, the process proceeds to step 504. When the answer to step 502 is no, the process proceeds to step 510.

[0089] Step 504 queries whether the client signed the document. When the answer to step 504 is yes, the process proceeds to step 506. When the answer to step 504 is no, the process proceeds to step 510.

[0090] Step 506 queries whether the signed document is stored in the entity repository. When the answer to step 506 is the digital process is reconciled, as shown at 508. When the answer to step 506 is no, an identification of the cause of the failure to reconcile is initiated. The identification may involve identifying which step in the process failed and what was the cause of the failure.

[0091] Thus, an orchestration layer for a multi-tier architecture is provided. Persons skilled in the art will appreciate that the present invention can be practiced by other than the described embodiments, which are presented for purposes of illustration rather than of limitation. The present invention is limited only by the claims that follow.