Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
This action is in reply to the application filed on August 21, 2025.
Claims 1-20 are currently pending and have been examined.
Claim Rejections - 35 USC § 112(b)
The following is a quotation of 35 U.S.C. § 112(b):
(B) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. § 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 11, 12, and 15 are rejected under 35 U.S.C. § 112(b) or 35 U.S.C. § 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention. Regarding Claim 11, this claim recites “the handler function,” which is a term that lacks proper antecedent basis. While the term “handler function” appears in Claims 3, 5, and 6, none of these claims are in the dependency chain for Claim 11. This raises the question of whether Applicant intended for Claim 11 to depend upon any of these claims or whether Applicant intended to recite a “handler function” somewhere earlier in Claim 11’s dependency chain. Thus, Claim 11 is not particularly pointed out or distinctly claimed and must be rejected under § 112(b). Because Claim 12 depends upon Claim 11 and fails to resolve this ambiguity, it must also be rejected under § 112(b). Regarding Claim 15, this claim recites “the class object” which is also a term that lacks proper antecedent basis. While the term “class object” appears in Claim 14, Claim 15 depends upon Claim 13 and not Claim 14. This raises the question of whether Applicant intended for Claim 15 to depend upon Claim 14 instead of Claim 13 or whether Applicant intended to recite a “class object” somewhere earlier in Claim 15’s dependency chain. Thus, Claim 15 is not particularly pointed out or distinctly claimed and must be rejected under § 112(b).
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-20 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to non-statutory subject matter. When considering subject matter eligibility under 35 U.S.C. § 101, there are multiple steps that may need to be assessed. First, in step 1 it must be determined whether the claim is directed to one of the four statutory categories of invention, i.e., process, machine, manufacture, or composition of matter. If the claim does fall within one of the statutory categories, it must then be determined in step 2A prong 1 whether the claim is directed to a judicial exception (i.e., law of nature, natural phenomenon, and abstract idea). If the claim is directed toward a judicial exception, it must then be determined in step 2A prong 2 whether the judicial exception is integrated into a practical application. Finally, if the judicial exception is not integrated into a practical application, it must additionally be determined in step 2B whether the claim recites “significantly more” than the abstract idea. See “2019 Revised Patent Subject Matter Eligibility Guidance,” 84 Fed. Reg. (4): 50-57 (Jan. 7, 2019).
In the instant case, Claims 1-18 are directed toward a method, i.e., process, Examiner interprets Claim 19 (i.e., “A rules engine comprising at least one processing unit…”) as a computer system, i.e., apparatus, and Claim 20 is directed toward a non-transitory computer readable medium, i.e., article of composition. Thus, each of the claims falls within one of the four statutory categories as required by step 1. Nevertheless, the claims are directed toward the judicial exception of an abstract idea in step 2A prong 1. Independent Claim 1 recites as follows:
Claim 1. A rules engine application method, the method comprising:
(a) obtaining trigger conditions corresponding to rules defining document requirements for at least one product to be evaluated in respect of a client, and client data pertaining to the client;
(b) applying the rules by evaluating the trigger conditions using the client data in respect of the at least one product; and
(c) as a result of applying the rules, generating a document requirement matrix, the document requirement matrix comprising, for each of the at least one product, an indication for each of a plurality of document classes corresponding to whether the client is required to provide a document of the respective document class to purchase a respective product.
The bold language above corresponds to the abstract ideas recited in Claim 1 (whereas the underlined language is language that is addressed in step 2A prong 2 and step 2B). As the bold language above demonstrates, Applicant’s claims are directed toward performing a set of determinations regarding whether a client needs to provide a document or whether the document has already been provided to purchase a particular product. Thus, Applicant’s claims are directed toward commercial interactions, i.e., the purchase of a product. As Applicant’s specification explains at paragraph 48, the invention is related to the commercial interaction/practice of cross-selling products and onboarding documents for the client. Because the instant invention is facilitating the commercial interaction of cross-selling and onboarding clients, the invention is reciting one of the certain methods of organizing human activities that courts have found are abstract ideas, specifically commercial interactions. See MPEP § 2106.04(a)(2)(II)(B). Alternatively, because the claims recite a series of applying rules to make various determinations, the claims are reciting a series of mental observations, judgments, and evaluations that can be performed in the human mind and thus is an abstract set of mental processes. See MPEP § 2106.04(a)(2)(III).
Finding the claims to be directed toward an abstract idea, however, is not the end of the inquiry. Rather, the next step is to determine whether the judicial exception is integrated into a practical application (step 2A prong 2). The revised guidance provides exemplary considerations that are indicative that an additional element or combination of elements may have integrated the exception into a practical application: 1) an additional element reflecting an improvement in the functioning of a computer or an improvement to another technology or technical field, 2) an additional element that implements the judicial exception with a particular machine or manufacture that is integral to the claim, 3) an additional element that effects a transformation or reduction of a particular article to a different state or thing, or 4) an additional element that applies or uses the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment such that the claim as a whole is more than a drafting effort designed to monopolize the exception. See MPEP § 2106.04(d). Examples where a judicial exception has not been integrated into a practical application include: 1) use of “apply it” or the equivalent, i.e., merely using a computer to implement or perform an abstract idea, 2) an additional element that adds insignificant extra-solution activity to the judicial exception, and 3) an additional element that does no more than generally link the use of the judicial exception to a particular technological environment or field of use. See id.
Applying these considerations to the claims in the instant application, the claims do not integrate the judicial exception into a practical application. The claims fail to recite an improvement of a computer, any improvement to a technology or technical field, any particular machine, any transformation or reduction of a particular article to a different state or thing, or any additional element that uses the judicial exception in a meaningful way. Instead, the claims are merely reciting instructions to implement the abstract idea on a computer (i.e., “rules engine application”), which is insufficient to provide a practical application of the claims and provide subject matter eligibility. See id. Therefore, there is no integration of the abstract idea into a practical application.
If the claims are not integrated into a judicial exception, the Examiner must consider whether there is “significantly more” recited in the claim in step 2B. See MPEP § 2106.05. There is nothing unconventional or inventive in Applicant’s claims for the purpose of analysis under step 2B, e.g., any combination of elements that provide an advance over any technological state of the art. Rather, as noted above, an abstract commercial interaction is merely implemented by a general-purpose computer. Other than the limitations that are abstract for the reasons articulated above, Applicant has merely recited a generic computer that facilitates the steps of the invention. Thus, Applicant’s claims merely recite a computer to implement the abstract idea, which fails to provide “significantly more” than the abstract idea.
As the MPEP states, Examiners may consider the following three factors when determining whether the claim recites mere instructions to implement an abstract idea on a computer: 1) whether the claim recites only the idea of a solution or outcome, i.e., the claim fails to recite details of how a solution to a problem is accomplished; 2) whether the claim invokes computers or other machinery merely as a tool to perform an existing process; and 3) the particularity or generality of the application of the judicial exception. See MPEP § 2106.05(f). Applying those factors to the instant application: 1) the claims do not recite how the computer performs any of the steps other than just stating that they do it; 2) the claims invoke the computer to perform a process of cross-selling and onboarding that has been performed without computers and before the ubiquity of computers; and 3) the claims are generic in nature and not recited in much particularity because it can apply to any way of performing the cross-selling and onboarding.
The dependent claims 2-18 are merely reciting further embellishments of the abstract idea and do not amount to anything that is significantly more than the abstract idea itself. Specifically, these claims recite further means via which a computer is the tool that merely implements the abstract commercial interaction. In other words, none of the dependent claims recite an improvement to a technology or technical field or provide any meaningful limitations that, in an ordered combination provide “significantly more” or providing any integration into a practical application. Rather, the dependent claims are merely further reciting features that are just as abstract as independent Claims 1, 19, and 20. Therefore, Claims 1-20 are directed to non-statutory subject matter and are rejected as ineligible subject matter under 35 U.S.C. § 101.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. §§ 102 and 103 (or as subject to pre-AIA 35 U.S.C. §§ 102 and 103) is incorrect, any correction of the statutory basis 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 of this title, 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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.
Claims 1-6, 13, 14, and 16-20 are rejected under 35 U.S.C. § 103 as being unpatentable over Loosli et al. (US 2018/0060897 A1, hereinafter “Loosli”) in view of Barbour et al. (US 2017/0053336 A1, hereinafter “Barbour”).
Claim 1. Loosli teaches: A rules engine application method, the method comprising:
(a) obtaining trigger conditions corresponding to rules defining document requirements for at least one product to be evaluated in respect of a client, and client data pertaining to the client (see, e.g., at least ¶s 5, 6, 26, 28-30, and 43 teaching executing a rules engine against data of a client and various requirements to determine at least one product for which the client qualifies);
(b) applying the rules by evaluating the trigger conditions using the client data in respect of the at least one product (see, e.g., Figure 3 feature 302 and ¶s 4, 37, and 40 teaching the application of rules and conditions to determine whether the client qualifies for the program); and
(c) as a result of applying the rules, generating a document requirement matrix, the document requirement matrix comprising, for each of the at least one product, an indication for each of a plurality of document classes corresponding to whether the client is required to provide a document of the respective document class to purchase a respective product (see, e.g., at least ¶s 5, 6, 26, 28-30, and 43 teaching executing a rules engine against data of a client and various requirements to determine at least one product for which the client qualifies; see also ¶ 16 teaching that the financial institution can use the end user’s, i.e., client’s, financial information on hand “to provide them with better offers even before they apply” and ¶ 27 teaching that the client information may already be in the financial institution’s possession due to already existing accounts).
Examiner notes that, for the purpose of compact prosecution, Loosli fails to expressly state that it generates a document requirement matrix as the means or locus of the sets of rules and the corresponding client data for its rules engine that determines whether the client data, as matched against the rules, means that the client qualifies for the financial product or not. Such a feature is arguably inherent in the disclosure of Loosli because Loosli is performing the analysis of the rules and the corresponding set of customer/client data (or lack thereof), which is thus a combination of rules in one direction (row or column) and the client data in the other direction (i.e., row or column). Nevertheless, Examiner notes that it is taught in analogous prior art to utilize such a matrix when analyzing a client’s information and various rules when deciding whether to cross-sell financial products to clients. Barbour, for example, teaches such a feature. Specifically, Barbour teaches utilizing a matrix with Boolean values to determine rules and their applicability (see, e.g., Barbour ¶s 154-155 and 160). Barbour notes that the invention is, like Loosli and the instant application, used to make financial product recommendations to participants even when the specific participant and entity do not have visibility into all of the underlying data required for the determination (see Barbour ¶ 8).
Therefore, it would have been obvious to one of ordinary skill in the art as of the effective filing date to apply the known technique of using a generated matrix (as disclosed by Barbour) to the known method and system of determining, based on a client’s existing data and corresponding rules, whether a client qualifies for the financial product cross-sell (as disclosed by Loosli). One of ordinary skill in the art would have been motivated to apply the known technique of using a generated matrix because it would allow financial institutions to offer better product recommendations to users and for higher uptake of the recommended products (see Barbour ¶ 14).
Furthermore, it would have been obvious to one of ordinary skill in the art as of the effective filing date to apply the known technique of using a generated matrix (as disclosed by Barbour) to the known method and system of determining, based on a client’s existing data and corresponding rules, whether a client qualifies for the financial product cross-sell (as disclosed by Loosli), because the claimed invention is merely applying a known technique to a known method ready for improvement to yield predictable results. See KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 406 (2007). In other words, all of the claimed elements were known in the prior art and one skilled in the art could have combined the elements as claimed by known methods with no change in their respective functions, and the combination would have yielded nothing more than predictable results to one of ordinary skill in the art at the time of the invention (i.e., predictable results are obtained by applying the known technique of using a generated matrix to the known method and system of determining, based on a client’s existing data and corresponding rules, whether a client qualifies for the financial product cross-sell, because predictably a matrix for the rules engine is a known way of executing the application of a set of rules to client financial data when deciding whether to cross-sell financial products). See also MPEP § 2143(I)(D).
Claim 2. The combination of Loosli and Barbour teach the limitations of Claim 1. That combination further teaches: The rules engine application method of claim 1, wherein each cell of the document requirement matrix is populated with a Boolean value corresponding to the indication of whether the client is required to provide the document of the respective document class to purchase the respective product (see Loosli ¶s 16 and 27 teaching using the data already on file for the client to make the determinations and at least ¶s 5, 6, 26, 28-30, and 43 teaching executing a rules engine against data of a client and various requirements to determine at least one product for which the client qualifies; see further Barbour ¶s 154-155 and 160 teaching using a matrix with Boolean values as part of the determinations that, as taught in, e.g., Barbour ¶ 8, is used to make financial product recommendations to participants even when the specific participant and entity do not have visibility into all of the underlying data required for the determination). Examiner notes that the rationale for combining Loosli and Barbour is provided in the rejection of Claim 1 above.
Claim 3. The combination of Loosli and Barbour teach the limitations of Claim 2. That combination further teaches: The rules engine application method of claim 2,
(a) wherein each of the trigger conditions corresponds to a rule or attribute thereof (see Loosli ¶s 16 and 27 teaching using the data already on file for the client to make the determinations and at least ¶s 5, 6, 26, 28-30, and 43 teaching executing a rules engine against data of a client and various requirements to determine at least one product for which the client qualifies);
(b) wherein each of the trigger conditions is evaluated using a handler function that outputs the Boolean value representing whether a respective trigger condition is satisfied (see Barbour ¶s 154 and 161 teaching utilizing Boolean values to determine conditions in the matrix);
(c) wherein any one handler function returning a false Boolean value for a particular cell of the matrix results in the particular cell being false and all handler functions returning a true Boolean value for the particular cell results in the particular cell being true (see Barbour ¶s 154 and 161 teaching utilizing Boolean values to determine conditions in the matrix, including a value of “0” when the cell is false and a “1” when the cell is true); and
(d) wherein the particular cell being false represents that one of the trigger conditions for requiring the client to provide the document of the respective document class is unsatisfied, and the particular cell being true represents that all of the trigger conditions for requiring the client to provide the document of the respective document class are satisfied (see Barbour ¶s 154 and 161 teaching utilizing Boolean values to determine conditions in the matrix, including a value of “0” when the cell is false and a “1” when the cell is true and Loosli ¶s 16 and 27 teaching using the data already on file for the client to make the determinations and at least ¶s 5, 6, 26, 28-30, and 43 teaching executing a rules engine against data of a client and various requirements to determine at least one product for which the client qualifies).
Examiner notes that the rationale for combining Loosli and Barbour is provided in the rejection of Claim 1 above.
Claim 4. The combination of Loosli and Barbour teach the limitations of Claim 3. That combination further teaches: The rules engine application method of claim 3,
(a) wherein each of the trigger conditions corresponds to a respective attribute of the rules and a respective attribute of the at least one product or the client data (see Loosli ¶s 16 and 27 teaching using the data already on file for the client to make the determinations and at least ¶s 5, 6, 26, 28-30, and 43 teaching executing a rules engine against data of a client and various requirements to determine at least one product for which the client qualifies); and
(b) wherein the handler function returns the true Boolean value if the respective attribute of the rules matches the respective attribute of the at least one product or the client data (see Barbour ¶s 154 and 161 teaching utilizing Boolean values to determine conditions in the matrix, including a value of “0” when the cell is false and a “1” when the cell is true).
Examiner notes that the rationale for combining Loosli and Barbour is provided in the rejection of Claim 1 above.
Claim 5. The combination of Loosli and Barbour teach the limitations of Claim 4. Barbour further teaches: The rules engine application method of claim 4, wherein a trigger matcher function maps the respective attribute of the rules to the respective attribute of the at least one product or the client data for the handler function (see, e.g., ¶s 154-156 teaching mapping the product and client data in each cell of the user-item matrix). Examiner notes that the rationale for combining Loosli and Barbour is provided in the rejection of Claim 1 above.
Claim 6. The combination of Loosli and Barbour teach the limitations of Claim 3. Barbour further teaches: The rules engine application method of claim 3, wherein the handler function is dynamically dispatched for each cell based on the respective document class and the respective product (see, e.g., ¶s 154-156 teaching mapping the product and client data in each cell of the user-item matrix). Examiner notes that the rationale for combining Loosli and Barbour is provided in the rejection of Claim 1 above.
Claim 13. The combination of Loosli and Barbour teach the limitations of Claim 1. Loosli further teaches: The rules engine application method of claim 1, further comprising: retrieving product information for the at least one product, wherein the trigger conditions comprise a trigger condition evaluated using the product information (see, e.g., Figure 3 feature 302 and ¶s 4, 37, and 40 teaching the application of rules and conditions to determine whether the client qualifies for the program, i.e., the product, based on the evaluation of rules based on the product).
Claim 14. The combination of Loosli and Barbour teach the limitations of Claim 13. Barbour further teaches: The rules engine application method of claim 13,
(a) wherein the product information is obtained in one or more third formats and, prior to the applying of the rules, the method further comprising converting the product information into a fourth format (see Barbour ¶ 36 teaching a “unified ontology” that is “comprised of at least three ontologies,” i.e., a fourth format taken from three other formats; see additionally ¶ 70 teaching that the unified ontology allows for the creation of an array of distinct relational databases in “a common Cassandra cluster of ontology data store,” i.e., a fourth format; see also ¶ 63 teaching that Spark SQL and Cassandra can work together to house and structure the data, i.e., that the structured Spark SQL data can be an additional format converted from the Cassandra data);
(b) wherein the fourth format is a class object (see, e.g., ¶s 61 and 70 teaching that the Cassandra clusters are relational databases); and
(c) wherein the converting of the product information comprises: (i) processing the product information in the one or more third formats to extract relevant product information; (ii) tokenizing the relevant product information to map attributes in the relevant product information into standardized terms; and (iii) grouping classes of the at least one products using a product matching function (see Barbour ¶ 36 teaching a “unified ontology” that is “comprised of at least three ontologies,” i.e., a fourth format taken from three other formats; see additionally ¶ 70 teaching that the unified ontology allows for the creation of an array of distinct relational databases in “a common Cassandra cluster of ontology data store,” i.e., a fourth format; see also ¶ 63 teaching that Spark SQL and Cassandra can work together to house and structure the data, i.e., that the structured Spark SQL data can be an additional format converted from the Cassandra data).
Examiner notes that the rationale for combining Loosli and Barbour is provided in the rejection of Claim 1 above.
Claim 16. The combination of Loosli and Barbour teach the limitations of Claim 1. Barbour further teaches: The rules engine application method of claim 1, wherein the applying of the rules comprises: ingesting a first file comprising the trigger conditions for the at least one product, and a second file identifying acceptable documents for the plurality of document classes (see, e.g., Barbour ¶s 78-79 teaching ingesting the data used to perform the analysis of the invention; alternatively, see Loosli ¶ 38 teaching obtaining the data for the invention from a network).
Claim 17. The combination of Loosli and Barbour teach the limitations of Claim 1. Loosli further teaches: The rules engine application method of claim 1, further comprising: evaluating the document requirement matrix against document information corresponding to documents provided by the client to determine additional documents to be provided by the client to purchase the at least one product, wherein the client data comprises the document information (see, e.g., at least ¶s 5, 6, 26, 28-30, and 43 teaching executing a rules engine against data of a client and various requirements to determine at least one product for which the client qualifies; see also ¶ 16 teaching that the financial institution can use the end user’s, i.e., client’s, financial information on hand “to provide them with better offers even before they apply” and ¶ 27 teaching that the client information may already be in the financial institution’s possession due to already existing accounts).
Claim 18. The combination of Loosli and Barbour teach the limitations of Claim 1. Loosli further teaches: The rules engine application method of claim 1,
(a) wherein the rules engine is implemented on a back-end of a server system and communicatively coupled to a user interface implemented on a front-end of the server system using an API endpoint (see Figure 1 feature 112 and ¶s 25 and 31 teaching the backend application that is on server 108 that is connected via network 106 to user interfaces 102 and 104; alternatively, note Barbour ¶s 40, 59, 75, 136, 138, and 139 and Figure 8);
(b) wherein the back-end of the server system hosts at least one first internal database storing the client data, the client data retrievable on a basis of a client identifier received from the user interface (see Figure 1 feature 112 and ¶s 25 and 31 teaching the backend application that is on server 108 that stores the client data); and
(c) wherein the back-end of the server systems hosts at least one second internal database storing the trigger conditions (see Figure 1 feature 112 and ¶s 25 and 31 teaching the backend application that is on server 108 that helps perform the application of the rules, i.e., the trigger conditions).
Regarding Claim 19. This claim recites the same three method steps as independent Claim 1 above. The only difference is that this claim recites “a rules engine comprising at least one processing unit configured to perform” the method of Claim 1. Examiner interprets this “rules engine comprising at least one processing unit” as a computer processor that performs the method steps. With that understanding, Examiner incorporates the rejection of Claim 1 herein, relying on the combination of Loosli and Barbour to render obvious those method steps. Loosli further teaches that its invention is performed by a computer processor (see at least ¶s 6 and 21). Thus, with this additional teaching of Loosli, the combination of Loosli and Barbour render obvious Claim 19.
Regarding Claim 20. This claim recites the same three method steps as independent Claim 1 above. The only difference is that this claim recites “At least one non-transitory computer readable medium having stored thereon computer program code that is executable by at least one processor and that, when executed by the at least one processor, causes the at least one processor to perform a rules engine application method comprising” the method of Claim 1. Examiner incorporates the rejection of Claim 1 herein, relying on the combination of Loosli and Barbour to render obvious those method steps. Loosli further teaches that its invention is performed by a computer processor executing instructions stored on a computer readable medium (see at least ¶s 6, 21, 33, and 35). Thus, with this additional teaching of Loosli, the combination of Loosli and Barbour render obvious Claim 20.
Claims 7-12 and 15 are rejected under 35 U.S.C. § 103 as being unpatentable over Loosli et al. (US 2018/0060897 A1, hereinafter “Loosli”) in view of Barbour et al. (US 2017/0053336 A1, hereinafter “Barbour”) and further in view of Ristock et al. (US 2014/0177821 A1, hereinafter “Ristock”).
Claim 7. The combination of Loosli and Barbour teach the limitations of Claim 1. That combination fails to expressly teach: The rules engine application method of claim 1, wherein the rules are obtained in one or more first formats and, prior to the applying of the rules, the method further comprising converting the rules into a shared second format, though Examiner does note that Barbour teaches is the use of a “unified ontology.” Barbour’s “unified ontology” is “comprised of at least three ontologies” and “may allow financial institution products from distinct financial institutions to be associated with classification nodes such that similar products from disparate financial institutions may be associated despite their dissimilar names, descriptions, different institutions, etc.” (see ¶ 36). Barbour additionally teaches that the unified ontology allows for the creation of an array of distinct relational databases in “a common Cassandra cluster of ontology data store” (see ¶ 70) as well as that Spark SQL and Cassandra can work together to house and structure the data (see ¶ 63). Thus, Barbour teaches the placing of the rules into a common format and structuring unstructured data, which is obtaining data in one format and converting it to another under a broadest reasonable interpretation of the claim. Nevertheless, for the purpose of compact prosecution, Examiner notes that analogous prior art reference Ristock expressly teaches converting rules from an obtained first format and converting the rules into a second format (see at least Ristock ¶ 131 teaching a fact model editor 1003 that can package the data for a rules engine 964 by converting the data into XML or JSON string format; see also ¶ 157 teaching exporting an individual test scenario in XLS format). Ristock is similar to the instant application, Loosli, and Barbour because it relates to using a rules engine to determine the possibility of up-sell, cross-sell, or other business opportunity with the customer (see Ristock ¶ 92).
Therefore, it would have been obvious to one of ordinary skill in the art as of the effective filing date to apply the known technique of converting rules and data to a particular data format (as disclosed by Ristock) to the known method and system of determining, based on a client’s existing data and corresponding rules, whether a client qualifies for the financial product cross-sell (as disclosed by Loosli and Barbour). One of ordinary skill in the art would have been motivated to apply the known technique of converting rules and data to a particular data format because different data formats may allow for different data formatting and editing, such as by exporting data in an XLS format that can enable a user to edit rows of test data inside a spreadsheet (see Ristock ¶ 157).
Furthermore, it would have been obvious to one of ordinary skill in the art as of the effective filing date to apply the known technique of converting rules and data to a particular data format (as disclosed by Ristock) to the known method and system of determining, based on a client’s existing data and corresponding rules, whether a client qualifies for the financial product cross-sell (as disclosed by Loosli and Barbour), because the claimed invention is merely applying a known technique to a known method ready for improvement to yield predictable results. See KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 406 (2007). In other words, all of the claimed elements were known in the prior art and one skilled in the art could have combined the elements as claimed by known methods with no change in their respective functions, and the combination would have yielded nothing more than predictable results to one of ordinary skill in the art at the time of the invention (i.e., predictable results are obtained by applying the known technique of converting rules and data to a particular data format to the known method and system of determining, based on a client’s existing data and corresponding rules, whether a client qualifies for the financial product cross-sell, because predictably converting formats is a known way of executing the application of a set of rules to client financial data when deciding whether to cross-sell financial products). See also MPEP § 2143(I)(D).
Claim 8. The combination of Loosli, Barbour, and Ristock teach the limitations of Claim 7. Ristock further teaches: The rules engine application method of claim 7, wherein the converting of the rules comprises:
(a) processing the rules in the one or more first formats to extract relevant rules information (see, e.g., ¶ 157 teaching extracting customer data from an external database and building an XLS document; alternatively, see Barbour ¶s 129-130 teaching a taskmaster that extracts data and generates traits);
(b) splitting the relevant rules information into individual trigger conditions (see, e.g., ¶ 131 teaching sending the data to the rules engine as separate interactions); and
(c) tokenizing the individual trigger conditions to map attributes in the individual trigger conditions into standardized terms (see, e.g., ¶ 107 teaching creating a token in the rules authorization tool; see also ¶ 131 teaching a rule language mapping section 1008).
Examiner notes that the rationale for combining Ristock with Loosli and Barbour is provided in the rejection of Claim 7 above.
Claim 9. The combination of Loosli, Barbour, and Ristock teach the limitations of Claim 8. Ristock further teaches: The rules engine application method of claim 8,
(a) wherein the rules in the one or more first formats are stored in a spreadsheet (see, e.g., ¶ 144 teaching a “decision table” that contains several columns and can be exported as a spreadsheet; see also ¶ 157 disclosing substantially the same);
(b) wherein the shared second format is JavaScript Object Notation (JSON) (see ¶ 131 teaching that the data may be packaged as XML or JSON); and
(c) wherein the individual trigger conditions each corresponds to a respective JSON object (see ¶ 131 teaching that the rules and facts may be packaged as JSON string format).
Examiner notes that the rationale for combining Ristock with Loosli and Barbour is provided in the rejection of Claim 7 above.
Claim 10. The combination of Loosli, Barbour, and Ristock teach the limitations of Claim 9. Ristock further teaches: The rules engine application of claim 9,
(a) wherein the processing of the rules comprises: (i) extracting rows and columns of the spreadsheet into a two-dimensional data structure; (ii) removing irrelevant rows and columns to extract the relevant rules information; and (iii) indexing the relevant rules information based on the plurality of document classes (see, e.g., ¶ 144 teaching a “decision table” that contains several columns and can be exported as an editable spreadsheet; see also ¶ 157 disclosing substantially the same);
(b) wherein the splitting of the rules comprises extracting the individual trigger conditions using regex and splitting conditions (see, e.g., ¶ 144 teaching a “decision table” that contains several columns and can be exported as an editable spreadsheet; see also ¶ 157 disclosing substantially the same); and
(c) wherein the tokenizing of the individual trigger conditions comprises: (i) converting the individual trigger conditions into dictionary objects; (ii) consolidating the attributes in the individual trigger conditions into the standardized terms; and (iii) converting each of the individual trigger conditions into the respective JSON object (see ¶ 131 teaching that the rules and facts may be packaged as JSON string format).
Examiner notes that the rationale for combining Ristock with Loosli and Barbour is provided in the rejection of Claim 7 above.
Claim 11. The combination of Loosli, Barbour, and Ristock teach the limitations of Claim 9. Ristock further teaches: The rules engine application method of claim 9, further comprising: storing the rules of the shared second format in a repository, wherein the applying of the rules comprises loading the handler function with the respective JSON object retrieved from the repository (see ¶ 131 teaching that the rules and facts may be packaged as JSON string format; see also ¶ 146 teaching that all business rules are saved in the rules repository 968). Examiner notes that the rationale for combining Ristock with Loosli and Barbour is provided in the rejection of Claim 7 above.
Claim 12. The combination of Loosli, Barbour, and Ristock teach the limitations of Claim 11. That combination further teaches: The rules engine application method of claim 11, further comprising: prior to the applying of the rules, parsing the repository for the rules of the shared second format, wherein the converting of the rules is dependent on the parsing determining that the rules of the shared second format are not available (see, e.g., ¶ 160 teaching determining that certain selected rules were not available during past interactions). Examiner notes that the rationale for combining Ristock with Loosli and Barbour is provided in the rejection of Claim 7 above.
Claim 15. The combination of Loosli and Barbour teach the limitations of Claim 13. Loosli further teaches: The rules engine application method of claim 13,
(a) wherein the class object defines a product category, a product type, a product sub-type, a product booking entity, or combinations thereof (see, e.g., ¶s 42-43 teaching that the class object is a “program type,” i.e., a product type, specifically, a type of credit account product);
(b) wherein the class object comprises a string method for printing the class object, a hash method for returning a hash value of the class object, a conversion method for converting the class object into a corresponding JSON object, or combinations thereof (see, e.g., ¶ 32 teaching utilizing an object-oriented architecture for converting and implementing the data in the computer environment); and
(c) wherein the class object comprises the product matching function, the product matching function configured to group the classes of the at least one product based on the product category, the product type, the product sub-type, the product booking entity, or combinations thereof (see, e.g., ¶s 42-43 teaching that the class object is matched with the qualification rules to identify the data structures that point to what program types the client qualifies for).
Examiner notes that, to the extent that Loosli (or Barbour) fail to expressly teach wherein the class object comprises a string method for printing the class object, a hash method for returning a hash value of the class object, a conversion method for converting the class object into a corresponding JSON object, or combinations thereof, Barbour does, however, teach the use of a “unified ontology.” Barbour’s “unified ontology” is “comprised of at least three ontologies” and “may allow financial institution products from distinct financial institutions to be associated with classification nodes such that similar products from disparate financial institutions may be associated despite their dissimilar names, descriptions, different institutions, etc.” (see ¶ 36). Barbour additionally teaches that the unified ontology allows for the creation of an array of distinct relational databases in “a common Cassandra cluster of ontology data store” (see ¶ 70) as well as that Spark SQL and Cassandra can work together to house and structure the data (see ¶ 63). Thus, Barbour arguably teaches the conversion of data into a common format under a broadest reasonable interpretation of the claim. Nevertheless, for the purpose of compact prosecution, Examiner notes that analogous prior art reference Ristock expressly teaches converting a class object into a corresponding JSON object (see at least Ristock ¶ 131 teaching a fact model editor 1003 that can package the data for a rules engine 964 by converting the data into JSON string format). Ristock is similar to the instant application, Loosli, and Barbour because it relates to using a rules engine to determine the possibility of up-sell, cross-sell, or other business opportunity with the customer (see Ristock ¶ 92).
Therefore, it would have been obvious to one of ordinary skill in the art as of the effective filing date to apply the known technique of converting class objects to a particular data format (as disclosed by Ristock) to the known method and system of determining, based on a client’s existing data and corresponding rules, whether a client qualifies for the financial product cross-sell (as disclosed by Loosli and Barbour). One of ordinary skill in the art would have been motivated to apply the known technique of converting rules and data to a particular data format because different data formats may allow for different data formatting and editing, such as by exporting data in an XLS format that can enable a user to edit rows of test data inside a spreadsheet (see Ristock ¶ 157).
Furthermore, it would have been obvious to one of ordinary skill in the art as of the effective filing date to apply the known technique of converting class objects to a particular data format (as disclosed by Ristock) to the known method and system of determining, based on a client’s existing data and corresponding rules, whether a client qualifies for the financial product cross-sell (as disclosed by Loosli and Barbour), because the claimed invention is merely applying a known technique to a known method ready for improvement to yield predictable results. See KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 406 (2007). In other words, all of the claimed elements were known in the prior art and one skilled in the art could have combined the elements as claimed by known methods with no change in their respective functions, and the combination would have yielded nothing more than predictable results to one of ordinary skill in the art at the time of the invention (i.e., predictable results are obtained by applying the known technique of converting class objects to a particular data format to the known method and system of determining, based on a client’s existing data and corresponding rules, whether a client qualifies for the financial product cross-sell, because predictably converting formats is a known way of executing the application of a set of rules to client financial data when deciding whether to cross-sell financial products). See also MPEP § 2143(I)(D).
Conclusion
The prior art made of record and not relied upon is considered pertinent to Applicant’s disclosure: Chirehdast, US 8,660,943 B1.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAN P MINCARELLI whose telephone number is (571)270-5909. The examiner can normally be reached Monday through Friday, 8:00 AM to 4:30 PM Eastern Time.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Nathan C. Uber, can be reached at (571)270-3923. The fax phone number for the organization where this application or proceeding is assigned is (571)273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/JAN P MINCARELLI/
Primary Examiner, Art Unit 3626
Prosecution Insights