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 .
Claim Objection
Claims 1-16 are objected to because of the following informalities:
Claims 1 and 16 recite “ method comprising the steps of (a) One of completing and sending”. “One of” seems to be a typographical error and the claim will be read as completing and sending.
Dependent claims 2-15 are objected to by virtue of dependency.
Claim 3 recites “the digital form of step 2” which seems a typographical error. This would be read as the digital form of claim 2.
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.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claims 1-16 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1
Claims 1-16 are directed to a method (i.e., a process), therefore, claims 1-16 all fall within the one of the four statutory categories of invention.
Step 2A, Prong One
Independent claims 1 substantially recites: completing and sending a form for a prospective client account working on behalf of a company; (b) after (a), extracting information from the form, to populate an account of the prospective client of a customer relations management (CRM) account with at least some of the information and adding one of a customer identifier selected from the group of a customer number and an account number to the account; (c) after (b), populating, with at least some of the information based on a decision algorithm of the company, at least one document selected from the group of:(i) a funding form selected from one of a transfer form from a third party company and a funding request from the third party company; (ii) an engagement agreement between the prospective client and the company; and (iii) an account application form to generate a specific account at the company; (d) after (c), sending the at least one document to the prospective client for signature through the world wide web; (e) the prospective customer signing the at least one document and sending back the company; (f) the company receiving the signed document and if the signed form is the funding form of step (c)(i): the sending the signed form to the third party company including the customer identifier of the prospective account; and (ii) upon receipt of assets from the third party, the CRM being advised of the receipt to activate the account as an active customer account of an active customer and advising a human operator at the company to at least interact with the active customer having successfully onboarded the active customer account. Claim 16 recites similar limitations.
The limitations stated above are processes/ functions that under broadest reasonable interpretation (e.g.,) covers “certain methods of organizing human activity” (managing personal behavior or relationships or interactions between people and commercial or legal interactions and following rules or instructions). Therefore, the claims recite an abstract idea.
Step 2A, Prong Two
The judicial exception is not integrated into a practical application. Claims 1 and 16 as a whole amounts to: (i) merely invoking generic components as a tool to perform the abstract idea or “apply it” (or an equivalent).
Claim 1 and 16 recite the additional elements: world wide web, computer, automatedly, extracting information without human assistance, sending information without human assistance, software, these are recited at a high-level of generality in the specification. (See specification The form may be available on a website of the company or may be sent or otherwise accessed via a text, email message, or otherwise made available to a potential customer[0011] A computer, or processor (smart phone, tablet, etc,) on the potential client side may complete at least enough of the information requested to process the form and send the information through the world wide web or otherwise to a computer or processor working on behalf of the company. [0024] Other embodiments may extract digital information written, typed or otherwise provided on a form as is known in the art [0025] For at least one embodiment of the present invention a form 12 is built such as through FormRouter (TM) to provide the form 12 which receives digital information.[0036] the CRM software is Salesforce. For at least some embodiments, FormRouter creates the customer identifier 26 of step (b) provided in a .pdf format and recognized by Salesforce [0027]), such that, when viewed as whole/ordered combination ( as shown in Fig.1-2), it amounts to no more than mere instruction to apply the judicial exception using generic computer components or “apply it” (See MPEP 2106.05(f)).
Step 2B
As discussed above with respect to Step 2A Prong Two, the additional elements amount to no more than: (i) “apply it” (or an equivalent), does not integrate the abstract idea into a practical application at Step 2A or provide an inventive concept at Step 2B.
Therefore, the additional elements of: (i) world wide web, computer, automatedly, extracting information without human assistance, sending information without human assistance, software, do not integrate the abstract idea into a practical application at Step 2A or provide an inventive concept at Step 2B. Thus, even when viewed as a whole/ordered combination ( as shown in Fig.1-2), nothing in the claims adds significantly more (i.e., an inventive concept) to the abstract idea. Thus, the claim is ineligible.
Dependent Claims Step 2A:
The limitations of the dependent claims but for those addressed below merely set forth further refinements of the abstract idea without changing the analysis already presented. Additionally, for the same reasons as above, the limitations fail to integrate the abstract idea into a practical application because they use the same general technological environment and instructions to implement the abstract idea (e.g., using computers to communicate data).
The dependent Claims add the elements “digital form, autofilling, FormRouter (TM) platform, digital signing software application is Docusign, digital signing software application pulling information, .pdf format, electronically sign”, these fail to integrate the abstract idea into a practical application because merely invoking the generic components as a tool to perform the abstract idea or “apply it”. Thus, the claims are ineligible.
Dependent Claims Step 2B:
The dependent claims merely use the same general technological environment and instructions to implement the abstract idea. Accordingly, the claims are not directed to significantly more than the exception itself.
The dependent Claims add the elements “digital form, autofilling, FormRouter (TM) platform, digital signing software application is Docusign, digital signing software application pulling information, .pdf format, electronically sign, are recited at a high-level of generality (See specification, [0036] the form of step (a) is a digital form 12. The digital form 12 of step 2 may have reciprocal coding assisting the potential customer by autofilling at least some information on the form 12 based on information provided by the potential customer 14 on the form 12. For some embodiments, the form 12 may be built on a FormRouter (TM) platform. For at least some embodiments, the CRM software is Salesforce. For at least some embodiments, FormRouter creates the customer identifier 26 of step (b) provided in a .pdf format and recognized by Salesforce. For at least some embodiments, at least one document 22 is generated through a digital signing software application pulling at least some of the information provided by the potential customer 14 onto the document 22, wherein the document 22 has a pre-approved format at least approved by the company. For at least some embodiments, the digital signing software application is Docusign (TM) and/or wherein in step (e) the potential customer 14 electronically signs the at least one document [0027])- these do not amount to significantly more for the same reasons they fail to integrate the abstract idea into a practical application. Therefore, the dependent claims are not eligible subject matter under § 101.
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.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-3, 5, and 7-15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kumar ( US20180060965 A1) in view of Kaufman ( US 20150134524 A1) in view of Roselli (US 20140149283 A1)
As per claim 1, Kumar teaches:
An automated onboarding method comprising the steps of:(a) One of completing and sending a form for a prospective client account through the world wide web to a computer working on behalf of a company; ( see at least: Fig.4 #404 client enter information [00011-12] [0039] , the advisor 102 may enter information into the managed package 202, and a web service 118 provided by an internet information services (IIS) server 210 may process an account creation, including communicating with an account opening API 212 of a custodian platform 130 to actually open the account within the custodian's database 214).
(b) after (a), the computer automatedly extracting information from the form, without human assistance, to populate an account of the prospective client of a customer relations management (CRM) account software with at least some of the information adding one of a customer identifier selected from the group of a customer number and an account number to the account; ( see at least: Fig.4, 406 create new account in CRM [0039] a forms service 154 provided by a forms generation server 220 may automatically generate forms with information captured during user entry to effect the creation of the account. [0042-46] In 330, the custodian may accept and process the forms and return an account number for the new account opened by processing of the forms to the app 144)
(c) after (b), the computer automatedly populating, with at least some of the information based on a decision algorithm of the company, ( see at least: Fig.3B-3C, Fig.4 #408-410 [0034-35] Each custodian may have their own set of forms to be completed and signed by the appropriate parties. The system 100 may integrate with forms automation vendors. The system 100 may use the APIs provided by the forms vendors to create an envelope/bundle with the selected forms and use the appropriate pre-fill APIs to have the forms pre-filled with the data from the system 100. [0017] Custodians may each have a different format and/or method for accepting account opening data [0065] The forms may be generated on the screen and the associated financial account information may automatically get filled into the forms. [0026])
at least one document selected from the group of: (i) a funding form selected from one of a transfer form from a third-party company and a funding request from the third-party company; (ii) an engagement agreement between the prospective client and the company and (iii) an account application form to generate a specific account at the company; ( see at least: Fig. 3B #314-316,Fig.4 [0063] Advisors may generate the appropriate forms from the financial account in the system app and send them to clients to get a signature digitally. [0014] to open a brokerage account with a particular custodian, the following information may be collected and submitted to the custodian [0015] Advisors may select product type, product company, and the account type, and/or other attributes for a client product [0047] the advisor 102 and/or investor 104 may opt to fund the account using the app 144 [0049-51] generating request with client and financial account information and send it to the form service to generate forms. )
(d) after (c), the computer automatedly sending the at least one document to the prospective client for signature through the world wide web; ( see at least:Fig.3B #320-322, [0039] A forms package 222 may be created and sent to the client for review and signature. The status of the forms package 222 may be tracked inside the managed package 202, along with a timestamp, until the completion of signatures on all forms. For example, an eSignature service 152 provided by an eSignature web server 230 may provide form signing functionality. )
(e) the prospective customer signing the at least one document and sending back through the world wide web to the computer of the company; (f) the computer of the company receiving the signed document ( see at least: Fig. 3C #324[0039] A forms package 222 may be created and sent to the client for review and signature. The status of the forms package 222 may be tracked inside the managed package 202, along with a timestamp, until the completion of signatures on all forms. For example, an eSignature service 152 provided by an eSignature web server 230 may provide form signing functionality. Completed (e.g., signed) forms 232 may be stored in CRM cloud 140 and/or within an integrated document management system. )
if the signed form is the funding form of step (c)(i): i) the computer automatedly sending the signed form to the third-party company including the customer identifier of the prospective account, without human intervention; ( see at least: Fig.3D , Fig.4D [0042-47] In 336, the app 144 may send data describing the request to the bank and/or retrieve information about the bank allowing the funds to be transferred (e.g., routing number and account number). In 338, the bank may transfer the funds, and the app 144 may provide notification that the account has been funded.)
While Kumar teaches the CRM software, and receipt of assets from the third party, automatedly onboarded account ( see at least: Fig.3C-3D #328- 330, 332 [0045-47] In 336, the app 144 may send data describing the request to the bank and/or retrieve information about the bank allowing the funds to be transferred (e.g., routing number and account number). In 338, the bank may transfer the funds, and the app 144 may provide notification that the account has been funded.)
Kumar does not explicitly teach (ii) upon receipt of assets from the third party, the CRM software being advised of the receipt to activate the account as an active customer account of an active customer and advising a human operator at the company to at least interact with the active customer having successfully automatedly onboarded the active customer account.
However, Kaufman teaches upon receipt of assets from the third party, inform of the receipt to activate the account as an active customer account of an active customer ( see at least: Fig.1, #118 & #120[0029] At a block 120, the new financial account may be activated for use. The new financial account may be activated immediately after the financial account has been credited [0063] The crediting of the new financial account may cause the new financial account to be activated (block 328), and the activation of the new financial account may cause a notification to be generated and/or sent to the user, applicant, and/or new account owner (block 330)).
It would have been obvious for one ordinary skilled in the art before the effective filing date of present invention to combine the activation of the account upon the receipt of assets feature for the same reasons its useful in Kaufman -namely, to perform the method during a single business day, e.g., during a single session established with at least one computing device of the institution providing the new financial account (par.6). Moreover, this is merely a combination of old elements in the art. In the combination, no element would serve a purpose other than it already did independently, and one skilled in the art would have recognized that the combination could have been implemented through routine engineering producing predictable results.
Roselli teaches advising a human operator at the company to at least interact with the active customer having successfully automatedly onboarded the active customer account. ( See at least: [1098] A branch/third party vendor may receive an advice to issue a welcome package, for example after a particular ‘trigger’ by the customer/staff member (in some embodiments, this only applies to postal options[1075-76] A gift may be initiated from a promotion or account opening. For Manual generation, the system should indicate that the customer is qualified for a promotional/welcome gift. Staff will then fulfill this item manually.).
It would have been obvious for one ordinary skilled in the art before the effective filing date of present invention to combine the manual advising feature for the same reasons its useful in Roselli -namely, the Welcome letter may include Credit Protection, Identity Protection Plus, and/or Credit Keeper information if selected from product configuration. Moreover, this is merely a combination of old elements in the art. In the combination, no element would serve a purpose other than it already did independently, and one skilled in the art would have recognized that the combination could have been implemented through routine engineering producing predictable results.
As per claim 2, Kumar in view of Kaufman and Roselli teaches claim 1 as above. Kumar further teaches:
wherein the form of step (a) is a digital form ( see at least: [0063] DocuSign [0039] an eSignature service 152 provided by an eSignature web server 230 may provide form signing functionality)
As per claim 3, Kumar in view of Kaufman and Roselli teaches claim 2 as above. Kumar further teaches:
the digital form of step 2 has reciprocal coding assisting the potential customer by autofilling at least some information on the form based on information provided by the potential customer on the form. ( see at least: [0039] the advisor 102 may enter information into the managed package 202, and a web service 118 provided by an internet information services (IIS) server 210 may process an account creation, including communicating with an account opening API 212 of a custodian platform 130 to actually open the account within the custodian's database 214. Furthermore, a forms service 154 provided by a forms generation server 220 may automatically generate forms with information captured during user entry to effect the creation of the account. A forms package 222 may be created and sent to the client for review and signature. [0032] They may also provide an API/mechanism to transmit data elements to this portal such that these data elements may be pre-filled in the portal, and the user may not have to re-enter them. In such cases, the system 100 may capture the account information, validate and transform it, and send it across to the custodian by a pre-fill API/mechanism. )
As per claim 5, Kumar in view of Kaufman and Roselli teaches claim 1 as above. Kumar further teaches:
wherein the CRM software is Salesforce. ( see [0020] Salesforce™ platform )
As per claim 7, Kumar in view of Kaufman and Roselli teaches claim 1 as above. Kumar further teaches:
the at least one document is generated through a digital signing software application pulling at least some of the information provided by the potential customer onto the document ( see at least: [0063] DocuSign for forms generation and eSignature functionality, Advisors may generate the appropriate forms from the financial account in the system app and send them to clients to get a signature digitally [0032] prefilled [0035] The system 100 may use the APIs provided by the forms vendors to create an envelope/bundle with the selected forms and use the appropriate pre-fill APIs to have the forms pre-filled with the data from the system 100.).
wherein the document has a pre-approved format at least approved by the company ( see at least:[0078] the system data model may be normalized, and data may be stored in multiple objects to avoid data duplication. The serialization process may query the data in all related objects and, for further processing, convert it to a well-known standard format such as xml/json. [preapproved format by the company] )
As per claim 8, Kumar in view of Kaufman and Roselli teaches claim 7 as above. Kumar further teaches:
wherein the digital signing software application is Docusign (TM). ( see at least: [0063] DocuSign for forms generation and eSignature functionality).
As per claim 9, Kumar in view of Kaufman and Roselli teaches claim 1 as above. Kumar further teaches:
wherein after step (b) verifies the likely legitimacy of the prospective client and initiates step (c). ( see Fig. 4A.#412-414[0050-51] In 412, the forms service 154 may receive the request and authenticate the request. If authentication is successful, in 414, the forms service 154 may generate and/or provide forms to the CRM cloud 140[0060] The account opening wizard 500 screens may perform validation checks as the advisor 102 enters information for their client [step-b])
Kumar does not explicitly teach a human operator verifying the client; however, this is taught by Rosille ( see at least: [0446-447] one or more manual validations—performed by a person with none (or almost none) system intervention. Types of Manual Validation include Verbal Quizzes, Documentary Verification, and Enhanced Due Diligence. These questions are typically read to customers by staff and not used online. The staff captures the customer's answers and compares them with the information existent in the bank systems. [0448] For Documentary Verification, for example, the bank staff may examine and verify identification to determine the true identity of all customers/application requesting the Bank's services [0416] KYC manual verification).
It would have been obvious for one ordinary skilled in the art before the effective filing date of present invention to combine the human operator verification feature for the same reasons its useful in Rosille -namely, to determine the true identity of all customers/application requesting the Bank's services ( par.448). Moreover, this is merely a combination of old elements in the art. In the combination, no element would serve a purpose other than it already did independently, and one skilled in the art would have recognized that the combination could have been implemented through routine engineering producing predictable results.
As per claim 10, Kumar in view of Kaufman and Roselli teaches claim 1 as above. Kumar further teaches:
wherein step (c) automatedly occurs following step (b) without human interaction. ( see at least: Fig.3B-3C, Fig.4 #408-410 [0039], [0065] The forms may be generated on the screen and the associated financial account information may automatically get filled into the forms)
As per claim 11, Kumar in view of Kaufman and Roselli teaches claim 1 as above. Kumar further teaches:
wherein after step (e) verifies the likely legitimacy of the prospective client account before onboarding the customer account. ( see at least: Fig. 4B-4C [0053-56] In 420, the services cloud 110 may receive the account creation request and authenticate. If validation is successful, in 434, the services cloud 110 may send a web services request to the custodian 130 API including the validated information In 436, the custodian 130 may accept the information and generate an account number. )
Kumar does not explicitly teach a human operator verifies the likely legitimacy of the prospective client account, however, this is taught by Rosille ( see at least: [0446-447] one or more manual validations—performed by a person with none (or almost none) system intervention. Types of Manual Validation include Verbal Quizzes, Documentary Verification, and Enhanced Due Diligence. These questions are typically read to customers by staff and not used online. The staff captures the customer's answers and compares them with the information existent in the bank systems. [0448] For Documentary Verification, for example, the bank staff may examine and verify identification to determine the true identity of all customers/application requesting the Bank's services [0416] KYC manual verification).
It would have been obvious for one ordinary skilled in the art before the effective filing date of present invention to combine the human operator verification feature for the same reasons its useful in Rosille -namely, to determine the true identity of all customers/application requesting the Bank's services ( par.448). Moreover, this is merely a combination of old elements in the art. In the combination, no element would serve a purpose other than it already did independently, and one skilled in the art would have recognized that the combination could have been implemented through routine engineering producing predictable results.
As per claim 12, Kumar in view of Kaufman and Roselli teaches claim 1 as above. Kumar further teaches:
wherein step (f) automatedly occurs following step (e) without human interaction. ( see at least: Fig. 3C #324-[0039] A forms package 222 may be created and sent to the client for review and signature. The status of the forms package 222 may be tracked inside the managed package 202, along with a timestamp, until the completion of signatures on all forms. For example, an eSignature service 152 provided by an eSignature web server 230 may provide form signing functionality. Completed (e.g., signed) forms 232 may be stored in CRM cloud 140 and/or within an integrated document management system [0052] In 424, the eSignature service 152 may receive the signed form from the investor 104 and send it to the CRM cloud 140 (e.g., as an XML response)).
As per claim 13, Kumar in view of Kaufman and Roselli teaches claim 1 as above. Kumar further teaches:
wherein in step e the potential customer electronically signs the at least one document. ( see at least: [0039] A forms package 222 may be created and sent to the client for review and signature. The status of the forms package 222 may be tracked inside the managed package 202, along with a timestamp, until the completion of signatures on all forms. For example, an eSignature service 152 provided by an eSignature web server 230 may provide form signing functionality. Completed (e.g., signed) forms 232 may be stored in CRM cloud 140 and/or within an integrated document management system. [0052])
As per claim 14, Kumar in view of Kaufman and Roselli teaches claim 1 as above. Kumar further teaches:
wherein in step (c), the funding form are sent to the prospective client as the at least one form, ( see at least:[0047],[0054] In 428, the CRM cloud 140 may receive client and account information for account creation and/or funding [0110] investor receive selected forms ( see Fig.3B) to sign it. The forms include money/asset movement ( see [0110])).
and upon receipt of the assets, the onboarding process is complete in step (f)(ii). ( see at least: Fig.3D #338, [0047] In 338, the bank may transfer the funds, and the app 144 may provide notification that the account has been funded.)
Kumar does not explicitly teach the engagement letter; however, this is taught by Rosille ( see at least: [0457] Terms and Conditions is the process of presenting the customer the terms and conditions related to the account that he/she is opening. Acceptance of Terms and Conditions may be passive or non-passive, online[0471-472] this milestone functions to present the customer with an appropriate Terms and Conditions agreement related to the entity as well as product(s) the customer selected. By collecting the input from this milestone, the system may decide whether the application is eligible for activation and, at the very end, send fulfilment request [1402] table 6 shows milestone terms and condition must be completed to activate the account)
It would have been obvious for one ordinary skilled in the art before the effective filing date of present invention to combine the engagement letter feature for the same reasons its useful in Rosille -namely, to review Terms and Conditions and make an informed decision on whether to proceed) ( par.472). Moreover, this is merely a combination of old elements in the art. In the combination, no element would serve a purpose other than it already did independently, and one skilled in the art would have recognized that the combination could have been implemented through routine engineering producing predictable results.
As per claim 15, Kumar in view of Kaufman and Roselli teaches claim 1 as above. Kumar further teaches:
wherein in step (c), the account application form and funding form are sent to the prospective client as the at least one form, ( see at least, [0047],[0054] In 428, the CRM cloud 140 may receive client and account information for account creation and/or funding [0110] investor receive selected forms ( see Fig.3B) to sign it. The forms include money/asset movement ( see [0110])).
upon receipt of the assets, the onboarding process is complete in step (f)(ii) ( see at least: Fig.3D #338, [0047] In 338, the bank may transfer the funds, and the app 144 may provide notification that the account has been funded.)
Kumar does not teach the signed engagement letter; however, this is taught by Rosille ( see at least: [0457] Terms and Conditions is the process of presenting the customer the terms and conditions related to the account that he/she is opening. Acceptance of Terms and Conditions may be passive or non-passive, online[0471-472] this milestone functions to present the customer with an appropriate Terms and Conditions agreement related to the entity as well as product(s) the customer selected. By collecting the input from this milestone, the system may decide whether the application is eligible for activation and, at the very end, send fulfilment request)
It would have been obvious for one ordinary skilled in the art before the effective filing date of present invention to combine the engagement letter feature for the same reasons its useful in Rosille -namely, to review Terms and Conditions and make an informed decision on whether to proceed) ( par.472). Moreover, this is merely a combination of old elements in the art. In the combination, no element would serve a purpose other than it already did independently, and one skilled in the art would have recognized that the combination could have been implemented through routine engineering producing predictable results.
Claim(s) 4 and 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kumar (US20180060965 a1) in view of Kaufman ( US 20150134524 A1) in view of Roselli (US 20140149283 A1) in further view of FormRouter.com (https://formrouter.com/submit-pdf-forms-to-salesforce/)
As per claim 4, Kumar in view of Kaufman and Roselli teaches claim 1 as above. Kumar further teaches:
the form ( see [0039] a forms service 154 provided by a forms generation server 220 may automatically generate forms with information captured during user entry to effect the creation of the account.)
Kumar does not explicitly teach the form is built on a FormRouter (TM ) platform However, this is taught by FormRouter ( see the video explaining how to build a PDF form using FormRouter, point the form to a FormRouter account, and map the form to a salesforce.com object after logging into salesforce.com account)
It would have been obvious for one ordinary skilled in the art before the effective filing date of present invention to combine building the form using FormRouter feature for the same reasons its useful in FormRouter -namely, to allow to take advantage of PDF forms and Salesforce to collect and collaboratively work with data. Moreover, this is merely a combination of old elements in the art. In the combination, no element would serve a purpose other than it already did independently, and one skilled in the art would have recognized that the combination could have been implemented through routine engineering producing predictable results.
As per claim 6, Kumar in view of Kaufman and Roselli teaches claim 5 as above. Kumar further teaches:
Salesforce login credentials ( see Fig.3A#310 Advisor logs into CRM. Fig.5A saleforce [0042])
Kumar does not explicitly teach the form is built on a FormRouter (TM ) platform and Salesforce login credentials connect the FormRouter platform to Salesforce, wherein FormRouter creates the customer identifier of step (b) provided in a .pdf format and recognized by Salesforce. However, this is taught by FormRouter ( see title: Submit PDF Forms to SalesForce.com® Easily collect data securely from PDF forms to Salesforce objects. Also see the video explaining how to build a PDF form using FormRouter, point the form to a FormRouter account, and map the form to a salesforce.com object after logging into salesforce.com account, see image below showing resume.pdf an attached pdf document to the Salesforce account).
PNG
media_image1.png
561
1026
media_image1.png
Greyscale
It would have been obvious for one ordinary skilled in the art before the effective filing date of present invention to combine building the form using FormRouter and attach it to salesforce.com account feature for the same reasons its useful in FormRouter -namely, to allow to take advantage of PDF forms and Salesforce to collect and collaboratively work with data. Moreover, this is merely a combination of old elements in the art. In the combination, no element would serve a purpose other than it already did independently, and one skilled in the art would have recognized that the combination could have been implemented through routine engineering producing predictable results.
Claim(s) 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kumar (US20180060965 A1) in view of Roselli (US 20140149283 A1)
As per claim 16, Kumar teaches:
An automated onboarding method comprising the steps of:(a) One of completing and sending a form for a prospective client account through the world wide web to a computer working on behalf of a company; ( see at least: Fig.4 #404 client enter information [0011-12] [0039] the advisor 102 may enter information into the managed package 202, and a web service 118 provided by an internet information services (IIS) server 210 may process an account creation, including communicating with an account opening API 212 of a custodian platform 130 to actually open the account within the custodian's database 214).
(b) after (a), the computer automatedly extracting information from the form, without human assistance, to populate an account of the prospective client of a customer relations management (CRM) account software with at least some of the information and adding one of a customer identifier selected from the group of a customer number and an account number to the account; ( see at least: Fig.4, 406 create new account in CRM [0039] a forms service 154 provided by a forms generation server 220 may automatically generate forms with information captured during user entry to effect the creation of the account. [0042-46] In 330, the custodian may accept and process the forms and return an account number for the new account opened by processing of the forms to the app 144)
(c) after (b), the computer automatedly populating, with at least some of the information based on a decision algorithm of the company, ( see at least: Fig.3B-3C, Fig.4 #408-410 [0034-35] Each custodian may have their own set of forms to be completed and signed by the appropriate parties. The system 100 may integrate with forms automation vendors. The system 100 may use the APIs provided by the forms vendors to create an envelope/bundle with the selected forms and use the appropriate pre-fill APIs to have the forms pre-filled with the data from the system 100. [0017] Custodians may each have a different format and/or method for accepting account opening data [0065] The forms may be generated on the screen and the associated financial account information may automatically get filled into the forms. [0026])
at least one document selected from the group of:(i) a funding form selected from one of a transfer form from a third party company and a funding request from the third party company; (ii) an engagement agreement between the prospective client and the company; and (iii) an account application form to generate a specific account at the company; ( see at least: Fig. 3B #314-316,Fig.4 [0063] Advisors may generate the appropriate forms from the financial account in the system app and send them to clients to get a signature digitally. [0014] to open a brokerage account with a particular custodian, the following information may be collected and submitted to the custodian [0015] Advisors may select product type, product company, and the account type, and/or other attributes for a client product [0047] the advisor 102 and/or investor 104 may opt to fund the account using the app 144 [0049-51] generating request with client and financial account information and send it to the form service to generate forms. )
(d) after (c), the computer automatedly sending the at least one document to the prospective client for signature through the world wide web; ( see at least:Fig.3B #320-322, [0039] A forms package 222 may be created and sent to the client for review and signature. The status of the forms package 222 may be tracked inside the managed package 202, along with a timestamp, until the completion of signatures on all forms. For example, an eSignature service 152 provided by an eSignature web server 230 may provide form signing functionality. )
(e) the prospective customer signing the at least one document and sending back through the world wide web to the computer of the company; and (f) the computer of the company receiving the signed document ( see at least: Fig. 3C #324[0039] A forms package 222 may be created and sent to the client for review and signature. The status of the forms package 222 may be tracked inside the managed package 202, along with a timestamp, until the completion of signatures on all forms. For example, an eSignature service 152 provided by an eSignature web server 230 may provide form signing functionality. Completed (e.g., signed) forms 232 may be stored in CRM cloud 140 and/or within an integrated document management system. )
While Kumar teaches the signed form, the CRM software ( see Fig.3A#310 Advisor logs into CRM. Fig.5A Saleforce [0042], [0039])
Kumar does not explicitly teach if the signed form is the engagement agreement of step (c)(ii), advised of the receipt to activate the account as an active customer account of an active customer and advising a human operator at the company to at least interact with the active customer having successfully automatedly onboarded the active customer account.
However, Rosille teaches if the signed form is the engagement agreement of step (c)(ii), advised of the receipt to activate the account as an active customer account of an active customer ( see at least: Fig.21, [0461] the Terms and Conditions milestone is deemed complete when the customer has been presented/referred to the Terms and Conditions and his/her acceptance has been recorded for non-passive acceptance. [0471-472] this milestone functions to present the customer with an appropriate Terms and Conditions agreement related to the entity as well as product(s) the customer selected. By collecting the input from this milestone, the system may decide whether the application is eligible for activation and, at the very end, send fulfilment request [1402] table 6 shows milestone terms and condition must be completed to activate the account)
It would have been obvious for one ordinary skilled in the art before the effective filing date of present invention to combine the engagement letter feature for the same reasons its useful in Rosille -namely, to review Terms and Conditions and make an informed decision on whether to proceed) ( par.472). Moreover, this is merely a combination of old elements in the art. In the combination, no element would serve a purpose other than it already did independently, and one skilled in the art would have recognized that the combination could have been implemented through routine engineering producing predictable results.
Roselli also teaches advising a human operator at the company to at least interact with the active customer having successfully automatedly onboarded the active customer account. ( See at least: [1098] A branch/third party vendor may receive an advice to issue a welcome package, for example after a particular ‘trigger’ by the customer/staff member (in some embodiments, this only applies to postal options[1075-76] A gift may be initiated from a promotion or account opening. For Manual generation, the system should indicate that the customer is qualified for a promotional/welcome gift. Staff will then fulfill this item manually.).
It would have been obvious for one ordinary skilled in the art before the effective filing date of present invention to combine the manual advising feature for the same reasons its useful in Roselli -namely, the Welcome letter may include Credit Protection, Identity Protection Plus, and/or Credit Keeper information if selected from product configuration (par.1097). Moreover, this is merely a combination of old elements in the art. In the combination, no element would serve a purpose other than it already did independently, and one skilled in the art would have recognized that the combination could have been implemented through routine engineering producing predictable results.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MANAL A. ALSAMIRI whose telephone number is (571)272-5598. The examiner can normally be reached M-F: 9:00 am - 5:00 pm.
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, Shannon Campbell can be reached at 571)272-5587. 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.
/MANAL A. ALSAMIRI/Examiner, Art Unit 3628