DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
Claims 1, 13 and 17 have been amended and are hereby entered.
Claim 4 was cancelled.
Claims 1 - 3 and 5 - 20 are pending and have been examined.
This action is made FINAL.
Response to Arguments
Applicant's arguments filed February 5, 2026 have been fully considered but they are not persuasive.
Regarding to Applicant's arguments for the 112(b) rejection of pending claims on page 15: Amendments and arguments regarding the 112(b) rejection have been entered and considered. Therefore, this particular rejection has been withdrawn due to Applicant's amendments.
Regarding the Applicant's arguments against the 101 rejection of pending claims on pages 12-15: Applicant’s arguments directed to Step 2A prong 1 and Step 2A prong 2 were considered. However, these arguments are not persuasive and the Examiner respectfully disagrees for the following reasons:
For Step 2A-Prong 1 starting in p. 12: The Applicant argues that the pending claims are not directed to the abstract idea of a mental process identified without pointing out or providing a reason as to how the recited elements are not directed to an abstract idea and/or how the abstract idea is being integrated into a practical application. However, the Examiner finds these arguments unpersuasive and respectfully disagrees. Because the claims are still “reciting” a judicial exception when the judicial exception is “set forth” or “described” in the claim. See MPEP 2106.04, subsection II. The “claims can recite a mental process even if they are claimed as being performed on a computer” while using an API and “an electronic signature framework application” connected to one or more “electronic communications channel” to prepare documents, collect signatures and identify/authenticate users and their identification data via their respective “electronic identi-authenti object(s)”. Because under the “broadest reasonable interpretation of the claim in light of the specification” it was determined that the claimed invention is described as a concept that is performed in the human mind and applicant is merely claiming that concept performed for at least the steps directed in part to “identifies a transaction identifier for the specific transaction”, “to prepare a document-to-sign” by adding “the set of identification data relating to the customer” and “signature tags” and “selects a type of electronic signature for the document-to-sign” and “…identifies and authenticates the customer based only on an electronic match between a first electronic signature and the electronic signature particular stored within the electronic identi-authenti object…” which “is merely using a computer as a tool to perform the concept” that is recited in a high level of generality and merely uses the API and framework application applied in the computer to perform the claimed functions (see MPEP 2106.04(a)(2)(III)(C) and 2106.05 (f)).
Moreover, the claim steps also describes the abstract idea of a certain method of organizing human activity in the forms of “commercial or legal interactions” and “managing personal behavior or relationships or interactions between people” as the steps encompass legal interactions in the form of agreements in the form of contracts and/or legal obligations that are further involving business relations as well as the steps encompass management of interactions between people in the form of following rules or instructions. Thus, these claims and their additional elements, when evaluated, individually and in combination, under the broadest reasonable interpretation and their specification (see MPEP 2111 and 2106.04(II)), were still directed to the abstract idea without reciting significantly more than the judicial exception. Thus, the Examiner respectfully disagrees, and maintains 35 USC § 101 rejection for these pending claims.
Regarding to Applicant's arguments of rejection under 35 USC § 103 for the pending claims on page 16: Applicant’s arguments regarding these amended limitation steps in claim(s) 1, 13 and 17 are not persuasive. Because for new grounds of the claimed invention and the prior art combination of Ross, Peterson and Nassiri reasonably teaches the claim limitations and each element contrary to Applicant’s unfounded/general allegations. Thus, Applicant's arguments fail to comply with 37 CFR 1.111(b) because they amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the Ross, Peterson and Nassiri references. Please, refer to the Claim Rejections - 35 USC § 103 section for further details. Therefore, the Examiner respectfully disagrees, and maintains 35 USC § 103 rejection for these pending claims.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1 - 3 and 5 - 20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The analysis of this claimed invention recited in the claims begins in view of independent claim 13, the most representative claim of the independent claims set 1, 13 and 17, as follows:
At Step 1: Claims 1 – 3 and claims 5 – 12 are directed to a method that fall under statutory category of a process, while claims 13 – 16 and claims 17 - 20 are directed to a system considered a machine.
At Step 2A Prong 1: Claim 13 (representative of claim 1 and 17) recites an abstract idea in the following limitations:
…operable to create and prepare documents…
wherein: …receives a request…the request for an electronic signature relating to a specific transaction, the request comprising:
an electronic identi-authenti object comprising metadata relating to the customer, said metadata comprising customer name, customer address, customer telephone number, customer biometric data and customer voice print, said metadata that authenticates and identifies a customer;
identification documentation relating to the customer, the identification documentation comprising one or more of a passport, driver's license, marriage license and social security card;
electronic login data comprising:
a username; a password; and a one-time password;
one or more electronic interactions with the customer, the one or more electronic interactions comprising:
a question transmitted…; and
a correct response received…associated with the customer; and an electronic acknowledgement of an electronic signature particular, said electronic signature particular being a predetermined signature font, a picture or an object;
a set of identification data relating to the customer; and a set of data relating to the specific transaction;
a set of identification data relating to the customer; and a set of data relating to the specific transaction;
…stores the electronic identi-authenti object…;
…identifies a transaction identifier for the specific transaction;
…transmits the transaction identifier…;
…receives a template that corresponds to the transaction identifier…;
…transfers the template, the set of identification data relating to the customer and electronic identi-authenti object…;
to prepare a document-to-sign…:
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;
…transfers the document-to-sign…
…forwards the document-to-sign…for electronic signature by the customers
…identifies and authenticates the customer based only on an electronic match between a first electronic signature and the electronic signature particular stored within the electronic identi-authenti object, from the customer…, said first electronic signature that converts the document-to-sign into a signed document;
…updates a data log associated with the electronic identi-authenti object to indicate that the electronic identi-authenti object was used in a first instance for identification and authentication;
…receives a second electronic signature, said second electronic signature identifying and authenticating the customer based only on an electronic match between a second electronic signature and the electronic signature particular stored within the electronic identi- authenti object, from the customer…, said second electronic signature that converts a second document-to-sign into a signed document; and
…updates the data log associated with the electronic identi-authenti object to indicate that the electronic identi-authenti object was used in a second instance for identification and authentication.
Generally, the claims describe a system and a method for authenticating customers prior to signing agreements and requesting authentication information and electronic signatures, populating agreements based on received information, receiving electronic signatures, and transmitting the collected data to a computer system for updates. As disclosed in the specification in ¶0007, this claimed invention provides “an orchestration services layer” that “serves as a centralized device or box that receives electronic signature calls (also referred to herein as requests) from a plurality of clients” such as “financial centers, mobile applications, online applications and/or any other suitable clients”. However, the abstract idea(s) of a certain method of organizing human activity (See MPEP 2106.04(a)(2), subsection II) is recited in claim 13 in the form of “commercial or legal interactions” and “managing personal behavior or relationships or interactions between people”. Specifically, the abstract idea is recited in the steps that are directed in part to “an electronic signature framework application operable to create and prepare documents” wherein a “request for an electronic signature relating to a specific transaction” is received with an “electronic identi-authenti object” that is metadata representative of “identification documentation relating to the customer” such as their personal, identification and electronic login data as well as transmitted questions with received responses. Then, a “transaction identifier” for such requesting transaction is identified and transmitted to receive and “transfer” a template to “prepare a document-to-sign” that add identification data and signature tags that are selected by type and then is “transferred” and “forwarded” to the customer to require their signature while “identifying and authenticating” the customer with the match of a first and second signatures and an “electronic signature particular” to the “electronic identi-authenti object” to finally update the most recent data logged. Thus, these steps are encompassing legal interactions in the form of agreements in the form of contracts and/or legal obligations that are further involving business relations. Similarly, these steps also fall under the abstract idea sub-group of “managing personal behavior or relationships or interactions between people” since updating “data logs” related to the customer signatures while forwarding/transferring the “template” for the customer to sign while “authenticating” the customer with a first signature and a second signature received encompasses the management of interactions between people in the form of following rules or instructions.
The steps directed to “identifies a transaction identifier for the specific transaction”, “to prepare a document-to-sign” by adding “the set of identification data relating to the customer” and “signature tags” and “selects a type of electronic signature for the document-to-sign” and “…identifies and authenticates the customer based only on an electronic match between a first electronic signature and the electronic signature particular stored within the electronic identi-authenti object…” fall under the abstract idea of mental processes that can be practically be performed in the human mind or in pen and paper (See MPEP 2106.04(a)(2), subsection III). Because identifying identification data, preparing a document to be signed by including this data and signature tags and selecting electronic signature types to also identify and authenticate the customer with a first signature matching the particular “electronic signature” based on “identi-authenti objects” encompass observation, evaluation and judgement. Also, these steps can either be done with the help of physical aid such as pen and paper or can be performed by humans without or with the assistance (e.g. tool) a computer. Thus, the steps do not negate and further still reads in the mental nature of the limitation(s), when identifying such identification information, preparing document forms and authenticating the customer with signatures, as well as the concept is merely claimed to be performed on a generic computer and is merely using a computer as a tool to perform the concept of handling transaction requests for preparing legal documents with signatures and provide such legal services (see MPEP 2106.04(a)(2)(III)(B & C)).
At Step 2A Prong 2: For independent claims 1, 13 and 17, The judicial exception(s) or abstract idea previously identified is not integrated into a practical application (see MPEP 2106.04 (d)). The claims recite the additional element(s) of a hardware processor, a hardware memory (from claim 13), an electronic signature application programming interface (API), an electronic signature framework application (from claims 13 and 17), an orchestrated services layer, a mobile device, a framework application, an electronic communications channel, a document services repository, a second electronic communications channel (from claims 1, 13 and 17). These additional elements, individually and in combination, and while considering the claims as a whole, are merely used as a tool to perform the abstract idea (See MPEP 2106.05(f)). Specifically, these steps are recited as being performed by the computer. The computer is recited at a high level of generality that is being used as a tool to perform the generic computer functions for preparing legal documents and collecting signatures in order to fulfill transaction requests. Thus, these steps mentioned above are further describing and applying the abstract idea without placing any limits on how the technological components are being improved, while distinguishing in the claim language, the performing limitations from functions that generic computer components can perform.
Finally, the steps directed in part to “receives…” a request, a template and a second electronic signature, the step of “stores the electronic identi-authenti object”, the steps of “transmit the transaction identifier”, “transfers” the template and the document-to-sign, “forwards the document-to-sign” and the steps of “updates” data log in the representative claim is really nothing more than links to computer for implementing the use of ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general-purpose computer or computer components (refer to MPEP 2106.05 f (2)). Thus, in these limitation steps, the computer is used to perform an abstract idea, as discussed above in Step 2A, Prong One, such that it amounts to no more than mere instructions to apply the exception using a generic computer.
Step 2B: For independent claims 1, 13 and 17, these claims do not provide an inventive concept. The recited additional elements of the claim(s) are the following: a hardware processor, a hardware memory (from claim 13), an electronic signature application programming interface (API), an electronic signature framework application (from claims 13 and 17), an orchestrated services layer, a mobile device, a framework application, an electronic communications channel, a document services repository, a second electronic communications channel (from claims 1, 13 and 17). These additional elements are not sufficient to amount significantly more than the judicial exception or abstract idea (see MPEP 2106.05). Because, as indicated in Step 2A Prong 2, these additional element(s) claimed are merely, instructions to “apply” the abstract ideas, which cannot provide an inventive concept. Also, the recitation of a computer to perform the claim limitations amounts to no more than mere instructions to apply the exception using a generic computer component. Thus, even when considered in combination, these additional elements represent mere instructions to implement an abstract idea or other exception on a computer, which do not provide an inventive concept at Step 2B.
For dependent claims 2-3, 5 -12, 14 - 16 and 18 - 20, the same analysis is incorporated. Due to their dependency to the independent claims analyzed, these claims cover or fall under the same abstract idea(s) of a method of organizing human activity and mental processes. They describe additional limitations steps of:
Claims 2-3, 5 -12, 14 - 16 and 18 - 20: further describes the abstract idea of the method or providing an orchestrated services layer and the type of electronic communications channel is, the basis of the data used to create the electronic identi-authenti object, the relationship and difference between the identification data received from user and retrieved, other processes that occur “prior to electronically signing the document-to-sign”, type of file and electronic signature for the document-to-sign, what “forwarding the signed document” comprised of which is further stored with the “electronic identi-authenti object”. Thus, being directed to the abstract idea groups of “commercial or legal interactions”, “managing personal behavior or relationships or interactions between people” and mental process as it encompasses legal interactions in the form of agreements in the form of contracts and/or legal obligations that are further involving business relations, following rules or instructions and observation, evaluation and judgement, respectively.
Step 2A Prong 2 and Step 2B: For dependent claims 2 and 5, these claims recite the additional elements of: a mobile application or online application (from claim 2) and a remote electronic communications channel (from claim 5). These additional elements recited are invoking computers merely used as a tool to perform or “apply” the abstract idea(s) to the existing process of communicating and transmitting document templates and signatures data as instructions. Thus, amounting to no more than mere instructions to “apply” the exception using a generic computer component (MPEP 2106.05(f) and (f)(2)). Accordingly, for the same reasons stated above, these additional element(s) claimed cannot provide an inventive concept at Step 2B.
Finally, the additional elements previously mentioned above, are nothing more than descriptive language about the elements that define the abstract idea, and these claims remain rejected under 101 as well.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1 - 3 and 5 - 20 are rejected under 35 U.S.C. 103 as being unpatentable over Ross (U.S. Pub No. 20070094510 A1) in view of Peterson (U.S. Pub No. 20110314371 A1) in further view of Nassiri (U.S. Pub No. 20080209516 A1)
Regarding claims 1, 13 and 17:
This independent claim set is represented by claim 13
Ross teaches:
a hardware processor operating in tandem with a hardware memory; (In ¶0018; Fig. 1 (12 and 14); Fig. 2 (42 and 56); Fig. 3 (80 and 82): describes a “general purpose computer 10” that “comprises processor 12, random access memory (RAM) 14, read only memory (ROM) 16”. See ¶0037 for more details for Fig. 3)
an electronic signature application programming interface (API) operating on the hardware processor; and an electronic signature framework application operable to create and prepare documents, said framework application operating on the hardware processor; wherein: (In ¶0024; Fig. 2 (42 and 56); Fig. 3 (92): describes that “computers 56 may include any appropriate application or applications that enable computers 56 to be used in the preparation of and/or execution of transaction documents”. Also, in ¶0057, “processor 80 may enable the creation of transaction documents” via “creation module 92” which “may include word processing tools or other computerized applications that may be used to create transaction documents” and “may include applications that enable creation module 92 to receive transaction documents that are created independently of TMS 42.” See ¶0066 for details of the “execution module 94” recognizing or offering “notary execution services that enable the application of notarization indicia to a transaction document” ¶0092 for more details of other external applications that can be used to download documents.)
the API receives a request from an electronic communications channel, the request for an electronic signature relating to a specific transaction, the request comprising: (In ¶0070 – 71; Fig. 5A (234); Fig. 4 (104 and 114); Fig. 5A (204): describes “the manager of TMS 42, the document creator, or another user responsible for the document may request that the transaction document be exported to the recordation authority” wherein the “recording authority” can be “a government property recordation office” directed to an electronic communications channel, in accordance to the example given in ¶0060 from Applicant disclosure.)
an electronic identi-authenti object comprising; metadata relating to the customer, said metadata comprising customer name, customer address, customer telephone number, customer biometric data and customer voice print, said metadata that authenticates and identifies a customer; (In ¶0045 – 46; Fig. 4 (100): describes that “buyer 52 may be assigned a unique identifier” (i.e. an object) that “identifies buyer 52 as an authorized user of TMS 42” and “may be assigned or may be assigned or may select a user name and a password” (e.g. directed to the different metadata that can be used for the electronic identi-authenti object claimed). But also, “buyer 52 may be prompted to enter his user name and password before buyer 52 is allowed to review transaction documents, electronically execute transaction documents, or obtain other data managed by TMS 42” wherein “user identification methods described above for authenticating a user to TMS 42 may also be used to perform authorization services” that can result in “the assembly of a set of attributes that describe what actions the user is authorized to perform within TMS 42”, in accordance to the example given in ¶0058 – 59 from Applicant disclosure. Refer to ¶0094 wherein “a script may be used to pose questions to the user and the user input may comprise answers to these questions” (e.g. directed to the demographic information claimed) that are further “used to populate the fields of the form” that is standardized for further document transaction requests which is directed to the set of data relating to the specific transaction. See ¶0050 and ¶0053 wherein the system uses “information specific to the parties and transaction involved” to “populate the standardized forms” and grants “selective access to only those documents that are identified as buyer-accessible by the permissions associated with the “buyer” role”, respectively. Examiner notes that the metadata described and that comprises the electronic identi-authenti object claimed is descriptive matter that is not expressly functionally-tied.)
electronic login data comprising: a username; a password; (In ¶0045: describes that the “buyer 52 may be assigned or may select a user name and a password”. See ¶0098 also.)
one or more electronic interactions with the customer, the one or more electronic interactions comprising: a question transmitted by the orchestration services layer; and (In ¶0094: describes that “a script may be used” by the system to “pose questions to the user and the user input may comprise answers to these questions. The answers may then be used to populate the fields of the form.”)
a correct response received at the orchestration services layer from a mobile device associated with the customer; (In ¶0094: describes that a “form may be displayed to the user” through their device that can be a “cellphone” (see ¶0018), wherein “fields within the standardized form may be identified to the user and the user input may include information appropriate to populate these fields”.)
and an electronic acknowledgement of an electronic signature particular, said electronic signature particular being a predetermined signature font, a picture or an object; (In ¶0064; Fig. 2 (62 and 42); Fig. 3 (94): describes that when “state law requires that an actual handwritten signature or other identifying mark be captured and associated with the transaction document before it may be considered executed” via the “execution module 94” which is directed to electronic signature particular being a predetermined signature font, a picture or an object. Also, the “execution module 94 may include an application appropriate for capturing and/or receiving an electronic representation of a signature and for applying that signature to transaction documents. Thus, execution module 94 may communicate with a signature capture device 62 to receive an electronic representation of an executing party's signature.” Refer to ¶0027 also for more details.)
a set of identification data relating to the customer; and a set of data relating to the specific transaction; (In ¶0030: describes that the “TMS 42” may include “storage of transaction documents prepared by any of the document preparers” that further relates to the customer or “buyer” (see ¶0024 - 25 for examples), the system may also “store other transaction related data such as task lists, process flows, instruction files, tutorials, or other transaction related information” and “may provide improved organization and accessibility of the complex information and multiplicity of documents associated with a transaction.”)
the API stores the electronic identi-authenti object at the document services repository; (In ¶0048: describes storing the identifier objects in a database and associating with authorization for data.)
to prepare a document-to-sign, the framework application: (In ¶0095: describes preparing the document for electronic execution.)
adds, to the template, the set of identification data relating to the customer; (In ¶0094; Fig. 4 (104): describes associating user with a transaction and “user input may be received to customize the standardized form at step 114”. Also, in ¶0091 describes identification information being received and used to “authenticate or verify the identity of the user to TMS 42 at step 102”.)
adds, to the template, signature tags; (In ¶0033: describes adding signature blocks to relevant portions of the document with ““click-to-sign” feature” that includes “signature or other representative indicia applied to the many signature blocks within the document”.)
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; (In ¶0063 – 65: describes selecting a type of signature for the document based on users such as “click to sign” or “apply captured signature”.)
the framework application transfers the document-to-sign to the API; and the API forwards the document-to-sign to the electronic communications channel for electronic signature by the customers (In ¶0063: describes transmitting the document to be signed through the TMS 42 to various parties by way of a multi-party system and communication channels.)
the API identifies and authenticates the customer based only on an electronic match between a first electronic signature and the electronic signature particular stored within the electronic identi-authenti object, from the customer at the electronic communications channel, said first electronic signature that converts the document-to-sign into a signed document; (In ¶0033: describes receiving an electronic signature that is applied to the signature blocks utilizing the TMS system through the “click-to-sign” process and “a digital certificate may be associated with each block that was clicked” by the buyer. Refer to ¶0045 for general details.)
the API updates a data log associated with the electronic identi-authenti object to indicate that the electronic identi-authenti object was used in a first instance for identification and authentication; (In ¶0084; Fig. 5A (226 and 220): describes the update of “the status identifiers associated with the document to indicate that the buyer has reviewed and approved the document.”)
the API receives a second electronic signature, said second electronic signature identifying and authenticating the customer based only an electronic match between a second electronic signature and the electronic signature particular stored within on the electronic identi- authenti object, from the customer at a second electronic communications channel, said second electronic signature that converts a second document-to-sign into a signed document; and (In ¶0104 – 105; Fig. 5A (216 – 226); Fig. 5B (230 and 234 – 236): describes that when “additional input is required to formally execute the transaction document”, the system can receive the additional input including “further signatures by other parties” that are required and “additional user input may include a digital certificate or other certification indicia that is associated with the user” (see ¶0107 also for details of notary authentication and a “digital file” that may “identify a certification authority that may be contacted for the obtainment of an electronic seal or other indicia”), which is directed to second electronic signature for authenticating the customer. Refer to ¶0110 – 111 for more receiving user and notary commands that require user signature and digital certificates and refer to ¶0114 wherein “signatories may identify documents or portions of documents to which the signing party wishes a future-captured signature to be applied”.)
the API updates the data log associated with the electronic identi-authenti object to indicate that the electronic identi-authenti object was used in a second instance for identification and authentication. (In ¶0083 – 84; Fig. 5A (220 and 210): describes that “users of TMS 42 may check the status of a document at any time to determine whether action by the user is required” since the system automatically detects user actions, which is directed to data logs being updated at a second instance. The user can view “transaction documents or obtain other transaction-related data” including “one or more status identifiers” that “may be associated with each document” that further include attributes that show if the document is complete or required specific actions such as “recordation”, “review”, “approval” “notarization”, etc. See ¶0112 wherein after “certification of the transaction document and the application of any security features to the document, the transaction document may be stored at step 220”.)
Ross generally teaches that “identification information specific to the parties and transaction involved may be used to populate the standardized forms” wherein the “modified forms may then be associated with the specific transaction and stored in database 82 as transaction documents” (see ¶0050; Ross) and these “standardized forms” are further provided to the user based on their role (see ¶0092; Ross). However, Ross does not explicitly teach the abilities of specifically identifying a transaction identifier for a specific transaction, transmit it to a document services hub, receive the template corresponding to the transaction identifier from the document services hub and transferring the template and its related customer’s identification data and electronic identi-authenti object to the framework application. However, Peterson which teaches:
the API identifies a transaction identifier for the specific transaction; (In ¶0033; Fig. 1 (100, 104 and 130); Fig. 3 (302); Fig. 5 (500 and 512): describes receiving a “URL that identifies a template managed or stored by an electronic signature service” wherein the “template specifies electronic signature data that is required to represent a complete electronic signature”. Refer to ¶0223 – 224 for details that describe API and framework.)
the API transmits the transaction identifier to a document services hub in communication with the document services repository; (In ¶0034; Fig. 1 (100, 104, and 130); Fig. 3 (304): describes “the process transmits a request based on the received URL” wherein “the script may incorporate the collected data values into the request, such as by appending them to the URL as a query string comprising one or more key value pairs”.)
the API receives a template that corresponds to the transaction identifier from the document services hub in communication with the document services repository; (In ¶0035; Fig. 1 (100, 104 and 130); Fig. 3 (306): describes “at block 306, the process receives a form prepared based on the template”.)
the API transfers the template, the set of identification data relating to the customer and electronic identi-authenti object to the framework application; (In ¶0036 – 37; Fig. 1 (100, 104, 121 and 130); Fig. 3 (308 – 310): describes “At block 308, the process collects required electronic signature data by presenting the received form” wherein the “process may render the form in a Web browser or similar rendering component” and “at block 310, the process transmits the collected electronic signature data to the electronic signature service”.)
It would have been obvious to one of ordinary skill in the art before the earliest effective filing date of the claimed invention to modify Ross to provide the abilities of specifically identifying a transaction identifier for a specific transaction, transmit it to a document services hub, receive the template corresponding to the transaction identifier from the document services hub and transferring the template and its related customer’s identification data and electronic identi-authenti object to the framework application, as taught by Peterson in order to provide a “programmatic interface to one or more functions of the electronic signature service” that “facilitates the development of third-party software, such as user interfaces, plug-ins, news feeds, adapters (e.g., for integrating functions of the electronic signature service 100 into Web or mobile applications), and the like” (¶0224; Peterson).
Ross generally teaches receiving “user identification information” used for authentication and verification including passwords that can be assigned along with authentication services that uses “login and password dialog, challenge and response, messaging support, and, depending on the security protocol utilized, encryption” (see ¶0044 – 45 and ¶0091; Ross). However, neither Ross or Peterson explicitly teach the abilities of having specific identification documentation and a one-time password. However, Nassiri which teaches:
identification documentation relating to the customer, the identification documentation comprising one or more of a passport, driver's license, marriage license and social security card; (In ¶0110 – 111; Figs. 2A – 5C (80): describes this non-functional descriptive matter as the “Authenticated Identity Documents” which includes “a hard copy drivers license, or a professional license, or a passport, or a government issued identity card, or a contract” that can also be provided in electronic form (see ¶0112 – 114). Refer to ¶0085 for more details of user inputting “electronic documents” that include personal information.)
and a one-time password; (In ¶0095: describes that “the electronic transaction manager 55 assigns a temporary signing password 230 to each signatory 130. Each signatory 130 is given a temporary signing password 230 that is unique to the signatory 130” wherein the “temporary signing password” is “distinct from the initial password 1203 assigned to the electronic document 80, and from the access password 200 assigned to the subsequent authorized party 120”.)
It would have been obvious to one of ordinary skill in the art before the earliest effective filing date of the claimed invention to modify Ross and Peterson to provide the abilities of having specific identification documentation and a one-time password, as taught by Peterson, as it would be “obvious to try” and include specific identification information that can be used with a one-time password that can guarantee the verification and validation of a customer’s authentication as well as in order to conduct such transactions related to document preparation, in a an “on-line” format “via a video conference using a paperless document platform that encompasses the necessary component of signature verification or identity verification to conclude the transaction” (¶0011; Nassiri).
Regarding claim 2:
The combination of Ross, Peterson and Nassiri, as shown in the rejection above, discloses the limitations of claim 1.
Ross further teaches:
wherein the electronic communications channel is a mobile application or online application. (In ¶0025: describes data transmitted via the communications network is used to create the authentication data object of users.)
Regarding claim 3:
The combination of Ross, Peterson and Nassiri, as shown in the rejection above, discloses the limitations of claim 1.
Ross further teaches:
wherein data used to create the electronic identi-authenti object is based on the electronic communications channel. (In ¶0044: describes data transmitted via the communications network is used to create the authentication data object of users.)
Regarding claim 5:
Ross, as shown in the rejection above, discloses the limitations of claim 3.
Ross further teaches:
wherein the electronic communications channel is a remote electronic communications channel, and the identifying includes entering a username and password. (In ¶0044: teaches describes data transmitted via the communications network is used to create the authentication data object of users; username and password.)
Regarding claim 6:
The combination of Ross, Peterson and Nassiri, as shown in the rejection above, discloses the limitations of claim 1.
Ross further teaches:
wherein the identification information received from the customer and the set of identification data relating to the customer is different data. (In ¶0092; Fig. 4: describes receipt of different data with regard to creation of the document including user identification information and user role data.)
Regarding claim 7:
The combination of Ross, Peterson and Nassiri, as shown in the rejection above, discloses the limitations of claim 1.
Ross further teaches:
wherein the set of identification data relating to the customer includes at least a portion of the identification information received from the customer. (In ¶0054 – 56: describes the data set relating to the customer including data relevant to the user roles and permissions based on the authentication data utilized.)
Regarding claim 8:
The combination of Ross, Peterson and Nassiri, as shown in the rejection above, discloses the limitations of claim 1.
Ross further teaches:
further comprising, prior to electronically signing the document-to-sign, acknowledging, by the customer at the electronic communications channel, a file that constitutes a signature. (In ¶0063 and ¶0068: describes prior to signing, the customer clicks the signature box to identify the parties intent to sign and applying the electronic representation of the signature to the electronic transaction document. See ¶0027 wherein electronic signature pad is used to capture handwritten signature.)
Regarding claim 9:
Ross, as shown in the rejection above, discloses the limitations of claims 8.
Ross further teaches:
wherein the file includes an image or a signature font. (In ¶0063 and ¶0068: describes an electronic representation of a signature captured by a signature capture device, which is interpreted to include a file of an image. See ¶0027 wherein an image of the signature is captured.)
Regarding claims 10, 16 and 20:
The combination of Ross, Peterson and Nassiri, as shown in the rejection above, discloses the limitations of claims 1, 13 and 17, respectively.
Ross further teaches:
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. (In ¶0063 and ¶0068: describes a click-to-sign box or an electronic representation of a signature captured by a signature capture device, which is interpreted to include a file of an image.)
Regarding claims 11, 14 and 18:
The combination of Ross, Peterson and Nassiri, as shown in the rejection above, discloses the limitations of claims 1, 13 and 17, respectively.
Ross further teaches:
further comprising: forwarding a signed document comprising the document-to-sign and the electronic signature from the electronic 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. (In ¶0037 and ¶0043; Fig. 2: describes the transmittal and storage of executed documents.)
Regarding claims 12, 15 and 19:
The combination of Ross, Peterson and Nassiri, as shown in the rejection above, discloses the limitations of claims 1, 14 and 18, respectively.
Ross further teaches:
further comprising storing the electronic identi-authenti object with the signed document at the document services repository. (In ¶0045: describes assigning party a unique identifier upon being authorized which is used by the system to authenticate and all access to transaction documents, thus the unique identifier is stored for access.)
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Follis (U.S. Patent No. 9984242 B2) is pertinent because it “relates generally to computer-implemented methods and systems for generating documents and recording signature proceedings according to attestation requirements and other document execution requirements.”
Hayslett (U.S. Pub No. 20190311021 A1) is pertinent because it “relate generally to the technical field of preparing data for signature retrieval and, in one specific example, to a technological process for signing documents.”
Porter (U.S. Pub No. 20180293647 A1) is pertinent because it is about “EscrowTab mobile application system and method comprises automating, reviewing, executing, and transmitting documents used in financial transactions by providing document data visualization on a mobile device allowing for review and execution of financial closing documents, such as promissory notes, deeds of trust and financial documents on a mobile device such as a tablet and relaying these documents to and from the originating financial institution, via means of the internet or dedicated communications media..”
Gaeta (U.S. Patent No. 11869017 B1) is pertinent because it “generally relates to facilitating remote execution and notarization of instruments.”
Grosse (U.S. Pub No. 20210397784 A1) is pertinent because it describes a system and method for automated data importation, processing, and form submittal.
Malliah (U.S. Pub No. 20200019715 A1) is pertinent because it describes a system and method for signing an electronic document;
Bansal (U.S. Pub No. 20170345394 A1) is pertinent because it describes document processing workflows, and more specifically to workflows that allow an electronic signature to be acquired and applied to a document using multiple devices.
Brown (U.S. Pub No. 20200067705 A1) is pertinent because it describes creating signature objects for signing an electronic document.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Ivonnemary Rivera Gonzalez whose telephone number is (571)272-6158. The examiner can normally be reached Mon - Fri 9:00AM - 5:30PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Nathan Uber can be reached at (571) 270-3923. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/IVONNEMARY RIVERA GONZALEZ/Examiner, Art Unit 3626
/NATHAN C UBER/Supervisory Patent Examiner, Art Unit 3626
Prosecution Insights