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 .
The following is a Final Office Action in response to communications received January 22, 2026. Claim(s) 2-4, 7-10, 13 and 15-17 have been canceled. Claim(s) 1, 5-6, 14 and 20 have been amended. New claim(s) 21-28 have been added. Therefore, claims 1, 5-6, 11-12, 14, and 18-28 are pending and addressed below.
Priority
Application No. 18223781 filed 07/19/2023 Claims Priority from Provisional Application 63390511 , filed 07/19/2022
Applicant Name/Assignee: EquiDeFi Ltd.
Inventor(s): Kesner, Harvey; Bhansali, Mohit
Response to Amendment/Arguments
Drawings
Applicant’s amendments in response to the objection set forth in the previous Office action for failing to comply with 37 CF$ 1.84(p)(5) is sufficient to overcome the objection. The examiner withdraws the objection to the drawings.
Claim Rejections - 35 USC § 101
Applicant's arguments filed 01/22/2026 have been fully considered but they are not persuasive.
In the remarks applicant recites the amended limitations of claim 1 emphasizing the steps “parsing the …data…”, “automatically embedding the identified regulatory requirements into workflow rules…” with independent claims 14 and 20 amended similarly. Applicant argues the human mind cannot reasonably embed …requirements into workflow rules. Applicant is arguing an abstract category not applied in the previous Office action. Applicant’s argument is moot.
In the remarks applicant argues that the “embedding” means the technology does not just store documents but instead governs the transaction ensuring compliance by design and producing verifiable proof that regulators can later review. Thus the amendments add an inventive concept under step 2B by specifying a technical process by which the workflow generator embeds regulatory requirements into workflows. The specific operations including “parsing jurisdictions, standards and regulations data”, “automatically embedding the regulatory requirements as logic based constraints (workflow rules) enforced by the workflow generator”. Applicant’s argument is not persuasive. The parsing of data to identify regulatory requirements in combination with embedding regulatory requirements as constraints recites high level operations with expected outcomes therefore, lacking in technical details of technical implementation that could be considered unconventional technical processes. The parsing of data and embedding of rules as logic based constraints operations can be implemented by any known technical means. When considered as a combination the process is directed toward the abstract idea rather than a particular technical process. Claim 1 recites only applying a workflow generator for use in generating screens implementing the embedding of regulatory requirements where the regulatory requirements are constraints of the abstract idea and not for a particular technical process and therefore, fails to provide significantly more that “apply it” as discussed in Alice for implementing the abstract idea. In claim 1, except for the embedding of regulatory requirement step nothing in the limitations is tied to any technology. With respect to claim 14, although the claim recites the additional elements a system comprising a processor, computer readable memory, a data store comprising a plurality of database architecture (rules database, jurisdiction database, a standards database, a regulation database), a workflow generator software component communicatively coupled with the data store, the additional elements, except for the operations of the workflow generator software, do not perform any operations. The workflow generator software is applied in response to receiving offers requiring regulatory compliance, performs the operations of accessing data from the data store (receiving data), parsing the accessed data (manipulating data), embedding identified regulatory requirements into workflow rules for the intended use to drive the creation of offering documents compliance with regulatory requirements which merely applying technology for implementing the identified abstract idea, without providing any unconventional technical process or significantly more than the identified abstract idea. The rejection is maintained.
In the remarks applicant argues that claim 20, adds specific technical operation of dynamic adaptation by automatically changing without user intervention the workflow when the financial jurisdiction data, financial standards data and/or regulation data changes. Applicant argues that these features go beyond significantly more than the use of generic computers to organize how a human would create a workflow. Applicant points to (¶ 0039, ¶ 0046 ¶ 0051) the specification, which supports regulatory requirements are baked in such that the offeror does not have to know or even be aware of them and keeps users on the rails by presenting only valid options at each workflow step. This workflow ensures that information required for regulatory compliance will be obtained to create proper and completed documents to support compliance offer. Applicant’s argument is not persuasive. The additional elements recited in the claim beyond the abstract idea include a “wizard” applied to generate financial documents, receive a signature and store the financial document – which is well known in the industry (for example docusign) and a workflow generator applied to perform the operations “accessing …embedding regulatory requirements and data from the data store” and “embedding the identified regulatory requirements into workflow rules” for the intended use to drive the creation of compliant financial instruments with regulatory jurisdictions” which similar to claim 1 with respect to the “workflow generator “ merely applies it for use in performing the abstract idea without technical details or description and does not provide significantly more than the use of the “workflow generator” to perform the abstract idea. The steps “receive a change to …jurisdiction, standards and regulation data”, “dynamically changing the workflow and the wizard to reflect the change” is so high level as to be implemented by manual or any other known means for receiving data and changing workflow. The wherein clause which limits the wizard embodied logic to generate financial document, receive electronic signature and store the document merely limits the wizard functions which is for use in performing the legal process of the generated financial document and does not provide significantly more. The rejection is maintained.
In the remarks applicant argues that new claims 21-28 supported by the specification (¶ 0014-0015, ¶ 0021, ¶ 0023, ¶ 0038-0048, ¶ 000052 ¶ 0053) and claims 6-7 illustrate additional patent eligibility. Applicant’s statement is not persuasive. Applicant has not explained how or why the dependent claims 6-7 and 21-28 are patent eligible with does not meet the requirements of a proper rebuttal. The see rejection below.
Claim Rejections - 35 USC § 103
In response to the amendments of claim(s) 1-20 a new ground of rejection has been applied with new reference. See prosecution below.
Claim Objections
Claim 5 and 6 is objected to because of the following informalities:
In reference to Claim(s) 5 and 6:
Dependent claim(s) 5 and 6 depend upon claim 3 which has been cancelled. For examination purposes the examiner is examining claim(s) 5 and 6 as being dependent upon claim 1. Appropriate correction is required.
Claim Interpretation
With respect to the language “offering”, the examiner is interpreting the term in light of the specification (¶ 0004) to be a financial instrument such as shares or bond or securities.
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, 5-6, 11-12, 14, and 18-28 are rejected under 35 U.S.C. § 101 because the instant application is directed to non-patentable subject matter. Specifically, the claims are directed toward at least one judicial exception without reciting additional elements that amount to significantly more than the judicial exception. The rationale for this determination is in accordance with the guidelines of USPTO, applies to all statutory categories, and is explained in detail below.
In reference to Claim(s) 1, 5-6, 11-12 and 21-26:
STEP 1. Per Step 1 of the two-step analysis, the claims are determined to include a method, as in independent Claim 1 and the dependent claims. Such methods fall under the statutory category of "process." Therefore, the claims are directed to a statutory eligibility category.
STEP 2A Prong 1. The claimed invention is directed to an abstract idea without significantly more. Method claim 1 recites a method step(s) 1) receiving input (2) accessing data store 3) parsing data, (4) embedding regulatory requirements into workflow rules (5) generating a dynamic workflow in a wizard screens for the intended use to create regulatory compliant documents. The claimed limitations which under its broadest reasonable interpretation, covers performance of the limitation in the commercial activity, but for the recitation of generic workflow generator. The claimed physical structures (workflow generator) are generic computer components and tools to perform commercial/legal interactions. The claimed workflow generator “generating” workflow and “wizard” are recited at a high level of generality and merely automates functions that could reasonable be performed commercial activity, therefore acting as a generic workflow generator to perform the abstract idea. A “wizard” is an interface tool that guides users through a series of steps to complete task. The specification titled “Offer Creation” discloses (¶0004) discloses an exemplary workflow to “create compliant documents for the offering using a web-based user interface to walk users through one or more of: (1) generation of the offering documents, (2) collection of the conditions precedent for each workflow, and (3) the closing and transfer of funds, and subsequently, the movement of the financial instrument among subsequent owners of the financial instrument whilst (1) documenting and recording on an official registry the transfer, (2) notifying the issuer of the transfer, and/or (3) closing and transfer of funds.” The specification in the background discloses that in the realm of cryptocurrencies, coin offering, tokenization and alternative trading systems rely on blockchain registry with records in the “cloud” and that it is desirable to create regulatory compliant documents that facilitate proof in order to comply and address legal proceedings and/or pronouncements from regulators in digital and non-digital asset verification.(¶ 0017). Accordingly, the focus of the claims in light of the specification is not on a specific improvement in relevant technology, but rather focuses on an “abstract idea” of creating regulatory compliant document for which computers are invoked merely as a tool. Here, as discussed above, it is clear from the Specification (including the claim language) that claim 1 focuses on an abstract idea, and not on an improvement to technology and/or a technical field.
These concepts are enumerated in Section I of the 2019 revised patent subject matter eligibility guidance published in the federal register (84 FR 50) on January 7, 2019) is directed toward abstract category of methods of organizing human activity.
STEP 2A Prong 2: The identified judicial exception is not integrated into a practical application because the claims fail to provide indications of patent eligible subject matter that integrate the alleged abstract idea into a practical application. The additional elements recited in the claim beyond the abstract idea include a “wizard” embodied in a workflow generator comprising successive screens and a workflow generator applied to perform the operations “accessing …embedding regulatory requirements and data from the data store” and “embedding the identified regulatory requirements into workflow rules”. The steps “receiving input…”, “parsing…data” and “embedding …identified regulatory requirements” are not tied to any particular technology for use in performing the recited steps and thus is so high level as to include manual and any known technical means. The focus of the steps (receiving input, parsing data, embedding regulatory requirements) is not directed toward indications of patent eligibility which considered individually as required by MPEP guidance (see MPEP 2106.05 (a)-(c), (e )-(h).)
The operations performed by the workflow generator include “accessing jurisdiction data, standards data and regulations data from a data store” at a high level lacking any technical details, which According to MPEP 2106.05(d) II (see also MPEP 2106.05(g)) the courts have recognized the following computer functions are claimed in a merely generic manner (e.g., at a high level of generality) where technology is merely applied to perform the abstract idea or as insignificant extra-solution activity.
Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); but see DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1258, 113 USPQ2d 1097, 1106 (Fed. Cir. 2014)
Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93
Electronically scanning or extracting data from a physical document, Content Extraction and Transmission, LLC v. Wells Fargo Bank, 776 F.3d 1343, 1348, 113 USPQ2d 1354, 1358 (Fed. Cir. 2014) (optical character recognition)
The additional element beyond the abstract idea workflow generator embodied in a wizard comprising successive screens is recited at a high level lacking technical details to perform the operations generating the screens implementing the embedded regulatory requirements for the intended use to create regulatory jurisdiction, standards compliant document for input of offering (e.g. financial instrument (spec. ¶ 0019, ¶ 0030), digital assets (¶ 0035), and jurisdiction.
The claim limitations and specification lacks technical disclosure on how the generating by the workflow generated embodied in a wizard the successive screens is performed as a technical process, focusing instead on its use for performing the abstract idea. Taking the claim elements separately, the operation performed by the method at each step of the process is purely in terms of results desired and devoid of implementation of details. The claimed steps do not provide any details or a process that could be considered as sufficient to provide a technological implementation or application of/or improvement to this concept or where the technology imposes meaningful limits upon the abstract idea. (i.e. integrated into a practical application).
When the claims are taken as a whole, as an ordered combination, the combination of limitations steps (1)-(3) receiving input, accessing/retrieving business regulatory compliance data and parsing/manipulating data to identify regulatory requirements- do not recite requiring any technology and are as a combination directed toward manipulating and analyzing data in order to identify regulatory requirements for input for document generation. The combination of limitations (1)-(3) and (4)-(5) is directed toward applying a workflow generator embodied in a wizard to embed at a high level identified regulatory requirements of limitations (1)-(3) for use in generating screens to create regulatory jurisdiction, standards and regulations requirements of offering (e.g. financial) documents The claimed limitations merely “apply” the wizard where the functional process for the wizard generation is results oriented without technical details. The combinations of parts is not directed toward any technical process or technological technique or technological solution to a problem rooted in technology.
The Examiner was not able to identify any specific technological processes that goes beyond merely confining the abstract idea in a particular technological environment, which, when considered in the ordered combination with the other steps, could have transformed the nature of the abstract idea previously identified. Accordingly, the additional element (workflow generator) does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. There is no indication in the claim language that the structure and/or the manner in which a workflow generator, wizard successive screen functions operations are changed in any way that goes beyond their ordinary capability or use. The claim provides no technical details regarding how the “generating” operation is performed. Instead, similar to the claims at issue in Intellectual Ventures I LLC v. Capital One Financial Corp., 850 F.3d 1332 (Fed. Cir. 2017), “the claim language . . . provides only a result-oriented solution with insufficient detail for how a computer accomplishes it. Our law demands more.” Intellectual Ventures, 850 F.3d at 1342 (citing Elec. Power Grp. LLC v. Alstom, S.A., 830 F.3d 1350, 1356 (Fed. Cir. 2016)). The claim is directed to an abstract idea.
In addition, when the claims are taken as a whole, as an ordered combination, the combination of steps not integrate the judicial exception into a practical application as the claim process fails to impose meaningful limits upon the abstract idea. This is because the claimed subject matter fails to provide additional elements or combination or elements to apply or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception. The functions recited in the claims recite the concept of accessing records and generating workflows that are implemented by a wizard and outputting which is a process directed toward using technology for a business practice of regulation compliance or document verification.
The integration of workflow generator or wizard screens do not improve upon technology or improve upon any technology related to the claim(s) functionality or capability in how such technology carry out one of their basic functions. The integration of elements do not provide a process that allows the recited technology to perform functions that previously could not be performed. The integration of elements do not provide a process which applies a relationship to apply a new way of using an application. The instant application, therefore, still appears only to implement the abstract idea to the particular technological environments apply what generic computer functionality in the related arts. The steps are still a combination made to access data and generate workflows that are outputted in wizard interface screens and does not provide any of the determined indications of patent eligibility set forth in the 2019 USPTO 101 guidance. The additional steps only add to those abstract ideas using generic functions, and the claims do not show improved ways of, for example, an particular technical function for performing the abstract idea that imposes meaningful limits upon the abstract idea.
Accordingly under step 2A prong 2, the claim limitations when considered individually or as a combination, fail to provide any indications of patent eligible subject matter, according to MPEP guidance (see MPEP 2106.05 (a)-(c), (e )-(h).
(i) an improvement to the functioning of a computer;
(ii) an improvement to another technology or technical field;
(iii) an application of the abstract idea with, or by use of, a
particular machine;
(iv) a transformation or reduction of a particular article to a
different state or thing; or
(v) other meaningful limitations beyond generally linking the
use of the abstract idea to a particular technological environment.
STEP 2B; The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because as discussed above with respect to concepts of the abstract idea into a practical application. The additional elements recited in the claim beyond the abstract idea include a “wizard” embodied in a workflow generator comprising successive screens and a workflow generator applied to perform the operations “accessing …embedding regulatory requirements and data from the data store” and “embedding the identified regulatory requirements into workflow rules”. The specification lacks technical details on how the “workflow generator” performs its operations, instead focusing on the results of its use (¶0004).
As discussed above, under the analysis of step 2A prong 2, Claim 1 recites only applying a workflow generator for use in generating screens implementing the embedding of regulatory requirements where the regulatory requirements are constraints of the abstract idea and not for a particular technical process. The application of the “wizard” embodied in a workflow generator comprising successive screens and a workflow generator applied to perform the operations “accessing …embedding regulatory requirements and data from the data store” and “embedding the identified regulatory requirements into workflow rules”, fails to provide significantly more that “apply it” as discussed in Alice for implementing the abstract idea. In claim 1, except for the embedding of regulatory requirement step nothing in the limitations is tied to any technology.
Accordingly, in light of the USPTO 101 guidance and the Alice 2 step 2B directions, the “workflow generator” generating a “workflow” in a wizard comprising successive screens are not enough to qualify as “significantly more” include “apply it” (or an equivalent) with an abstract idea, mere instructions to implement the abstract idea on a computer or requiring no more than a generic compute to perform generic computer functions that are well understood activities known to the industry. As a result, none of the technology recited by the method claims offers a meaningful limitation beyond generally linking the use of the method to a particular technological environment, that is, implementation via computers. .. . The claim limitations do not recite that claimed “workflow generator” or the generated “wizard” perform more than a high level generic function ... . None of the limitations recite technological implementation details for any of these steps, but instead recite only results desired to be achieved by any and all possible means. .. . Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept.
When the claims are taken as a whole, as an ordered combination, the combination of steps does not add “significantly more” by virtue of considering the steps as a whole, as an ordered combination. All of these computer functions are generic, routine, conventional computer activities that are performed only for their conventional uses. See Elec. Power Grp. v. Alstom S.A., 830 F.3d 1350, 1353 (Fed. Cir. 2016). Also see In re Katz Interactive Call Processing Patent Litigation, 639 F.3d 1303, 1316 (Fed. Cir. 2011) Absent a possible narrower construction of the terms “accessing” or “generating”...”workflow” and “wizard screens” are functions can be achieved by any general purpose computer without special programming. None of these activities are used in some unconventional manner nor do any produce some unexpected result. In short, each step does no more than require a generic computer to perform generic computer functions.
As to the data operated upon, "even if a process of collecting and analyzing information is 'limited to particular content' or a particular 'source,' that limitation does not make the collection and analysis other than abstract." SAP America, Inc. v. Invest Pic LLC, 898 F.3d 1161, 1168 (Fed. Cir. 2018). Considered as an ordered combination, the computer components of Applicant’s claimed functions add nothing that is not already present when the steps are considered separately. The sequence of data reception-analysis modification-transmission is equally generic and conventional. See Ultramercial, Inc. v. Hulu, LLC, 772 F.3d 709, 715 (Fed. Cir. 2014) (sequence of receiving, selecting, offering for exchange, display, allowing access, and receiving payment recited as an abstraction), Inventor Holdings, LLC v. Bed Bath & Beyond, Inc., 876 F.3d 1372, 1378 (Fed. Cir. 2017) (sequence of data retrieval, analysis, modification, generation, display, and transmission), Two-Way Media Ltd. v. Comcast Cable Communications, LLC, 874 F.3d 1329, 1339 (Fed. Cir. 2017) (sequence of processing, routing, controlling, and monitoring). The ordering of the steps is therefore ordinary and conventional. The analysis concludes that the claims do not provide an inventive concept because the additional elements recited in the claims do not provide significantly more than the recited judicial exception.
According to 2106.05 well-understood and routine processes to perform the abstract idea is not sufficient to transform the claim into patent eligibility. As evidence the examiner provides:
The specification discloses:
[0021] The web server 108 may have or have access to a web application 118, a workflow engine 120, a workflow generator 122, and a document generator 124. The web application 118 includes executable software that is configured to interface with the web application 106 of the user workstation 102 to provide a wizard driven by the workflow engine 120. The workflow engine 120 includes software that is configured to provide a menu-driven
workflow presented at the user workstation 102. The workflow may be generated by the workflow generator 122 to include user response-driven screens displayable to the user 104 via a user interface on the user workstation 102, drop-down menus and other points of data entry, and other features that walk the user 104 through the offer creation process, keeping the process "on the rails" so that the documents that are ultimately created by the document generator 124 in support of the offer are regulatory-compliant and meet necessities of the offer. The workflow is generated by the workflow generator 122 to enforce rules for creating the offering.
[0023] The data storage 126 may also contain documents 134 created by or for the workflow, workflow data 136 entered by the user 102 at the user workstation 104 or retrieved from another source, and/or rules 138 enforced by the workflow generator 122 and/or workflow engine 120 as part of creating a regulatory-compliant and investor approvable offer. The documents 134 and/or workflow data 136 may be saved during offer creation, for example in the event that the workflow is interrupted or the user 102 wishes to pause the workflow until a later time or end it altogether. In some embodiments, the document creation may be directed by the user 102 as guided by the workflow engine 120 but in fact occur at the client workstation 104 using the workflow data 136 to create the documents 134. Additionally, or alternatively, the documents 134 and/or workflow data 136 may be saved for recordkeeping in the event of an audit, for example. The rules 138 may include, without limitation, presentation of specific drop-down menus for user entry or selection that are based on previous input by the user, such as information that refines a
previous entry or addresses a regulatory need based on a previous entry.
[0033] The memory 308 may store device software that contains executable instructions to perform operations to implement the web server 108. The memory 308 may also store applications 320 that include one or more of a web application 320a, a workflow engine 320b, a workflow generator 320c, and a document generator 320d. In some embodiments, the web application 320a corresponds to the web application 118, the workflow engine 320b
corresponds to the workflow engine 120, the workflow generator 320c corresponds to the workflow generator 122, and the document generator 320d corresponds to the document generator 124.
[0036] FIG. 5 is an example user interface 500 that presents a workflow implemented by the web application 106 for the user 102 to create an offer for a financial instrument. In the example of FIG. 5, the web application 106 may present or cause the presentation on the user workstation 104 of a succession of screens that comprise a wizard for walking the user 102 through the process of creating the offer. In some embodiments, the workflow is created
by the workflow engine 120, which implements the rules 138 to drive creation of the documents 110 supporting the offer.
[0052] In some embodiments, the rules enforced by the workflow engine may be updated based on events (for example, to ensure compliance with new regulations, business logic, etc.). In such embodiments, the workflow is in fact a dynamic workflow. Modifying the rules seamlessly updates the workflow engine to accord with the new requirements, and causes the user to enter information accordingly without needing to be aware of any changes
that underlie the workflow modification.
[0053] After completing the wizard to the end, documents prepared for the offer may be electronically signed and uploaded as a package. In some instances, the entire, or nearly the entire, set of documents necessary for creating the offer may be generated by simply following the workflow. Eventual integration with a "data room" may permit access by potential investors, where additional documents requested by potential investors may be added, all of which can be provenanced and tracked. This greatly simplifies the offer creation process, eliminating the need for cumbersome emails/faxes/original signatures/countersignatures in both directions, provides provenance for the documents, and ensures that no investor can proceed without the proper compliance-driven documentation.
Additional evidence with respect to applying wizards that it is well known for such wizards to provide in a sequence of screens/pages task-
US Pub No. 2008/0027830 A1 by Johnson et al wherein the prior art teaches “The incoming content is read, validated and imported into a standard rich content database structure. The import process is carried out using a set of wizard-like GUI Screens.”(para 0101); US Pub No. 2007/0168874 A1 by Kloeffer et al -wherein the prior art teaches “operations services can also include an integrated electronic operations handbook, which can include a list of predefined tasks and the actions that are necessary for handling each predefined task, such as when the task has to be performed (event based or time based), the responsible person (role), documentation on the task, and information on the service level agreement…a guided activity transaction, e.g., a wizard, may be provided to help a user perform an administration task, which guides the user through a defined activity.”(para 0066); CA 2557528 A1 by Rathod et al-“Personal Portal & Personal Network Creation Wizard which help personalize the wizard adopts step by step approach to personalize the portal in which steps are carried out the first one being registration of the NetAlter Service and personal information”(0176)
The instant application, therefore, still appears to only implement the abstract ideas to the particular technological environments using what is generic components and functions in the related arts. The claim is not patent eligible.
The remaining dependent claims—which impose additional limitations—also fail to claim patent-eligible subject matter because the limitations cannot be considered statutory. In reference to claims 5-6, 11-12 and 21-26, these dependent claim have also been reviewed with the same analysis as independent claim 1. Dependent claim 5 is directed toward receiving user input to pause wizard, determining whether workflow is at a stop, saving data if workflow stopped and restarting wizard resuming wizard- applying technology to receive user input and saving data-well understood functions in technology to perform a business process. Dependent claim 6 is directed toward implementing escrow service integration by detecting an escrow requirement, initiating communication with third party service escrow service provider and implementing the escrow using the smart contract that enforces when asset is released- directed toward performing a transaction and legal process using technology. Dependent claim 11 is directed toward screens include logic/interface with smart contracts- applying known technology to perform a business process - well understood use of technology in a business process. Dependent claim 12 is directed toward limiting a smart contract to a contract of a decentralized autonomous organization- well understood use of technology in a legal structure. Dependent claim 21 is directed toward encoding regulatory requirements as restraints for permissible workflow paths and restrict impermissible workflow paths in workflow, configure drop down menus and data entry field in workflow screens to present only compliant options with regulatory requirements for input, establish mandatory data collection points based on regulatory requirements- directed toward applying technology to present interactive user interface tools to collect regulation mandatory data according to restriction instructions for presenting workflow interface tools data collection for regulatory compliance- a business process of using technology for controlling collection of mandatory data according to regulations. Dependent claim 22 is directed toward receiving a change in jurisdiction, standards and regulation data which is applied to modify the parsing and identification of regulatory requirements in data collection and document generation of claim 1, -applying technology to comply with changes in regulations. Dependent claim 23 is directed toward presenting a first point of data entry, receiving user input via an interface, accessing data store to obtain second data point, presenting second data point, receiving second user input, accessing data store to obtain third point of data- and continuing workflow for successive data points of data entry and user input until workflow ends- insignificant extra solution activity. Dependent claim 24 is directed toward detecting a requirement for third party service, retrieving data from data store, initiating communication with third party service provider through API- a business process for receiving and transmitting data according to a business process. Dependent claim 25 is directed toward generating document package of compliant documents, applying electronic signature and storing the document – well understood application of technology (e.g. docusign). Dependent claim 26 is directed toward encoding smart contract a condition controlling asset transfer, encoding smart contract qualification conditions that must be verified before asset transfer, executing asset transfer upon verification, recording asset transfer- a legal transfer of assets according to contractual terms and conditions.
The dependent claim(s) have been examined individually and in combination with the preceding claims, however they do not cure the deficiencies of claim 1. Where all claims are directed to the same abstract idea, “addressing each claim of the asserted patents [is] unnecessary.” Content Extraction & Transmission LLC v. Wells Fargo Bank, Nat 7 Ass ’n, 776 F.3d 1343, 1348 (Fed. Cir. 2014). If applicant believes the dependent claims 5-6, 11-12 and 21-26 are directed towards patent eligible subject matter, they are invited to point out the specific limitations in the claim that are directed towards patent eligible subject matter.
In reference to Claim(s) 14, 18-19 and 27:
STEP 1. Per Step 1 of the two-step analysis, the claims are determined to include a system, as in independent Claim 14 and the dependent claims. Such systems fall under the statutory category of "machine." Therefore, the claims are directed to a statutory eligibility category.
STEP 2A Prong 1. The functions of system claim 14 corresponds to steps of method claim 1. Therefore, claim 14 has been analyzed and rejected as being directed toward an abstract idea of the categories of concepts directed toward methods of organizing human activity previously discussed with respect to claim 1.
STEP 2A Prong 2: The identified judicial exception is not integrated into a practical application because the claims fail to provide indications of patent eligible subject matter that integrate the alleged abstract idea into a practical application. The additional elements recited in the claim beyond the abstract idea include a system comprising a processor, computer readable memory, a data store comprising a plurality of database architecture (rules database, jurisdiction database, a standards database, a regulation database), a workflow generator software component communicatively coupled with the data store and a dynamic workflow embodied in a wizard. The data store comprising multi-database architecture. The rules database containing logic workflow rules [data]. The jurisdiction database containing jurisdiction records, jurisdiction data of regulatory jurisdiction that regulate documents [data]. The standards database containing standards records [data] linked to jurisdiction records. The regulations database containing regulation records [data] linked to standards records in standards database.
The workflow generator software component communicatively coupled to the data store beyond the abstract idea applied for embedding regulatory requirements and resident in the memory and for the intended use to generate workflow embodied in a wizard of succession of screens which according to MPEP 2106.05(d) II (see also MPEP 2106.05(g)) the courts have recognized the following computer functions are claimed in a merely generic manner (e.g., at a high level of generality) where technology is merely applied to perform the abstract idea or as insignificant extra-solution activity.
Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); but see DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1258, 113 USPQ2d 1097, 1106 (Fed. Cir. 2014)
Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93
Electronically scanning or extracting data from a physical document, Content Extraction and Transmission, LLC v. Wells Fargo Bank, 776 F.3d 1343, 1348, 113 USPQ2d 1354, 1358 (Fed. Cir. 2014) (optical character recognition)
The additional elements “screens” are applied at a high level to “implement embedded regulatory requirements for the intended use to create offering (financial instruction) documents compliant with regulations and regulatory jurisdictions and standards lacking any technical disclosure.
The limitations “receiving type of offering and jurisdiction…”, “accessing jurisdiction data, standards data and regulations data…” and “parsing the accessed…data” for the intended use to identify regulatory requirements applicable to input offering (financial instrument) type and jurisdiction is not tied to any technology. Therefore, the “receiving”, “accessing” and “parsing” can be performed by any known means and is not directed toward indications of patent eligible subject matter under step 2A as these limitation are directed toward the data acted upon and not any underlying technology. The claim limitations and specification lacks technical disclosure on how the generating of the wizard is performed as a technical process, focusing instead on its use for performing the abstract idea. Taking the claim elements separately, the operation performed by the method at each step of the process is purely in terms of results desired and devoid of implementation of details. The claimed steps do not provide any details or a process that could be considered as sufficient to provide a technological implementation or application of/or improvement to this concept or where the technology imposes meaningful limits upon the abstract idea. (i.e. integrated into a practical application).
When the claims are taken as a whole, as an ordered combination, the combination of limitations functions (1) embedding regulatory requirements and resident in memory and (2)-(5) are directed toward receiving type of offering (financial instrument) and accessing and manipulating jurisdiction, standards and regulations data in order to identify regulatory requirements applicable to the offering (financial instruction) inputted for use in embedding identified regulatory requirements into workflow rules for legal compliance where the workflow generated is “applied” to enforce the regulations in the workflow process and not to provide indications of patent eligible subject matter. The combination of limitations (1)-(5) and (6) is directed toward implementing screens to implement the embedded regulatory requirements for the intended use to create offering (financial instrument) documents compliant with regulations applying a wizard to control the workflow. The claimed limitations merely “apply” the wizard where the functional process for the wizard generation is results oriented without technical details. The combinations of parts is not directed toward any technical process or technological technique or technological solution to a problem rooted in technology but instead to create offering (financial instrument) document that are compliant with regulations – a common business practice.
The Examiner was not able to identify any specific technological processes that goes beyond merely confining the abstract idea in a particular technological environment, which, when considered in the ordered combination with the other steps, could have transformed the nature of the abstract idea previously identified. Accordingly, the additional element (workflow generator) does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. There is no indication in the claim language that the structure and/or the manner in which a workflow generator, wizard successive screen functions operations are changed in any way that goes beyond their ordinary capability or use. The claim provides no technical details regarding how the “generating” operation is performed. Instead, similar to the claims at issue in Intellectual Ventures I LLC v. Capital One Financial Corp., 850 F.3d 1332 (Fed. Cir. 2017), “the claim language . . . provides only a result-oriented solution with insufficient detail for how a computer accomplishes it. Our law demands more.” Intellectual Ventures, 850 F.3d at 1342 (citing Elec. Power Grp. LLC v. Alstom, S.A., 830 F.3d 1350, 1356 (Fed. Cir. 2016)). The claim is directed to an abstract idea.
In addition, when the claims are taken as a whole, as an ordered combination, the combination of steps not integrate the judicial exception into a practical application as the claim process fails to impose meaningful limits upon the abstract idea. . This is because the claimed subject matter fails to provide additional elements or combination or elements to apply or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception. The functions recited in the claims recite the concept of accessing records and generating workflows that are implemented by a wizard and outputting which is a process directed toward using technology for a business practice of regulation compliance or document verification.
The integration of workflow generator or wizard screens do not improve upon technology or improve upon any technology related to the claim(s) functionality or capability in how such technology carry out one of their basic functions. The integration of elements do not provide a process that allows the recited technology to perform functions that previously could not be performed. The integration of elements do not provide a process which applies a relationship to apply a new way of using an application. The instant application, therefore, still appears only to implement the abstract idea to the particular technological environments apply what generic computer functionality in the related arts. The steps are still a combination made to access data and generate workflows that are outputted in wizard interface screens and does not provide any of the determined indications of patent eligibility set forth in the 2019 USPTO 101 guidance. The additional steps only add to those abstract ideas using generic functions, and the claims do not show improved ways of, for example, an particular technical function for performing the abstract idea that imposes meaningful limits upon the abstract idea.
Accordingly under step 2A prong 2, the claim limitations when considered individually or as a combination, fail to provide any indications of patent eligible subject matter, according to MPEP guidance (see MPEP 2106.05 (a)-(c), (e )-(h).
(i) an improvement to the functioning of a computer;
(ii) an improvement to another technology or technical field;
(iii) an application of the abstract idea with, or by use of, a
particular machine;
(iv) a transformation or reduction of a particular article to a
different state or thing; or
(v) other meaningful limitations beyond generally linking the
use of the abstract idea to a particular technological environment.
STEP 2B; The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because as discussed above with respect to concepts of the abstract idea into a practical application. The additional elements recited in the claim beyond the abstract idea include a system comprising a processor, computer readable memory, data store comprising multi-database architecture (rules database, jurisdiction database, standards database, regulations database), a workflow generator software component communicatively coupled with the data store, a dynamic workflow embodied in a wizard comprising successive screens. and data that is accessed and the generating of a workflow embodied in a wizard. The specification lacks technical details on how the “workflow generator” performs its operations, instead focusing on the results of its use (¶0004).
The additional elements, except for the operations of the workflow generator software, do not perform any operations. The workflow generator software is applied in response to receiving offers requiring regulatory compliance, performs the operations of accessing data from the data store (receiving data) which the courts have found to be well understood routine application of technology. The limitation parsing the accessed data (manipulating data) is not tied to any particular technology for implementation. The limitation “embedding identified regulatory requirements into workflow rules” for the intended use to drive the creation of offering documents compliance with regulatory requirements which merely applying technology for implementing the identified abstract idea, without providing any technical process details or significantly more than the identified abstract idea of embedding regulatory requirements into workforce rules applied for the intended use to create offering (financial instrument) documents that are in compliance with jurisdiction regulations.
Accordingly, in light of the USPTO 101 guidance and the Alice 2 step 2B directions, the “workflow generator” generating a “workflow” in a wizard comprising successive screens are not enough to qualify as “significantly more” include “apply it” (or an equivalent) with an abstract idea, mere instructions to implement the abstract idea on a computer or requiring no more than a generic compute to perform generic computer functions that are well understood activities known to the industry. As a result, none of the technology recited by the method claims offers a meaningful limitation beyond generally linking the use of the method to a particular technological environment, that is, implementation via computers. .. . The claim limitations do not recite that claimed “workflow generator” or the generated “wizard” perform more than a high level generic function ... . None of the limitations recite technological implementation details for any of these steps, but instead recite only results desired to be achieved by any and all possible means. .. . Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept.
When the claims are taken as a whole, as an ordered combination, the combination of steps does not add “significantly more” by virtue of considering the steps as a whole, as an ordered combination. All of these computer functions are generic, routine, conventional computer activities that are performed only for their conventional uses. See Elec. Power Grp. v. Alstom S.A., 830 F.3d 1350, 1353 (Fed. Cir. 2016). Also see In re Katz Interactive Call Processing Patent Litigation, 639 F.3d 1303, 1316 (Fed. Cir. 2011) Absent a possible narrower construction of the terms “accessing” or “generating”...”workflow” and “wizard screens” are functions can be achieved by any general purpose computer without special programming. None of these activities are used in some unconventional manner nor do any produce some unexpected result. In short, each step does no more than require a generic computer to perform generic computer functions.
As to the data operated upon, "even if a process of collecting and analyzing information is 'limited to particular content' or a particular 'source,' that limitation does not make the collection and analysis other than abstract." SAP America, Inc. v. Invest Pic LLC, 898 F.3d 1161, 1168 (Fed. Cir. 2018). Considered as an ordered combination, the computer components of Applicant’s claimed functions add nothing that is not already present when the steps are considered separately. The sequence of data reception-analysis modification-transmission is equally generic and conventional. See Ultramercial, Inc. v. Hulu, LLC, 772 F.3d 709, 715 (Fed. Cir. 2014) (sequence of receiving, selecting, offering for exchange, display, allowing access, and receiving payment recited as an abstraction), Inventor Holdings, LLC v. Bed Bath & Beyond, Inc., 876 F.3d 1372, 1378 (Fed. Cir. 2017) (sequence of data retrieval, analysis, modification, generation, display, and transmission), Two-Way Media Ltd. v. Comcast Cable Communications, LLC, 874 F.3d 1329, 1339 (Fed. Cir. 2017) (sequence of processing, routing, controlling, and monitoring). The ordering of the steps is therefore ordinary and conventional. The analysis concludes that the claims do not provide an inventive concept because the additional elements recited in the claims do not provide significantly more than the recited judicial exception.
The system and wizard claimed is described in very general terms and functions (accessing, generating) for accessing data and generating tasks and fails to further provide technical details that would distinguish the claimed system from its generic counterpoints. Accordingly, although a system is claimed, the claim is not truly drawn to a specific system or generated wizard, but rather toward the process of accessing data and generating workflow task for document management. Simply reciting the use of a system is not sufficient to meet the Alice step 2B test. The incidental use of a system used to access data or generate a wizard with task screens does not provide the needed significantly more.
According to 2106.05 well-understood and routine processes to perform the abstract idea is not sufficient to transform the claim into patent eligibility. As evidence the examiner provides:
The specification discloses:
[0021] The web server 108 may have or have access to a web application 118, a workflow engine 120, a workflow generator 122, and a document generator 124. The web application 118 includes executable software that is configured to interface with the web application 106 of the user workstation 102 to provide a wizard driven by the workflow engine 120. The workflow engine 120 includes software that is configured to provide a menu-driven
workflow presented at the user workstation 102. The workflow may be generated by the workflow generator 122 to include user response-driven screens displayable to the user 104 via a user interface on the user workstation 102, drop-down menus and other points of data entry, and other features that walk the user 104 through the offer creation process, keeping the process "on the rails" so that the documents that are ultimately created by the document generator 124 in support of the offer are regulatory-compliant and meet necessities of the offer. The workflow is generated by the workflow generator 122 to enforce rules for creating the offering.
[0022] The web server 108 may include or be configured to access a data storage 126. The data storage 126 may contain, for example, one or more databases or other structured storage of regulatory jurisdictions 128, standards 130, and/or regulations 132 associated with the standards 130. Examples of regulatory jurisdictions 128 may include the Securities and Exchange Commission; FINRA, NASDAQ, NYSE, or other stock, commodities, and currency exchanges; state, local, and other federal agencies, etc. Examples of standards 130 may include industry and/or regulatory standards such as Securities Act of 1933, as amended, Securities Exchange Act of 1934, Investment Company Act or 1940, Investment Advisors Act of 1940, rules and regulations of national securities exchanges or
OTCMarkets, Inc., state and local regulations, federal and state banking and insurance regulations, ISO, PCI DSS, CCSSS, and the like. Examples of regulations 132 associated with the standards 130 may include CCPA, NYCRR, and the like. Jurisdictions, standards, and regulations are not limited to the United States.
[0023] The data storage 126 may also contain documents 134 created by or for the workflow, workflow data 136 entered by the user 102 at the user workstation 104 or retrieved from another source, and/or rules 138 enforced by the workflow generator 122 and/or workflow engine 120 as part of creating a regulatory-compliant and investor approvable offer. The documents 134 and/or workflow data 136 may be saved during offer creation, for example in the event that the workflow is interrupted or the user 102 wishes to pause the workflow until a later time or end it altogether. In some embodiments, the document creation may be directed by the user 102 as guided by the workflow engine 120 but in fact occur at the client workstation 104 using the workflow data 136 to create the documents 134. Additionally, or alternatively, the documents 134 and/or workflow data 136 may be saved for recordkeeping in the event of an audit, for example. The rules 138 may include, without limitation, presentation of specific drop-down menus for user entry or selection that are based on previous input by the user, such as information that refines a
previous entry or addresses a regulatory need based on a previous entry.
[0028] The operating system 216a may include components that enable the user workstation 104 to receive and transmit data via various interfaces (e.g., user controls, communication interface 202, and/or memory input/output devices). The operating system 216a may also process data using the one or more processors 206 to generate outputs based on inputs that are received via the user interface 204. For example, the operating system
216a may provide an execution environment, such as a Java Virtual Machine or Microsoft's Common Language RuntimeTM, for the execution of the applications 220. The operating system 216a may include a presentation component that presents the output (e.g., displays the data on an electronic display, stores the data in memory, transmits the data to another electronic device, etc.). The operating system 216a may include an interface layer that
enables applications to interface with the communication interface 202. The interface layer may comprise public APls, private APls, or a combination of both public APis and private APis. Additionally, the operating system 216a may include other components that perform various other functions generally associated with an operating system.
[0033] The memory 308 may store device software that contains executable instructions to perform operations to implement the web server 108. The memory 308 may also store applications 320 that include one or more of a web application 320a, a workflow engine 320b, a workflow generator 320c, and a document generator 320d. In some embodiments, the web application 320a corresponds to the web application 118, the workflow engine 320b
corresponds to the workflow engine 120, the workflow generator 320c corresponds to the workflow generator 122, and the document generator 320d corresponds to the document generator 124.
[0034] In some embodiments, the data store 316 may store, for example, one or more databases or other structured storage of regulatory jurisdictions 316a (which may correspond to the jurisdictions 128), standards 316b (which may correspond to the standards 130), regulations 316c (which may correspond to the regulations 132) associated with the standards 316b, documents 316d (which may correspond to the documents 134), workflow data 316e (which may correspond to the workflow data 136) and rules 316f (which may correspond to the rules 138).
[0036] FIG. 5 is an example user interface 500 that presents a workflow implemented by the web application 106 for the user 102 to create an offer for a financial instrument. In the example of FIG. 5, the web application 106 may present or cause the presentation on the user workstation 104 of a succession of screens that comprise a wizard for walking the user 102 through the process of creating the offer. In some embodiments, the workflow is created
by the workflow engine 120, which implements the rules 138 to drive creation of the documents 110 supporting the offer.
[0040] In the example shown in FIG. 6, a box 604 appears that requests the name of the broker indicated by the user's selection of the radio button as depicted. Another box 606 appears that requests the user 102 to indicate whether there will be an escrow for investor funds in connection with the offer. If without blockchain, the escrow may be provided by a third-party service using a traditional database, and the escrow can be effected by having a
human being determine when to release items. Where a blockchain is involved, escrow can be implemented using a smart contract on the blockchain that enforces when assets are digitally released, useful if the assets are digital in nature. Alternatively, the smart contract can be triggered by a DAO organization as well. Selection of the corresponding radio button may cause additional information and/or entry points (not shown) to appear, which
correspond to the selection. For example, information related to the escrow (e.g., account number, escrow agent) may be entered. On the other hand, non-selection of the radio button, followed by selection of the "continue" button 608 may cause a new screen to be presented, with a corresponding request for information.
[0052] In some embodiments, the rules enforced by the workflow engine may be updated based on events (for example, to ensure compliance with new regulations, business logic, etc.). In such embodiments, the workflow is in fact a dynamic workflow. Modifying the rules seamlessly updates the workflow engine to accord with the new requirements, and causes the user to enter information accordingly without needing to be aware of any changes
that underlie the workflow modification.
[0053] After completing the wizard to the end, documents prepared for the offer may be electronically signed and uploaded as a package. In some instances, the entire, or nearly the entire, set of documents necessary for creating the offer may be generated by simply following the workflow. Eventual integration with a "data room" may permit access by potential investors, where additional documents requested by potential investors may be added, all of which can be provenanced and tracked. This greatly simplifies the offer creation process, eliminating the need for cumbersome emails/faxes/original signatures/countersignatures in both directions, provides provenance for the documents, and ensures that no investor can proceed without the proper compliance-driven documentation.
Additional evidence with respect to applying wizards that it is well known for such wizards to provide in a sequence of screens/pages task-
US Pub No. 2008/0027830 A1 by Johnson et al wherein the prior art teaches “The incoming content is read, validated and imported into a standard rich content database structure. The import process is carried out using a set of wizard-like GUI Screens.”(para 0101); US Pub No. 2007/0168874 A1 by Kloeffer et al -wherein the prior art teaches “operations services can also include an integrated electronic operations handbook, which can include a list of predefined tasks and the actions that are necessary for handling each predefined task, such as when the task has to be performed (event based or time based), the responsible person (role), documentation on the task, and information on the service level agreement…a guided activity transaction, e.g., a wizard, may be provided to help a user perform an administration task, which guides the user through a defined activity.”(para 0066); CA 2557528 A1 by Rathod et al-“Personal Portal & Personal Network Creation Wizard which help personalize the the wizard adopts step by step approach to personalize the portal in which steps are carried out the first one being registration of the NetAlter Service and personal information”(0176)
The instant application, therefore, still appears to only implement the abstract ideas to the particular technological environments using what is generic components and functions in the related arts. The claim is not patent eligible.
The remaining dependent claims—which impose additional limitations—also fail to claim patent-eligible subject matter because the limitations cannot be considered statutory. In reference to claims 18-19 and 27 these dependent claim have also been reviewed with the same analysis as independent claim 14. Dependent claim(s) 18 isdirected toward applying screens to access data - insignificant extra solution activity of displaying data. Dependent claim 19 is directed toward applying interface technology to include a smart contract - well understood use of technology in a business/legal process. Dependent claim 27 is directed toward presenting a first point of data entry, receiving user input via an interface, accessing data store to obtain second data point, presenting second data point, receiving second user input, accessing data store to obtain third point of data- and continuing workflow for successive data points of data entry and user input until workflow ends- insignificant extra solution activity.
The dependent claim(s) have been examined individually and in combination with the preceding claims, however they do not cure the deficiencies of claim 14. Where all claims are directed to the same abstract idea, “addressing each claim of the asserted patents [is] unnecessary.” Content Extraction & Transmission LLC v. Wells Fargo Bank, Nat 7 Ass ’n, 776 F.3d 1343, 1348 (Fed. Cir. 2014). If applicant believes the dependent claims 18-19 and 27 are directed towards patent eligible subject matter, they are invited to point out the specific limitations in the claim that are directed towards patent eligible subject matter.
In reference to Claim(s) 20 and 28:
STEP 1. Per Step 1 of the two-step analysis, the claims are determined to include a method, as in independent Claim 20 and dependent claim 28. Such methods fall under the statutory category of "process." Therefore, the claim is directed to a statutory eligibility category.
STEP 2A Prong 1. The claimed invention is directed to an abstract idea without significantly more. Method claim 20 recites a method step(s) 1) receiving input 2) accessing data store 2) generating a dynamic workflow in a wizard 3) parsing data to identify regulations (4) embedding regulatory requirements identified into workflow rules (5) generating workflow embodied in a wizard of successive screens 6) receiving change to data 7) changing workflow and wizard to reflect change in data 8) generate financial document with signature 9) store document. The claimed limitations which under its broadest reasonable interpretation, covers performance of the limitation in the commercial activity, but for the recitation of generic workflow generator. The claimed physical structures (workflow generator) are generic computer components and tools to perform commercial/legal interactions. The claimed workflow generator “generating” workflow and “wizard” are recited at a high level of generality and merely automates functions that could reasonable be performed commercial activity, therefore acting as a generic workflow generator to perform the abstract idea. A “wizard” is an interface tool that guides users through a series of steps to complete task. The specification titled “Offer Creation” discloses (¶0004) discloses an exemplary workflow to “create compliant documents for the offering using a web-based user interface to walk users through one or more of: (1) generation of the offering documents, (2) collection of the conditions precedent for each workflow, and (3) the closing and transfer of funds, and subsequently, the movement of the financial instrument among subsequent owners of the financial instrument whilst (1) documenting and recording on an official registry the transfer, (2) notifying the issuer of the transfer, and/or (3) closing and transfer of funds.” The specification in the background discloses that in the realm of cryptocurrencies, coin offering, tokenization and alternative trading systems rely on blockchain registry with records in the “cloud” and that it is desirable to create regulatory compliant documents that facilitate proof in order to comply and address legal proceedings and/or pronouncements from regulators in digital and non-digital asset verification.(¶ 0017). Accordingly, the focus of the claims in light of the specification is not on a specific improvement in relevant technology, but rather focuses on an “abstract idea” of creating regulatory compliant document for which computers are invoked merely as a tool. Here, as discussed above, it is clear from the Specification (including the claim language) that claim 20 focuses on an abstract idea, and not on an improvement to technology and/or a technical field.
These concepts are enumerated in Section I of the 2019 revised patent subject matter eligibility guidance published in the federal register (84 FR 50) on January 7, 2019) is directed toward abstract category of methods of organizing human activity.
STEP 2A Prong 2: The identified judicial exception is not integrated into a practical application because the claims fail to provide indications of patent eligible subject matter that integrate the alleged abstract idea into a practical application. The additional elements recited in the claim beyond the abstract idea include a workflow generator, workflow embodied in a wizard comprising successive screens where the wizard generates financial document, receives …signature and store the financial document. The operations performed by the workflow generator and wizard are not directed toward any underlying technology but rather the generation of regulatory compliance documents that are signed and stored.
The workflow generator applied to perform the operation embedding regulatory requirements and resident in a memory and to generate workflow embodied in a wizard of successive screens. This operation is not directed toward any indications of patent eligibility as the process is not directed toward any indications as provided by MPEP guidance (see MPEP 2106.05 (a)-(c), (e )-(h).)
The steps “receiving input…”, “accessing …data”, “parsing…data”, “receiving a change of …data”, “dynamically changing workflow and the wizard…” are tied to any technology or technical process and are merely steps directed toward identifying regulations to apply to generated financial documents for storage. The claim limitations and specification lacks technical disclosure on how the generating of the wizard is performed as a technical process, focusing instead on its use for performing the abstract idea. Taking the claim elements separately, the operation performed by the method at each step of the process is purely in terms of results desired and devoid of implementation of details. The claimed steps do not provide any details or a process that could be considered as sufficient to provide a technological implementation or application of/or improvement to this concept or where the technology imposes meaningful limits upon the abstract idea. (i.e. integrated into a practical application). The combinations of parts is not directed toward any technical process or technological technique or technological solution to a problem rooted in technology.
The Examiner was not able to identify any specific technological processes that goes beyond merely confining the abstract idea in a particular technological environment, which, when considered in the ordered combination with the other steps, could have transformed the nature of the abstract idea previously identified. Accordingly, the additional element (workflow generator) does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. There is no indication in the claim language that the structure and/or the manner in which a workflow generator, wizard successive screen functions operations are changed in any way that goes beyond their ordinary capability or use. The claim provides no technical details regarding how the “generating” operation is performed. Instead, similar to the claims at issue in Intellectual Ventures I LLC v. Capital One Financial Corp., 850 F.3d 1332 (Fed. Cir. 2017), “the claim language . . . provides only a result-oriented solution with insufficient detail for how a computer accomplishes it. Our law demands more.” Intellectual Ventures, 850 F.3d at 1342 (citing Elec. Power Grp. LLC v. Alstom, S.A., 830 F.3d 1350, 1356 (Fed. Cir. 2016)). The claim is directed to an abstract idea.
In addition, when the claims are taken as a whole, as an ordered combination, the combination of steps not integrate the judicial exception into a practical application as the claim process fails to impose meaningful limits upon the abstract idea. . This is because the claimed subject matter fails to provide additional elements or combination or elements to apply or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception. The functions recited in the claims recite the concept of accessing records and generating workflows that are implemented by a wizard and outputting which is a process directed toward using technology for a business practice of regulation compliance or document verification.
The integration of workflow generator or wizard screens do not improve upon technology or improve upon any technology related to the claim(s) functionality or capability in how such technology carry out one of their basic functions. The integration of elements do not provide a process that allows the recited technology to perform functions that previously could not be performed. The integration of elements do not provide a process which applies a relationship to apply a new way of using an application. The instant application, therefore, still appears only to implement the abstract idea to the particular technological environments apply what generic computer functionality in the related arts. The steps are still a combination made to access data and generate workflows that are outputted in wizard interface screens and does not provide any of the determined indications of patent eligibility set forth in the 2019 USPTO 101 guidance. The additional steps only add to those abstract ideas using generic functions, and the claims do not show improved ways of, for example, an particular technical function for performing the abstract idea that imposes meaningful limits upon the abstract idea.
Accordingly under step 2A prong 2, the claim limitations when considered individually or as a combination, fail to provide any indications of patent eligible subject matter, according to MPEP guidance (see MPEP 2106.05 (a)-(c), (e )-(h).
(i) an improvement to the functioning of a computer;
(ii) an improvement to another technology or technical field;
(iii) an application of the abstract idea with, or by use of, a
particular machine;
(iv) a transformation or reduction of a particular article to a
different state or thing; or
(v) other meaningful limitations beyond generally linking the
use of the abstract idea to a particular technological environment.
STEP 2B; The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because as discussed above with respect to concepts of the abstract idea into a practical application. The additional elements recited in the claim beyond the abstract idea include a workflow generator, workflow embodied in a wizard comprising successive screens where the wizard generates financial document, receives …signature and store the financial document. The specification lacks technical details on how the “workflow generator” performs its operations, instead focusing on the results of its use (¶0004).
Accordingly, in light of the USPTO 101 guidance and the Alice 2 step 2B directions, the “workflow generator” generating a “workflow” in a wizard comprising successive screens are not enough to qualify as “significantly more” include “apply it” (or an equivalent) with an abstract idea, mere instructions to implement the abstract idea on a computer or requiring no more than a generic compute to perform generic computer functions that are well understood activities known to the industry. As a result, none of the technology recited by the method claims offers a meaningful limitation beyond generally linking the use of the method to a particular technological environment, that is, implementation via computers. .. . The claim limitations do not recite that claimed “workflow generator” or the generated “wizard” perform more than a high level generic function ... . None of the limitations recite technological implementation details for any of these steps, but instead recite only results desired to be achieved by any and all possible means. .. . Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept.
When the claims are taken as a whole, as an ordered combination, the combination of steps does not add “significantly more” by virtue of considering the steps as a whole, as an ordered combination. All of these computer functions are generic, routine, conventional computer activities that are performed only for their conventional uses. See Elec. Power Grp. v. Alstom S.A., 830 F.3d 1350, 1353 (Fed. Cir. 2016). Also see In re Katz Interactive Call Processing Patent Litigation, 639 F.3d 1303, 1316 (Fed. Cir. 2011) Absent a possible narrower construction of the terms “accessing” or “generating”...”workflow” and “wizard screens” are functions can be achieved by any general purpose computer without special programming. None of these activities are used in some unconventional manner nor do any produce some unexpected result. In short, each step does no more than require a generic computer to perform generic computer functions.
As to the data operated upon, "even if a process of collecting and analyzing information is 'limited to particular content' or a particular 'source,' that limitation does not make the collection and analysis other than abstract." SAP America, Inc. v. Invest Pic LLC, 898 F.3d 1161, 1168 (Fed. Cir. 2018). Considered as an ordered combination, the computer components of Applicant’s claimed functions add nothing that is not already present when the steps are considered separately. The sequence of data reception-analysis modification-transmission is equally generic and conventional. See Ultramercial, Inc. v. Hulu, LLC, 772 F.3d 709, 715 (Fed. Cir. 2014) (sequence of receiving, selecting, offering for exchange, display, allowing access, and receiving payment recited as an abstraction), Inventor Holdings, LLC v. Bed Bath & Beyond, Inc., 876 F.3d 1372, 1378 (Fed. Cir. 2017) (sequence of data retrieval, analysis, modification, generation, display, and transmission), Two-Way Media Ltd. v. Comcast Cable Communications, LLC, 874 F.3d 1329, 1339 (Fed. Cir. 2017) (sequence of processing, routing, controlling, and monitoring). The ordering of the steps is therefore ordinary and conventional. The analysis concludes that the claims do not provide an inventive concept because the additional elements recited in the claims do not provide significantly more than the recited judicial exception.
According to 2106.05 well-understood and routine processes to perform the abstract idea is not sufficient to transform the claim into patent eligibility. As evidence the examiner provides:
The specification discloses:
[0021] The web server 108 may have or have access to a web application 118, a workflow engine 120, a workflow generator 122, and a document generator 124. The web application 118 includes executable software that is configured to interface with the web application 106 of the user workstation 102 to provide a wizard driven by the workflow engine 120. The workflow engine 120 includes software that is configured to provide a menu-driven
workflow presented at the user workstation 102. The workflow may be generated by the workflow generator 122 to include user response-driven screens displayable to the user 104 via a user interface on the user workstation 102, drop-down menus and other points of data entry, and other features that walk the user 104 through the offer creation process, keeping the process "on the rails" so that the documents that are ultimately created by the document generator 124 in support of the offer are regulatory-compliant and meet necessities of the offer. The workflow is generated by the workflow generator 122 to enforce rules for creating the offering.
[0023] The data storage 126 may also contain documents 134 created by or for the workflow, workflow data 136 entered by the user 102 at the user workstation 104 or retrieved from another source, and/or rules 138 enforced by the workflow generator 122 and/or workflow engine 120 as part of creating a regulatory-compliant and investor approvable offer. The documents 134 and/or workflow data 136 may be saved during offer creation, for example in the event that the workflow is interrupted or the user 102 wishes to pause the workflow until a later time or end it altogether. In some embodiments, the document creation may be directed by the user 102 as guided by the workflow engine 120 but in fact occur at the client workstation 104 using the workflow data 136 to create the documents 134. Additionally, or alternatively, the documents 134 and/or workflow data 136 may be saved for recordkeeping in the event of an audit, for example. The rules 138 may include, without limitation, presentation of specific drop-down menus for user entry or selection that are based on previous input by the user, such as information that refines a
previous entry or addresses a regulatory need based on a previous entry.
[0033] The memory 308 may store device software that contains executable instructions to perform operations to implement the web server 108. The memory 308 may also store applications 320 that include one or more of a web application 320a, a workflow engine 320b, a workflow generator 320c, and a document generator 320d. In some embodiments, the web application 320a corresponds to the web application 118, the workflow engine 320b
corresponds to the workflow engine 120, the workflow generator 320c corresponds to the workflow generator 122, and the document generator 320d corresponds to the document generator 124.
[0036] FIG. 5 is an example user interface 500 that presents a workflow implemented by the web application 106 for the user 102 to create an offer for a financial instrument. In the example of FIG. 5, the web application 106 may present or cause the presentation on the user workstation 104 of a succession of screens that comprise a wizard for walking the user 102 through the process of creating the offer. In some embodiments, the workflow is created
by the workflow engine 120, which implements the rules 138 to drive creation of the documents 110 supporting the offer.
[0052] In some embodiments, the rules enforced by the workflow engine may be updated based on events (for example, to ensure compliance with new regulations, business logic, etc.). In such embodiments, the workflow is in fact a dynamic workflow. Modifying the rules seamlessly updates the workflow engine to accord with the new requirements, and causes the user to enter information accordingly without needing to be aware of any changes
that underlie the workflow modification.
[0053] After completing the wizard to the end, documents prepared for the offer may be electronically signed and uploaded as a package. In some instances, the entire, or nearly the entire, set of documents necessary for creating the offer may be generated by simply following the workflow. Eventual integration with a "data room" may permit access by potential investors, where additional documents requested by potential investors may be added, all of which can be provenanced and tracked. This greatly simplifies the offer creation process, eliminating the need for cumbersome emails/faxes/original signatures/countersignatures in both directions, provides provenance for the documents, and ensures that no investor can proceed without the proper compliance-driven documentation.
Additional evidence with respect to applying wizards that it is well known for such wizards to provide in a sequence of screens/pages task-
US Pub No. 2008/0027830 A1 by Johnson et al wherein the prior art teaches “The incoming content is read, validated and imported into a standard rich content database structure. The import process is carried out using a set of wizard-like GUI Screens.”(para 0101); US Pub No. 2007/0168874 A1 by Kloeffer et al -wherein the prior art teaches “operations services can also include an integrated electronic operations handbook, which can include a list of predefined tasks and the actions that are necessary for handling each predefined task, such as when the task has to be performed (event based or time based), the responsible person (role), documentation on the task, and information on the service level agreement…a guided activity transaction, e.g., a wizard, may be provided to help a user perform an administration task, which guides the user through a defined activity.”(para 0066); CA 2557528 A1 by Rathod et al-“Personal Portal & Personal Network Creation Wizard which help personalize the the wizard adopts step by step approach to personalize the portal in which steps are carried out the first one being registration of the NetAlter Service and personal information”(0176)
The instant application, therefore, still appears to only implement the abstract ideas to the particular technological environments using what is generic components and functions in the related arts. The claim is not patent eligible.
The remaining dependent claims—which impose additional limitations—also fail to claim patent-eligible subject matter because the limitations cannot be considered statutory. In reference to claim(s) 28 this dependent claim has also been reviewed with the same analysis as independent claim 20. Dependent claim 28 is directed toward presenting a first point of data entry, receiving user input via an interface, accessing data store to obtain second data point, presenting second data point, receiving second user input, accessing data store to obtain third point of data- and continuing workflow for successive data points of data entry and user input until workflow ends- insignificant extra solution activity.
The dependent claim(s) have been examined individually and in combination with the preceding claims, however they do not cure the deficiencies of claim 20. Where all claims are directed to the same abstract idea, “addressing each claim of the asserted patents [is] unnecessary.” Content Extraction & Transmission LLC v. Wells Fargo Bank, Nat 7 Ass ’n, 776 F.3d 1343, 1348 (Fed. Cir. 2014). If applicant believes the dependent claim(s) 28 is directed towards patent eligible subject matter, they are invited to point out the specific limitations in the claim that are directed towards patent eligible subject matter.
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 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 and 21-23 is/are rejected under 35 U.S.C. 103 as being unpatentable over WO 2006/036656 A2 by Dubinsky (Dubinsky) in view of US Pub No. 2021/0248166 A1 by Ares (Ares) and further in view of CA 2985424 by Weisz (Weisz)
In reference to Claim 1:
Dubinsky teaches;
(Currently Amended) A method to generate and execute a workflow applying regulatory requirements in a workflow rules-based architecture to generate offering documents compliant with the regulatory requirements ((Dubinsky) in at least Abstract; para 0006, para 0047), the method comprising:
receiving input of type of offering and a jurisdiction in which the offering requires regulatory compliance ((Dubinsky) in at least abstract; FIG. 15; para 0012, para 0019, para 0025, para 0055-0056, para 0058); and
in response to receiving the type of offering and jurisdiction: accessing, at a workflow generator embedding the regulatory requirements, jurisdiction data, standards data, and regulations data from a data store, the data store having a structured storage storing workflow rules relating to the workflow, jurisdiction data including entries of regulatory jurisdictions that regulate documents generated by the workflow, standards data including regulatory standards enforceable in the regulatory jurisdictions, and regulations data including entries of regulations to enforce corresponding regulatory standards among the regulatory standards for one or more of the regulatory jurisdictions, which regulations govern information required to be present in the generated offering documents for compliance; wherein the rules, jurisdiction data, standards data, and regulations data are stored in the structured storage associating one or more of the rules with each regulatory jurisdiction, regulatory standards for the associated regulatory jurisdiction, and regulations for the associated regulatory jurisdiction ((Dubinsky) in at least Abstract; para 0006, para 0012-0014, para 0025-0026, para 0050, para 0054-0056, para 0059, para 0062);…
automatically embedding the identified regulatory requirements into workflow rules enforced by the workflow generator ((Dubinsky) in at least para 0012-0014, para 0025, para 0047-0050, para 0054-0055); and
based on at least the workflow rules and the embedded regulatory requirements, generating by the workflow generator a dynamic workflow embodied in a wizard comprised of a succession of screens, the screens implementing the embedded regulatory requirements to automatically drive the creation of offering documents compliant with the regulatory jurisdictions, regulatory standards, and regulations in the accessed jurisdiction data, standards data, and regulations data for the input type of offering and jurisdiction, such that a user of the wizard cannot deviate from the underlying workflow ((Dubinsky) in at least FIG. 15; para 0047, para 0054-0055)
Dubinsky does not explicitly teach:
…offering documents…
parsing the accessed jurisdiction data, standards data, and regulations data to identify the regulatory requirements applicable to the input offering type and jurisdiction;
Weisz teaches:
…offering documents…((Weisz) in at least para 0061)
parsing the accessed jurisdiction data, standards data, and regulations data to identify the regulatory requirements applicable to the input offering type and jurisdiction ((Weisz) in at least Fig. 13; para 0010, para 0016, , para 0095, para 0034 wherein the prior art teaches system automatically determines class of parties and cross reference eligible parties according to jurisdictions and regulatory requirements; para 0061 wherein the prior art teaches offering is identified, the class of the offering party and offerings by issuers with rules corresponding to each offer, para 0095-0096, para 0121-0122 wherein the prior art teaches populating documents for restricted sales pursuant to regulations, para 0123, para 0127);
Both Dubinsky and Weisz are directed toward generating agreements/contracts with a plurality of documents for the transaction between parties for financial instruments where the system populates contractual information. According to KSR, simple substitution for one known element with another to obtain predictable results is common sense rationale. The prior art Dubinsky contained regulatory compliance generation of contracts for financial offering (financial instrument mortgage type) with differed from the claimed regulatory compliance generation of contracts for financial offering (financial instrument -investment vehicle type ) by the substitution with other regulatory compliance generation of contracts for financial offering (financial instrument). The prior art Weisz provides evidence that the substituted offering (IPO, investment vehicles) and their functions were known in the art. One of ordinary skill in the art could have substituted one known element financial instrument for the generation of a contract in compliance with regulations for another, and the results of the substitution would have been predictable
With respect to the limitation “parsing the accessed jurisdiction data, standards data, and regulations data to identify the regulatory requirements applicable to the input offering type and jurisdiction”, both Dubinsky and Weisz are directed toward generating contracts/agreements related to financial instruments which are regulated according to jurisdiction rules and are directed toward automated system which populate and generate documents for contractual agreements. Weisz teaches the motivation of identifying in different agreements between parties the classes of the parties and financial instruments in order to identify and determine class of parties and cross reference eligible parties according to jurisdictions and regulatory requirements. It would have been obvious to one having ordinary skill before the effective filing date of the claimed invention to modify the contractual document generation process of Dubinsky to include the parsing/classifying of the entities and financial offerings as taught by Weisz since Weisz teaches the motivation of identifying in different agreements between parties the classes of the parties and financial instruments in order to identify and determine class of parties and cross reference eligible parties according to jurisdictions and regulatory requirements.
Ares teaches:
a data store comprising a multi-database architecture having a structured storage ((Ares) in at least Abstract; Fig. 3B; para 0072, para 0082,
parsing the accessed jurisdiction data, standards data, and regulations data to identify the regulatory requirements applicable to the input offering type and jurisdiction ((Ares) in at least Abstract; para 0009-0011, para 0013, para 0015-0017, para 0072, para 0082-0084, para 0242-0243);
Both Dubinsky and Ares teach tables associated with specific rules used for business applications. Ares teaches the motivation of parsing data into unique domain tables in order to identify data sets corresponding to specific domain criteria in order for data to be retrieved according to domain. It would have been obvious to one having ordinary skill before the effective filing date of the claimed invention to expand on the rules table for application applied to documents of Dubinsky to include the multi-architectural database and domain tables as taught by Ares since Ares teaches the motivation of parsing data into unique domain tables in order to identify data sets corresponding to specific domain criteria in order for data to be retrieved according to domain.
In reference to Claim 21:
The combination of Dubinsky, Ares and Weisz discloses the limitations of independent claim 1. Dubinsky further discloses the limitations of dependent claim 21:
(New) The method of claim 1, wherein the embedding comprises:
encoding the regulatory requirements as logic-based constraints that define permissible workflow paths and restrict impermissible workflow paths in the dynamic workflow ((Dubinsky) in at least para 0006 wherein the prior art teaches structure created using programming language binary codes to create linkage between legal text and codes for regulatory structures and legally binding terminology required to construct documents; para 0025-0026, para 0028-0029, para 0035, para 0037, para 0046, para 0048, para 0050);
configuring drop-down menus and data entry fields in the workflow screens to present only options compliant with the regulatory requirements for the input offering type and jurisdiction ((Dubinsky) in at least para 0027-0032); and
establishing mandatory data collection points based on the regulatory requirements such that the dynamic workflow cannot proceed without obtaining information required for regulatory compliance.((Dubinsky) in at least para 0035 wherein the prior art teaches rules includes sub-rule processing which include “none”, “pass”, “fail”, “passfail”, “indeterminate”, “passindeterminate”, “failindeterminate” and “passfailindeterminate”; para 0048, para 0054-0055, para 0062)
In reference to Claim 22:
The combination of Dubinsky, Ares and Weisz discloses the limitations of independent claim 1. Dubinsky further discloses the limitations of dependent claim 22:
(New) The method of claim 1 (see rejection of claim 1 above), further comprising:
receiving a change in the jurisdiction data, standards data, or regulations data, wherein the workflow generator dynamically modifies the workflow in response to the change …((Dubinsky) in at least para 0030, para 0062)
Dubinsky does not explicitly teach:
…modifies the workflow in response to the change by parsing the changed data to identify updated regulatory requirements corresponding to the changed data and embedding the updated regulatory requirements into the workflow without requiring user awareness of regulatory changes reflected in the changed data.
Ares teaches:
receiving a change in the jurisdiction data, standards data, or regulations data, wherein the workflow generator dynamically modifies the workflow in response to the change by parsing the changed data to identify updated regulatory requirements corresponding to the changed data and embedding the updated regulatory requirements into the workflow without requiring user awareness of regulatory changes reflected in the changed data. ((Ares) in at least FIG. 74A-B; Abstract; para 0009-0011, para 0013, para 0015-0017, para 0052 wherein the prior art teaches the server continuously and/or periodically retrieve data to parse and unify data collected before and for use of revising nodal network para 0071-0073, para 0058, para 0082-0084, para 0095, para 0107, para 0109, para 0237, para 0242-0243)
Both Dubinsky and Ares teach tables associated with specific rules used for business applications. Ares teaches the motivation of server learning techniques to continuously updating the nodal network to reflect latest state of collected data which includes atomic items (e.g. regulations-para 0242) added and continuously monitor state changes to detect issues using a defined set of rules. It would have been obvious to one having ordinary skill before the effective filing date of the claimed invention to expand on the rules table for application applied to documents of Dubinsky to include continuous collected of data and atomic items added to domain tables that require updating as taught by Ares since Ares teaches the motivation of motivation of server learning techniques to continuously updating the nodal network to reflect latest state of collected data which includes atomic items (e.g. regulations-para 0242) added and continuously monitor state changes to detect issues using a defined set of rules.
In reference to Claim 23:
The combination of Dubinsky, Ares and Weisz discloses the limitations of independent claim 1. Dubinsky further discloses the limitations of dependent claim 23:
(New) The method of claim 1 (see rejection of claim 1 above), wherein the workflow comprises:
presenting a first point of data entry in the user interface ((Dubinsky) in at least para 0027-0031, para 0047);
receiving first user input via the user interface at the first point of data entry ((Dubinsky) in at least para 0053);
in response to the first user input, accessing the data store to obtain a second point of data entry based on the first user input in accordance with a first workflow rule associated with the first user input, wherein the first workflow rule is associated in the data store with one of the regulatory jurisdictions, regulatory standards for the associated regulatory jurisdiction, and regulations for the associated regulatory jurisdiction ((Dubinsky) in at least para 0054-0057);
presenting the second point of entry in the user interface ((Dubinsky) in at least para 0047, para 0054-0055);
receiving second user input via the user interface at the second point of data entry ((Dubinsky) in at least para 0047, para 0054-0055, para 0059);
in response to the second user input, accessing the data store to obtain a third point of data entry based on the second user input in accordance with a second workflow rule associated with the second user input, wherein the second workflow rule is associated in the data store with one of the regulatory jurisdictions, regulatory standards for the associated regulatory jurisdiction, and regulations for the associated regulatory jurisdiction ((Dubinsky) in at least para 0047, para 0054-0055); and
continuing the workflow for successive points of data entry and corresponding user input, each successive point of data entry being based on the just-previous user input ((Dubinsky) in at least para 0047, para 0054-0055);
driven by workflow rules associated with respective user input and associated in the data store with regulatory jurisdictions, regulatory standards for the associated regulatory jurisdictions, and regulations for the associated regulatory jurisdictions, until the workflow reaches an end defined for the compliant offering. ((Dubinsky) in at least para 0025, para 0027, para 0047-0048, para 0052, para 0054-0055)
Claim(s) 5 is/are rejected under 35 U.S.C. 103 as being unpatentable over WO 2006/036656 A2 by Dubinsky (Dubinsky) in view of US Pub No. 2021/0248166 A1 by Ares (Ares), in view of CA 2985424 by Weisz (Weisz) as applied to claim 1 above, and further in view of EP 1785856 B1 by Krebs (Krebs)
In reference to Claim 5:
The combination of Dubinsky, Ares and Weisz discloses the limitations of independent claim 1. Dubinsky further discloses the limitations of dependent claim 5:
(currently amended) The method of claim 3 [1] (see rejection of claim 1 above), comprising:
Dubinsky does not explicitly teach:
at the workflow engine, receiving user input to pause the wizard; and
responsive to receiving the user input to pause;
determining at the workflow engine whether the workflow is at a stop; and
if the workflow is at a stop, saving the data of the workflow in the data store, such that the workflow engine can restart the wizard with the saved data such that the user can resume the wizard at the stop.
Krebs teaches:
at the workflow engine, receiving user input to pause the wizard ((Krebs) in at least para 0060); and
responsive to receiving the user input to pause ((Krebs) in at least para 0060-0062);
determining at the workflow engine whether the workflow is at a stop ((Krebs) in at least para 0060-0063); and
if the workflow is at a stop, saving the data of the workflow in the data store, such that the workflow engine can restart the wizard with the saved data such that the user can resume the wizard at the stop ((Krebs) in at least para 0060-0067, para 0069-0072).
Both Dubinsky and Krebs are directed toward applying wizard interface tools to walk users through processes. Krebs teaches the motivation of proving a pause button in order to allow a user to pause a wizard from currently executing a step or to wait for a currently executing step to finish. Krebs teaches that such steps that the pause function can be applied is to allow the wizard to batch data into storage and then resume the execution of the wizard under control of the batch process manager. It would have been obvious to one having ordinary skill before the effective filing date of the claimed invention to modify the wizard functions of Dubinsky to include a pause function as taught by Krebs since Krebs teaches the motivation of proving a pause button in order to allow a user to pause a wizard from currently executing a step or to wait for a currently executing step to finish.
Claim(s) 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over WO 2006/036656 A2 by Dubinsky (Dubinsky) in view of US Pub No. 2021/0248166 A1 by Ares (Ares), in view of CA 2985424 by Weisz (Weisz) as applied to claim 1 above, and further in view of US Pub No. 2023/0091805 A1 by Wolfberg (Wolfberg)
In reference to Claim 6:
The combination of Dubinsky, Ares and Weisz discloses the limitations of independent claim 1. Dubinsky further discloses the limitations of dependent claim 6:
(Currently Amended) The method of claim 3 [1] (see rejection of claim 1 above),
Dubinsky does not explicitly teach:
wherein at least one of the succession of screens embodies third-party escrow service integration logic to access a third party third-party escrow service and logic to interface with a smart contract; and
wherein the workflow generator implements the third-party escrow service integration logic to perform operations implementing escrow by the third-party escrow service that comprise:
detecting, from user input, a requirement for third-party escrow;
automatically initiating communication with the selected third-party service provider; and
implementing the escrow using the smart contract on a blockchain that enforces when assets subject to the offering are digitally released.
Wolfberg teaches:
wherein at least one of the succession of screens embodies third-party escrow service integration logic to access a third party third-party escrow service and logic to interface with a smart contract ((Wolfberg) in at least FIG. 2-6; para 0005, para 0045, para 0047, para 0050, para 0053, para 0055) ; and
wherein the workflow generator implements the third-party escrow service integration logic to perform operations implementing escrow by the third-party escrow service ((Wolfberg) in at least para 0005, para 0056, para 0060, para 0065) that comprise:
detecting, from user input, a requirement for third-party escrow ((Wolfberg) in at least Fig. 4; para 0026, para 0055-0056);
automatically initiating communication with the selected third-party service provider ((Wolfberg) in at least para 0005, para 0027, para 0060); and
implementing the escrow using the smart contract on a blockchain that enforces when assets subject to the offering are digitally released ((Wolfberg) in at least FIG. 2-6; para 0005, para 0045, para 0047, para 0050, para 0053, para 0055-0056, para 0060).
Both Dubinsky and Wolfberg are directed toward applying a wizard for providing details of deal specifics. Wolfberg teaches the motivation of setting up escrow, as escrow agreements are implemented in offering agreements as custody funds defined in the workflow where exchange, receipt and/or disbursement are enacted by a third party or other contracting parties according to smart contract parameters. It would have been obvious to one having ordinary skill before the effective filing date of the claimed invention to modify the contractual document generation process of Dubinsky to include setting up escrow custody funds as taught by Wolberg since Wolfberg teaches the motivation of setting up escrow, as escrow agreements are implemented in offering agreements as custody funds defined in the workflow where exchange, receipt and/or disbursement are enacted by a third party or other contracting parties according to smart contract parameters.
Claim(s) 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over WO 2006/036656 A2 by Dubinsky (Dubinsky) in view of US Pub No. 2021/0248166 A1 by Ares (Ares), in view of CA 2985424 by Weisz (Weisz), as applied to claim 1 above and further in view of US Pub No. 2014/0089185 A1 by Desai et al. (Desai)
In reference to Claim 11:
The combination of Dubinsky, Ares and Weisz discloses the limitations of independent claim 1. Dubinsky further discloses the limitations of dependent claim 11:
(Original) The method of claim 1 (see rejection of claim 1 above),
Garcia does not explicitly teach:
wherein at least one of the succession of screens embodies logic to access information in any one of a digital wallet, escrow wallet, or token wallet.
Desai teaches:
wherein at least one of the succession of screens embodies logic to access information in any one of a digital wallet, escrow wallet, or token wallet ((Desai) in at least para 0088-0089, para 0117, para 0125, para 0144, para 0454-0457).
According to KSR, simple substitution of one known element for another to obtain predictable results is common sense obvious rationale. The prior art Dubinsky contained plurality of exemplary services accessible via wizard process which differed from the claimed device by the substitution of specific category of services which entail wallet services. The prior art Desai provides evidence that such substituted third party services and providers and their functions were known in the art. Accordingly, based on the teaching of Desai, one of ordinary skill in the art could have substituted one known third party services provider for another, and the results of the substitution would have been predictable.
Both Dubinsky and Desai are directed toward providing access to services with wizard utility ecosystems. Desai teaches the motivation of applying wizards as utility tools in order to access different services which can include digital wallet services from a set of different services. It would have been obvious to one having ordinary skill before the effective filing date of the claimed invention to modify the services available for accessing using wizard tools of Dubinsky to include wallet services as taught by Desai since Desai teaches the motivation of applying wizards as utility tools in order to access different services which can include digital wallet services from a set of different services.
Claim(s) 12 and 26 is/are rejected under 35 U.S.C. 103 as being unpatentable over WO 2006/036656 A2 by Dubinsky (Dubinsky) in view of US Pub No. 2021/0248166 A1 by Ares (Ares), in view of CA 2985424 by Weisz (Weisz), as applied to claim 1 above, and further in view of US Pub No. 2017/0232300 A1 by Tran et al. (Tran)
In reference to Claim 12:
The combination of Dubinsky, Ares and Weisz discloses the limitations of independent claim 1. Dubinsky further discloses the limitations of dependent claim 12
(Original) The method of claim 1 (see rejection of claim 1 above),
Dubinsky does not explicitly teach:
wherein at least one of the succession of screens embodies logic to interface with a smart contract.
Tran teaches:
wherein at least one of the succession of screens embodies logic to interface with a smart contract. ((Tran) in at least para 0122-0123, para 0134)
Both Dubinsky and Tran are directed toward generating agreements/contracts with a plurality of documents for the transaction between parties for financial instruments where the system populates contractual information. According to KSR, simple substitution for one known element with another to obtain predictable results is common sense rationale. The prior art Dubinsky contained regulatory compliance generation of contracts for financial offering with differed from the claimed smart contracts for financial offering (financial instrument -investment vehicle type ) by the substitution smart contracts with generic contracts for financial offering (financial instrument). The prior art Tran provides evidence that the substituted smart contract and their functions were known in the art. One of ordinary skill in the art could have substituted one known element financial instrument for the generation of a contract in compliance with regulations for another, and the results of the substitution would have been predictable
Both Dubinsky and Tran are directed toward utilizing wizards as digital assistance to walk users through processes generating contracts. Tran teaches the motivation of applying wizards in order to provide to the user a sequence of steps and pages to allow a user to fill out information that follow the legal digital assistant requirements as it relates to a smart contract agreement to be legally enforceable. It would have been obvious to one having ordinary skill before the effective filing date of the claimed invention to modify the utilization of the digital assistant wizard for generating contracts of Dubinsky to include utilizing digital assistant wizards to provide a sequence of steps for information required provided in a list of step for a smart contract of Tran since Tran teaches the motivation of applying wizards in order to provide to the user a sequence of steps and pages to allow a user to fill out information that follow the legal digital assistant requirements as it relates to a smart contract agreement to be legally enforceable.
In reference to Claim 26:
The combination of Dubinsky, Ares, Weisz and Tran discloses the limitations of dependent claim 12. Dubinsky further discloses the limitations of dependent claim 26:
(New) The method of claim 12 (see rejection of claim 12 above), further comprising:
Dubinsky does not explicitly teach:
encoding into the smart contract a condition controlling asset transfer pursuant to the offering to comply with applicable regulations;
encoding into the smart contract investor qualification conditions that must be verified before asset transfer pursuant to the offering;
upon verifying the investor qualification conditions, automatically executing the asset transfer without requiring manual intervention; and
recording the asset transfer on a blockchain tracking database with timestamps and party identifiers for regulatory audit purposes.
Tran teaches:
encoding into the smart contract a condition controlling asset transfer pursuant to the offering to comply with applicable regulations ((Tran) in at least para 0122-0123, para 0134, para 0138, para 0197, para 0199, para 0218);
encoding into the smart contract investor qualification conditions that must be verified before asset transfer pursuant to the offering ((Tran) in at least para 0121, para 0132, para 0149, para 0152-0153);
upon verifying the investor qualification conditions, automatically executing the asset transfer without requiring manual intervention ((Tran) in at least para 0151, para 0153, para 0202, para 0204); and
recording the asset transfer on a blockchain tracking database with timestamps and party identifiers for regulatory audit purposes ((Tran) in at least para 0151, para 0202, para 0208, para 0210, para 0213)
Both Dubinsky and Tran are directed toward utilizing wizards as digital assistance to walk users through processes generating contracts for financial transaction. Tran teaches the motivation that it is known in the art to code smart contracts which are applied to verify transaction eligibility and proof of ownership of assets in a transfer transaction that is tracible for audits. It would have been obvious to one having ordinary skill before the effective filing date of the claimed invention to modify the utilization of the digital assistant wizard for generating contracts of Dubinsky to include utilizing digital assistant wizards to encode smart contracts as taught by Tran since Tran teaches the motivation that it is known in the art to code smart contracts which are applied to verify transaction eligibility and proof of ownership of assets in a transfer transaction that is tracible for audits.
Claim(s) 24 is/are rejected under 35 U.S.C. 103 as being unpatentable over WO 2006/036656 A2 by Dubinsky (Dubinsky) in view of US Pub No. 2021/0248166 A1 by Ares (Ares), in view of CA 2985424 by Weisz (Weisz), as applied to claim 1 above, and further in view of US Pub No. 2021/0073290 A1 by Hunter (Hunter)
In reference to Claim 24:
The combination of Dubinsky, Ares and Weisz discloses the limitations of independent claim 1. Dubinsky further discloses the limitations of dependent claim 24:
(New) The method of claim 1 (see rejection of claim 1 above), wherein the workflow generator implements third-party service integration logic comprising:
Dubinsky does not explicitly teach:
detecting, from user input, a requirement for a third-party service;
retrieving from the data store third-party service provider data including one or more of provider or account identification; and
automatically initiating communication with a third-party service provider identified in the third-party service provider data through an application programming interface (API).
Hunter teaches:
detecting, from user input, a requirement for a third-party service ((Hunter) in at least para 0052, para 0064-0065, para 0086, para 0093, para 0097, para 0099);
retrieving from the data store third-party service provider data including one or more of provider or account identification ((Hunter) in at least para 0064, para 0084, para 0088, para 0097, para 0103, para 0219, para 0253, para 0365); and
automatically initiating communication with a third-party service provider identified in the third-party service provider data through an application programming interface (API).((Hunter) in at least para 0108, para 0160-0161, para 0231, para 0253-0257, para 0365-0366)
Both Dubinsky and Hunter are directed toward contract/document creation. Hunter teaches the motivation of obtaining of a plurality of entities identifiers associated with the contract generation in order to when parsing the fields of the document to generate a set of governing conditions using identifiers from the document that includes obligations to allocate resources and a failure penalty set forth in the document. It would have been obvious to one having ordinary skill before the effective filing date of the claimed invention to expand on the generation of legal documents of Dubinsky to include obtaining identifiers of third party entities as taught by Hunter since Hunter teaches the motivation of obtaining of a plurality of entities identifiers associated with the contract generation in order to when parsing the fields of the document to generate a set of governing conditions using identifiers from the document that includes obligations to allocate resources and a failure penalty set forth in the document.
With respect to the initiation of communication through API limitation, both Dubinsky and Hunter teach applying interface technology for communication of data. Hunter teaches the motivation of applying API of a modeling application in order for the AI system to change program state without performing operations used by the smart contract. It would have been obvious to one having ordinary skill before the effective filing date of the claimed invention to modify the details of the interface as taught by Dubinsky to include API technology as taught by Hunter since Hunter teaches the motivation of applying API of a modeling application in order for the AI system to change program state without performing operations used by the smart contract.
Claim(s) 25 is/are rejected under 35 U.S.C. 103 as being unpatentable over WO 2006/036656 A2 by Dubinsky (Dubinsky) in view of US Pub No. 2021/0248166 A1 by Ares (Ares), in view of CA 2985424 by Weisz (Weisz), as applied to claim 1 above, and further in view of in view of US Pub No. 2007/0250769 A1 by Bass et al. (Bass)
In reference to Claim 25:
The combination of Dubinsky, Ares and Weisz discloses the limitations of independent claim 1. Dubinsky further discloses the limitations of dependent claim 25:
(New) The method of claim 1 (see rejection of claim 1 above), further comprising:
generating a digital document package comprising all compliant offering documents completed for the offering type and jurisdiction ((Dubinsky) in at least FIG. 15; para 0047, para 0054-0055);
Dubinsky does not explicitly teach:
for any of the completed compliant offering documents that require signature, applying electronic signature request logic to the completed compliant offering documents that requiring signature; and
storing the digital document package in a data room data structure.
Bass teaches:
generating a digital document package comprising all compliant offering documents completed for the offering type and jurisdiction ((Bass) in at least FIG. 5-7; para 0050-0054, para 0057, para 0062, para 0065-0066)
for any of the completed compliant offering documents that require signature, applying electronic signature request logic to the completed compliant offering documents that requiring signature ((Bass) in at least para 0103-0120, para 0132-0133, para 0148-0149, para 0158); and
storing the digital document package in a data room data structure ((Bass) in at least para 0103-0120, para 0132-0133, para 0148-0149, para 0158).
Both Dubinsky and Bass are directed toward applying wizard software for workflow processes. Bass teaches the motivation of a wizard process which allows for editing in order to provide a means to change the rules that drive the creation of document compliant with the created document requirements. It would have been obvious to one having ordinary skill before the effective filing date of the claimed invention to modify the contractual document generation process of Dubinsky to include a means to edit the wizard workflow process as taught Bass since Bass teaches the motivation of a wizard process which allows for editing in order to provide a means to change the rules that drive the creation of document compliant with the created document requirements.
Claim(s) 14 and 27 is/are rejected under 35 U.S.C. 103 as being unpatentable over WO 2006/036656 A2 by Dubinsky (Dubinsky) in view of US Pub No. 2021/0248166 A1 by Ares (Ares) and further in view of US Pub No. 2011/0078059 A1 by Chambers et al (Chambers)
In reference to Claim 14:
Dubinsky teaches:
(Currently Amended) A system to generate and execute a workflow applying regulatory requirements in a workflow rules-based architecture to generate offering documents compliant with the regulatory requirements ((Dubinsky) in at least Abstract, para 0006, para 0008) the system comprising:
a processor ((Dubinsky) in at least para 0006, para 0051);
a computer readable memory ((Dubinsky) in at least para 0061);
a data store …((Dubinsky) in at least para 0061), storing
a rules database [tables] containing conditional logic workflow rules relating to the workflows ((Dubinsky) in at least para 0013-0014, para 0052)…
a standards database [table] containing standards records relationally linked to jurisdiction records in the jurisdictions database through jurisdiction-to-standards associations, the standards records including standards data of regulatory standards enforceable in the regulatory jurisdictions ((Dubinsky) in at least para 0019-0021; Table 1 wherein the prior art teaches script rule, default rule and comparison rule for conditions and properties of documents);…
a workflow generator software component embedding the regulatory requirements and resident in the memory, communicatively coupled with the data store and configured to generate a dynamic workflow embodied in a wizard comprised of a succession of screens [intended use] ((Dubinsky) in at least Fig. 15, Fig. 18; para 0025, para 0027, para 0047-0048, para 0052, para 0054-0055), wherein the workflow comprises:
in response to receiving a type of offering and a jurisdiction in which the offering requires regulatory compliance ((Dubinsky) in at least abstract; FIG. 15; para 0012, para 0019, para 0025, para 0055-0056, para 0058):
accessing jurisdiction data, standards data, and regulations data from the data store ((Dubinsky) in at least Abstract; para 0006, para 0012-0014, para 0025-0026, para 0050, para 0054-0056, para 0059, para 0062);…
automatically embedding the identified regulatory requirements into workflow rules enforced by the workflow generator ((Dubinsky) in at least para 0012-0014, para 0025, para 0047-0050, para 0054-0055);
wherein the screens implement the embedded regulatory requirements to automatically drive the creation of offering documents compliant with the regulatory jurisdictions, regulatory standards, and regulations in the accessed jurisdiction data, standards data, and regulations data for the input type of offering and jurisdiction, such that a user of the wizard cannot deviate from the underlying workflow ((Dubinsky) in at least FIG. 15; para 0047, para 0054-0055)
Dubinsky does not explicitly teach:
a data store comprising a multi-database architecture having a structured storage
a jurisdictions database containing jurisdiction records, including jurisdiction data of regulatory jurisdictions that regulate offering documents generated by the workflow;
a regulations database containing regulation records relationally linked to standards records in the standards database through standards-to-regulations associations, the regulation records including regulations data of regulations to enforce associated standards for one or more of the regulatory jurisdictions, which regulations govern information required to be present in the generated offering documents for regulatory compliance; and
…offering documents…
parsing the accessed jurisdiction data, standards data, and regulations data to identify the regulatory requirements applicable to the input offering type and jurisdiction;
Ares teaches:
a data store comprising a multi-database architecture having a structured storage ((Ares) in at least Abstract; Fig. 3B; para 0072, para 0082,
parsing the accessed jurisdiction data, standards data, and regulations data to identify the regulatory requirements applicable to the input offering type and jurisdiction ((Ares) in at least Abstract; para 0009-0011, para 0013, para 0015-0017, para 0072, para 0082-0084, para 0242-0243);
Both Dubinsky and Ares teach tables associated with specific rules used for business applications. Ares teaches the motivation of parsing data into unique domain tables in order to identify data sets corresponding to specific domain criteria in order for data to be retrieved according to domain. It would have been obvious to one having ordinary skill before the effective filing date of the claimed invention to expand on the rules table for application applied to documents of Dubinsky to include the multi-architectural database and domain tables as taught by Ares since Ares teaches the motivation of parsing data into unique domain tables in order to identify data sets corresponding to specific domain criteria in order for data to be retrieved according to domain.
Chambers teaches:
a jurisdictions database containing jurisdiction records, including jurisdiction data of regulatory jurisdictions that regulate offering documents generated by the workflow ((Chambers) in at least para 0023-0024, para 0066, para 0077);
a regulations database containing regulation records relationally linked to standards records in the standards database through standards-to-regulations associations, the regulation records including regulations data of regulations to enforce associated standards for one or more of the regulatory jurisdictions, which regulations govern information required to be present in the generated offering documents for regulatory compliance ((Chambers) in at least para 0024, para 0028, para 0079, para 0114); and
…offering documents…((Chambers) in at least para 0070- 0073, para 0077)
Both Dubinsky and Chambers are directed toward legal and regulatory activity associated with specific rules used for business applications. Chambers teaches the motivation of applying suitable data structures such as databased for providing regulatory rules references and jurisdiction requirements with respect to securities transactions/activities. It would have been obvious to one having ordinary skill before the effective filing date of the claimed invention to expand on the rules table for application applied to documents of Dubinsky to include the regulatory and jurisdiction reference integrated databases of Chambers since Chambers teaches the motivation of applying suitable data structures such as databased for providing regulatory rules references and jurisdiction requirements with respect to securities transactions/activities.
With respect to “offerings”, According to KSR, simple substitution for one known element with another to obtain predictable results is common sense rationale. The prior art Dubinsky contained regulatory compliance generation of contracts for financial offering (financial instrument mortgage type) with differed from the claimed regulatory compliance generation of contracts for financial offering (financial instrument -investment vehicle type ) by the substitution with other regulatory compliance generation of contracts for financial offering (financial instrument). The prior art Chambers provides evidence that the substituted offering (IPO, investment vehicles) for agreements and their functions were known in the art. One of ordinary skill in the art could have substituted one known element financial instrument for the generation of a contract in compliance with regulations for another, and the results of the substitution would have been predictable
In reference to Claim 27:
The combination of Dubinsky, Ares and Chambers discloses the limitations of independent claim 14. Dubinsky further discloses the limitations of dependent claim 27
(New) The system of claim 14 (see rejection of claim 14 above), wherein the workflow further comprises:
presenting a first point of data entry in the user interface ((Dubinsky) in at least para 0027-0031, para 0047);
receiving first user input via the user interface at the first point of data entry ((Dubinsky) in at least para 0053);
in response to the first user input, accessing the data store to obtain a second point of data entry based on the first user input in accordance with a first workflow rule associated with the first user input, wherein the first workflow rule is associated in the data store with one of the regulatory jurisdictions, regulatory standards for the associated regulatory jurisdiction, and regulations for the associated regulatory jurisdiction ((Dubinsky) in at least para 0054-0057);
presenting the second point of entry in the user interface ((Dubinsky) in at least para 0047, para 0054-0055);
receiving second user input via the user interface at the second point of data entry ((Dubinsky) in at least para 0047, para 0054-0055, para 0059);
in response to the second user input, accessing the data store to obtain a third point of data entry based on the second user input in accordance with a second workflow rule associated with the second user input, wherein the second workflow rule is associated in the data store with one of the regulatory jurisdictions, regulatory standards for the associated regulatory jurisdiction, and regulations for the associated regulatory jurisdiction ((Dubinsky) in at least para 0047, para 0054-0055); and
continuing the workflow for successive points of data entry and corresponding user input, each successive point of data entry being based on the just-previous user input ((Dubinsky) in at least para 0047, para 0054-0055);
driven by workflow rules associated with respective user input and associated in the data store with regulatory jurisdictions, regulatory standards for the associated regulatory jurisdictions, and regulations for the associated regulatory jurisdictions, until the workflow reaches an end defined for the compliant offering ((Dubinsky) in at least para 0025, para 0027, para 0047-0048, para 0052, para 0054-0055) .
Claim(s) 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over WO 2006/036656 A2 by Dubinsky (Dubinsky) in view of US Pub No. 2021/0248166 A1 by Ares (Ares) in view of US Pub No. 2011/0078059 A1 by Chambers et al (Chambers), as applied to claim 14 above, and further in view of US Pub No. 2014/0089185 A1 by Desai et al. (Desai)
In reference to Claim 18:
The combination of Dubinsky, Ares and Chambers discloses the limitations of independent claim 14. Dubinsky further discloses the limitations of dependent claim 18
(Previously Presented) The system of claim 14 (see rejection of claim 14 above),
Dubinsky does not explicitly teach:
wherein at least one of the succession of screens of the wizard embodies logic to access information in any one of a digital wallet, escrow wallet, or token wallet.
Desai teaches:
wherein at least one of the succession of screens of the wizard embodies logic to access information in any one of a digital wallet, escrow wallet, or token wallet. ((Desai) in at least para 0088-0089, para 0117, para 0125, para 0144, para 0454-0457).
According to KSR, simple substitution of one known element for another to obtain predictable results is common sense obvious rationale. The prior art Dubinsky contained plurality of exemplary services accessible via wizard process which differed from the claimed device by the substitution of specific category of services which entail wallet services. The prior art Desai provides evidence that such substituted third party services and providers and their functions were known in the art. Accordingly, based on the teaching of Desai, one of ordinary skill in the art could have substituted one known third party services provider for another, and the results of the substitution would have been predictable.
Both Dubinsky and Desai are directed toward providing access to services with wizard utility ecosystems. Desai teaches the motivation of applying wizards as utility tools in order to access different services which can include digital wallet services from a set of different services. It would have been obvious to one having ordinary skill before the effective filing date of the claimed invention to modify the services available for accessing using wizard tools of Dubinsky to include wallet services as taught by Desai since Desai teaches the motivation of applying wizards as utility tools in order to access different services which can include digital wallet services from a set of different services.
Claim(s) 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over WO 2006/036656 A2 by Dubinsky (Dubinsky) in view of US Pub No. 2021/0248166 A1 by Ares (Ares) in view of US Pub No. 2011/0078059 A1 by Chambers et al (Chambers), in view of US Pub No. 2014/0089185 A1 by Desai et al. (Desai) as applied to claim 18 above, and further in view of US Pub No. 2017/0232300 A1 by Tran et al. (Tran)
In reference to Claim 19:
The combination of Dubinsky, Ares, Chambers and Desai discloses the limitations of independent claim 14. Dubinsky further discloses the limitations of dependent claim 18:
(Previously Presented) The method of claim 18 (see rejection of claim 18 above),
Dubinsky does not explicitly teach:
wherein at least one of the succession of screens of the wizard embodies logic to interface with a smart contract.
Tran teaches:
wherein at least one of the succession of screens of the wizard embodies logic to interface with a smart contract.((Tran) in at least para 0122-0123, para 0134)
Both Dubinsky and Tran are directed toward utilizing wizards as digital assistance to walk users through processes with respect to accessing and managing records which include legal records. Tran teaches the motivation of applying wizards in order to provide to the user a sequence of steps and pages to allow a user to fill out information that follow the legal digital assistant requirements as it relates to a smart contract agreement to be legally enforceable. It would have been obvious to one having ordinary skill before the effective filing date of the claimed invention to modify the utilization of the digital assistant wizard for consent values for accessing records where the information type required by the wizard include type of action, legal basis of Dubinsky to include utilizing digital assistant wizards to provide a sequence of steps for information required provided in a list of step for a smart contract of Tran since Tran teaches the motivation of applying wizards in order to provide to the user a sequence of steps and pages to allow a user to fill out information that follow the legal digital assistant requirements as it relates to a smart contract agreement to be legally enforceable.
Claim(s) 20 and 28 is/are rejected under 35 U.S.C. 103 as being unpatentable over WO 2006/036656 A2 by Dubinsky (Dubinsky) in view of US Pub No. 2021/0248166 A1 by Ares (Ares) in view of CA 2985424 by Weisz (Weisz) and further in view of US Pub No. 2007/0250769 A1 by Bass et al. (Bass)
In reference to Claim 20:
Dubinsky teaches:
(Currently Amended) A method to generate and execute a workflow applying regulatory requirements in a workflow rules-based architecture to generate offering documents compliant with the regulatory requirements ((Dubinsky) in at least Abstract; para 0006, para 0047), the method comprising:
receiving input of a type of financial offering and a financial jurisdiction in which the financial offering requires regulatory compliance ((Dubinsky) in at least abstract; FIG. 15; para 0012, para 0019, para 0025, para 0055-0056, para 0058); and
in response to receiving the type of financial offering and financial jurisdiction: accessing at a workflow generator embedding the regulatory requirements, financial jurisdiction data, financial standards data, and financial regulations data from a data store, the data store having a structured storage storing workflow rules relating to the workflow, financial jurisdiction data including entries of regulatory financial jurisdictions that regulate financial instruments generated by the workflow, financial standards data including regulatory financial standards enforceable in the regulatory financial jurisdictions, and financial regulations data including entries of financial regulations to enforce corresponding regulatory financial standards among the regulatory financial standards for one or more of the regulatory financial jurisdictions, which financial regulations govern information required to be present in the generated offering documents for compliance; wherein the rules, financial jurisdiction data, financial standards data, and financial regulations data are stored in the structured storage associating one or more of the rules with each regulatory financial jurisdiction, regulatory financial standards for the associated regulatory financial jurisdiction, and financial regulations for the associated regulatory financial jurisdiction ((Dubinsky) in at least Abstract; para 0006, para 0012-0014, para 0025-0026, para 0050, para 0054-0056, para 0059, para 0062); …
automatically embedding the identified regulatory requirements into workflow rules enforced by the workflow generator ((Dubinsky) in at least para 0012-0014, para 0025, para 0047-0050, para 0054-0055);
based on at least the accessed workflow rules and the embedded regulatory requirements, generating by the workflow generator a dynamic workflow embodied in a wizard comprised of a succession of screens, the screens implementing the rules embedded regulatory requirements to automatically drive the creation of financial instruments compliant with the regulatory financial jurisdictions, regulatory financial standards, and financial regulations in the accessed financial jurisdiction data, financial standards data, and financial regulations data, such that a user of the wizard cannot deviate from the underlying workflow ((Dubinsky) in at least FIG. 15; para 0047, para 0054-0055);
Dubinsky does not explicitly teach:
financial offering
parsing the accessed financial jurisdiction data, financial standards data, and financial regulations data to identify the regulatory requirements applicable to the input financial offering type and financial jurisdiction;
receiving a change to one or more of the financial jurisdiction data, financial standards data, and financial regulations data; and
responsive to receiving the change, dynamically changing the workflow, and the wizard to reflect the received change; and
wherein at least one of the succession of screens of the wizard embodies logic to generate a financial document, receive an electronic signature for the financial document, and to store the financial document in a data room.
Weisz teaches:
…offering documents…((Weisz) in at least para 0061)
parsing the accessed jurisdiction data, standards data, and regulations data to identify the regulatory requirements applicable to the input offering type and jurisdiction ((Weisz) in at least Fig. 13; para 0010, para 0016, , para 0095, para 0034 wherein the prior art teaches system automatically determines class of parties and cross reference eligible parties according to jurisdictions and regulatory requirements; para 0061 wherein the prior art teaches offering is identified, the class of the offering party and offerings by issuers with rules corresponding to each offer, para 0095-0096, para 0121-0122 wherein the prior art teaches populating documents for restricted sales pursuant to regulations, para 0123, para 0127);
Both Dubinsky and Weisz are directed toward generating agreements/contracts with a plurality of documents for the transaction between parties for financial instruments where the system populates contractual information. According to KSR, simple substitution for one known element with another to obtain predictable results is common sense rationale. The prior art Dubinsky contained regulatory compliance generation of contracts for financial offering (financial instrument mortgage type) with differed from the claimed regulatory compliance generation of contracts for financial offering (financial instrument -investment vehicle type ) by the substitution with other regulatory compliance generation of contracts for financial offering (financial instrument). The prior art Weisz provides evidence that the substituted offering (IPO, investment vehicles) and their functions were known in the art. One of ordinary skill in the art could have substituted one known element financial instrument for the generation of a contract in compliance with regulations for another, and the results of the substitution would have been predictable
With respect to the limitation “parsing the accessed jurisdiction data, standards data, and regulations data to identify the regulatory requirements applicable to the input offering type and jurisdiction”, both Dubinsky and Weisz are directed toward generating contracts/agreements related to financial instruments which are regulated according to jurisdiction rules and are directed toward automated system which populate and generate documents for contractual agreements. Weisz teaches the motivation of identifying in different agreements between parties the classes of the parties and financial instruments in order to identify and determine class of parties and cross reference eligible parties according to jurisdictions and regulatory requirements. It would have been obvious to one having ordinary skill before the effective filing date of the claimed invention to modify the contractual document generation process of Dubinsky to include the parsing/classifying of the entities and financial offerings as taught by Weisz since Weisz teaches the motivation of identifying in different agreements between parties the classes of the parties and financial instruments in order to identify and determine class of parties and cross reference eligible parties according to jurisdictions and regulatory requirements.
Ares teaches:
parsing the accessed jurisdiction data, standards data, and regulations data to identify the regulatory requirements applicable to the input offering type and jurisdiction ((Ares) in at least Abstract; para 0009-0011, para 0013, para 0015-0017, para 0072, para 0082-0084, para 0242-0243);
Both Dubinsky and Ares teach tables associated with specific rules used for business applications. Ares teaches the motivation of parsing data into unique domain tables in order to identify data sets corresponding to specific domain criteria in order for data to be retrieved according to domain. It would have been obvious to one having ordinary skill before the effective filing date of the claimed invention to expand on the rules table for application applied to documents of Dubinsky to include the multi-architectural database and domain tables as taught by Ares since Ares teaches the motivation of parsing data into unique domain tables in order to identify data sets corresponding to specific domain criteria in order for data to be retrieved according to domain.
Bass teaches:
receiving a change to one or more of the financial jurisdiction data, financial standards data, and financial regulations data ((Bass) in at least FIG. 5-7; para 0047, para 0049-0051, para 0065-0066); and
responsive to receiving the change, dynamically changing the workflow, and the wizard to reflect the received change ((Bass) in at least FIG. 5-7; para 0050-0054, para 0057, para 0062, para 0065-0066); and
wherein at least one of the succession of screens of the wizard embodies logic to generate a financial document, receive an electronic signature for the financial document, and to store the financial document in a data room ((Bass) in at least para 0103-0120, para 0132-0133, para 0148-0149, para 0158).
Both Dubinsky and Bass are directed toward applying wizard software for workflow processes. Bass teaches the motivation of a wizard process which allows for editing in order to provide a means to change the rules that drive the creation of document compliant with the created document requirements. It would have been obvious to one having ordinary skill before the effective filing date of the claimed invention to modify the contractual document generation process of Dubinsky to include a means to edit the wizard workflow process as taught Bass since Bass teaches the motivation of a wizard process which allows for editing in order to provide a means to change the rules that drive the creation of document compliant with the created document requirements.
In reference to Claim 28:
The combination of Dubinsky, Ares, Weisz and Bass discloses the limitations of independent claim 20. Dubinsky further discloses the limitations of dependent claim 28:
(New) The method of claim 20 (see rejection of claim 20 above), wherein the workflow comprises:
presenting a first point of data entry in the user interface ((Dubinsky) in at least para 0027-0031, para 0047);
receiving first user input via the user interface at the first point of data entry ((Dubinsky) in at least para 0053);
in response to the first user input, accessing the data store to obtain a second point of data entry based on the first user input in accordance with a first workflow rule associated with the first user input, wherein the first workflow rule is associated in the data store with one of the regulatory financial jurisdictions, regulatory financial standards for the associated regulatory financial jurisdiction, and financial regulations for the associated regulatory financial jurisdiction ((Dubinsky) in at least para 0054-0057);
presenting the second point of entry in the user interface ((Dubinsky) in at least para 0047, para 0054-0055);
receiving second user input via the user interface at the second point of data entry ((Dubinsky) in at least para 0047, para 0054-0055, para 0059);
in response to the second user input, accessing the data store to obtain a third point of data entry based on the second user input in accordance with a second workflow rule associated with the second user input, wherein the second workflow rule is associated in the data store with one of the regulatory financial jurisdictions, regulatory financial standards for the associated regulatory financial jurisdiction, and financial regulations for the associated regulatory financial jurisdiction ((Dubinsky) in at least para 0047, para 0054-0055); and
continuing the workflow for successive points of data entry and corresponding user input, each successive point of data entry being based on the just-previous user input ((Dubinsky) in at least para 0047, para 0054-0055);
driven by workflow rules associated with respective user input and associated in the data store with regulatory financial jurisdictions, regulatory financial standards for the associated regulatory financial jurisdictions, and financial regulations for the associated regulatory financial jurisdictions, until the workflow reaches an end defined for the compliant financial offering. ((Dubinsky) in at least para 0025, para 0027, para 0047-0048, para 0052, para 0054-0055)
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. US Patent No. 7,467,107 B1 by Mulligan JR; US Pub No. 2012/0331567 A1 by Shelton; US Pub No. 2011/0093471 A1 by Brockway et al; US Pub No. 2012/0323589 A1 by Udani; US Patent No. 12,107,952 B2 by Wright et al; US Pub No. 2021/0201328 A1 by Gunther; AU 2014363926 by McCarthy; GB 2597112 A by Richards; CA 3022440 A1 by Singh; US Pub No. 2014/0278705 A1 by Tuggle; US Pub No. 2014/0101564 A1 by Ward et al; US Patent No. 11,641,280 B1 by Chapman et al; US Pub No 2018/0204281 A1 by Painter et al; EP 3687109 A1 by Chen; EP4009583 A1 by Blank et al
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 MARY M GREGG whose telephone number is (571)270-5050. The examiner can normally be reached M-F 9am-5pm.
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, Christine Behncke can be reached at 571-272-8103. 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.
/MARY M GREGG/Examiner, Art Unit 3695
/CHRISTINE M Tran/Supervisory Patent Examiner, Art Unit 3695
Prosecution Insights