Prosecution Insights
Last updated: April 19, 2026
Application No. 18/529,850

COMPUTER METHOD AND SYSTEM FOR EVENT ANALYTICS

Final Rejection §101§103
Filed
Dec 05, 2023
Examiner
GAVIN, KRISTIN ELIZABETH
Art Unit
3624
Tech Center
3600 — Transportation & Electronic Commerce
Assignee
Lululemon Athletica Canada Inc.
OA Round
2 (Final)
14%
Grant Probability
At Risk
3-4
OA Rounds
3y 8m
To Grant
29%
With Interview

Examiner Intelligence

Grants only 14% of cases
14%
Career Allow Rate
21 granted / 154 resolved
-38.4% vs TC avg
Strong +15% interview lift
Without
With
+15.2%
Interview Lift
resolved cases with interview
Typical timeline
3y 8m
Avg Prosecution
50 currently pending
Career history
204
Total Applications
across all art units

Statute-Specific Performance

§101
38.5%
-1.5% vs TC avg
§103
39.9%
-0.1% vs TC avg
§102
7.9%
-32.1% vs TC avg
§112
9.2%
-30.8% vs TC avg
Black line = Tech Center average estimate • Based on career data from 154 resolved cases

Office Action

§101 §103
DETAILED ACTION This final Office action is responsive to amendments filed February 4th, 2026. Claims 1, 14, 15, 19, 21, and 22 have been amended. Claims 1-22 are presented for examination. 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 . Response to Arguments Applicant’s arguments, see page 18, filed 02/, with respect to the Specification have been fully considered and are persuasive. The Specification objection of 11/04/25 has been withdrawn. Applicant’s arguments, see page 18, filed 02/04/26, with respect to claims 1, 14, 15, 21, and 22 have been fully considered and are persuasive. The claim objections of 11/04/25 has been withdrawn. Applicant’s arguments, see page 18, filed 02/04/26, with respect to claims 14, 19, and 21 have been fully considered and are persuasive. The 35 USC of 11/04/25 has been withdrawn. Applicant's arguments regarding claim rejections under 35 USC 101 filed 02/04/26 have been fully considered but they are not persuasive. On pages 18-20 of the provided remarks, Applicant argues that the amended claims recite statutory subject matter. Beginning on page 19 of the provided remarks, Applicant argues that the claims recite no judicial exceptions. Specifically, Applicant argues that the claims are “inextricably tied to the claimed subject matter such that all limitations are carried out with computing components. Accordingly, the claims recite no mental processes as the claimed processes are carried out with computing components.” Examiner respectfully disagrees and cites the 2019 PEG, “Claims can recite a mental process even if they are claimed as being performed on a computer.” Further, the 2019 PEG states the following, “In evaluating whether a claim that requires a generic computer recites a mental process, examiners should carefully consider the broadest reasonable interpretation of the claim in light of the specification. By way of example, examiners may review the specification to determine if the underlying claimed invention is described as a concept that is performed in the human mind and applicant is merely claiming that concept performed 1) on a generic computer, 2) in a computer environment or 3) is merely using a computer as a tool to perform the concept. In these situations, the claim is considered to recite a mental process.” Examiner asserts that the claimed these elements merely facilitate the claimed functions at a high level of generality and they perform conventional functions and are considered to be general purpose computer components which is supported by Applicant’s specification in Paragraphs 0092-94 and Figures 1-2. Therefore, the claims recite the abstract idea of mental process. Applicant’s arguments are not persuasive. Regarding Step 2A Prong 2 analysis, Applicant argues that the judicial exception is integrated into practical application. Citing Example 46 of the October 2019 Update, Applicant argues that “the embodiments of the pending subject matter can transform user activity data into a universal data shape and using machine learning to improve or modify the logic associated with the activity”. Examiner respectfully disagrees and cites MPEP 2106.05(a), “the claim must be evaluated to ensure the claim itself reflects the disclosed improvement in technology. Intellectual Ventures I LLC v. Symantec Corp., 838 F.3d 1307, 1316, 120 USPQ2d 1353, 1359 (Fed. Cir. 2016) (patent owner argued that the claimed email filtering system improved technology by shrinking the protection gap and mooting the volume problem, but the court disagreed because the claims themselves did not have any limitations that addressed these issues). That is, the claim must include the components or steps of the invention that provide the improvement described in the specification.” If Applicant is asserting that the application of machine learning improves or modifies logic associated with the activity, per the above citation, this improvement needs to be present within the claim. Examiner asserts that the present amendment merely recites the matching of a data structure and value types which as written is an observation, judgment, and evaluation of the human mind using generic computing components as a tool. Applicant’s arguments are not persuasive. Further, Applicant argues that the providing of the final shape is not an abstract idea but that this “can act as a universal data shape to improve the functioning of a computer or an improvement to other technology or technical fields.” Examiner begins by stating that the claimed “providing the first final shape” was not identified as reciting the abstract idea as the provision is claimed at a high-level and regarded as insignificant post-solution activity, which is regarded, per MPEP 2106.05(g), as “"extra-solution activity" can be understood as activities incidental to the primary process or product that are merely a nominal or tangential addition to the claim.” Continuing on in MPEP 2106.05(g), “An example of post-solution activity is an element that is not integrated into the claim as a whole, e.g., a printer that is used to output a report of fraudulent transactions, which is recited in a claim to a computer programmed to analyze and manipulate information about credit card transactions in order to detect whether the transactions were fraudulent.” Similar to the argued printer output, Examiner asserts that the provided first final shape is incidental to the primary process. Applicant’s arguments are not persuasive. Finally, per Step 2B analysis, Applicant argues that the claims as a whole amount to significantly more than any judicial exceptions found therein. Specifically, Applicant argues “embodiments of the claims as a whole can transform user activity data into a universal data shape. This can be important to help analyze data coming from disparate silo-ed systems where the information is may be stored, labelled, or measured differently.” Examiner begins by asserting that the argued “first final shape which can act as a universal data shape” is not analogous to the provided examples of Improvements to Computer Functionality found in MPEP 2106.05(a). For example, the following is stated in MPEP 2106.05(a), “It is important to note that in order for a method claim to improve computer functionality, the broadest reasonable interpretation of the claim must be limited to computer implementation. That is, a claim whose entire scope can be performed mentally, cannot be said to improve computer technology. Synopsys, Inc. v. Mentor Graphics Corp., 839 F.3d 1138, 120 USPQ2d 1473 (Fed. Cir. 2016)”. The examples listed which improve computer-functionality list specific improvements to the computer capabilities versus invoking computers merely as a tool. As stated above, the present amendment merely recites the matching of a data structure and value types which as written is an observation, judgment, and evaluation of the human mind using generic computing components as a tool. Therefore, the 35 USC 101 rejection is maintained. Applicant’s arguments are not persuasive. Applicant's arguments claim rejections under 35 USC 103 filed 02/04/26 have been fully considered but they are not persuasive. On page 20 of the provided remarks, Applicant argues that the cited prior art does not disclose the amended claim limitation. Specifically, Applicant argues that “The models being validated in Pinto are predictive models rather than models, for example, default values, data element relationships, data models, shapes, and event logic.” Examiner begins by asserting that the claimed “model” of the present embodiment is different then the cited predictive model of Pinto. However, the claim does not limit the type of model utilized within the validation. Per [0013] of the as-filed Specification, “Models can be computer programs or code representations of machine learning or artificial intelligence processes that may be trained with datasets to obtain output results for the event analytics.” Therefore, the predictive models of Pinto are analogous to the claimed models of the amended claims. Additionally, Examiner asserts that the cross-validation techniques of Pinto cited in paragraph [0103] are analogous to the amended matching of data elements and values. The 35 USC 103 rejection is maintained. Applicant’s arguments are not persuasive. 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-22 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, 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 whether the claim is directed to a judicial exception (i.e., law of nature, natural phenomenon, and abstract idea), and if so, it must additionally be determined whether the claim is a patent-eligible application of the exception. If an abstract idea is present in the claim, any element or combination of elements in the claim must be sufficient to ensure that the claim amounts to significantly more than the abstract idea itself. Step 1: Independent claims 1 (method), 15 (system), and 22 (non-transitory computer-readable medium) and dependent claims 2-14 and 16-21, respectively, fall within at least one of the four statutory categories of 35 U.S.C. 101: (i) process; (ii) machine; (iii) manufacture; or (iv) composition of matter. Claim 1 is directed to a method (i.e. process), claim 15 is directed to a system (i.e. machine), and claim 22 is directed to a non-transitory computer-readable medium (i.e. manufacture). Step 2A Prong 1: The independent claims recite a computer implemented method of operation in a system including an event analytics server associated with one or more listener module on at least one processor, the method comprising: receiving, using at least one hardware processor a set of event logic comprising an event model defining more than one user triggered event; wherein the event model comprises a set of elements associated with the more than one user triggered event, wherein the set of elements provide: one or more event model object definition (EMOD) wherein the EMOD defines default values and/or a data element relationship within the system; one or more event standard object definition (ESOD) wherein the ESOD, defines a data model, shape, and event logic comprising an event category hierarchy and type associated with one or more user triggered event; one or more transformation objects definition (TOD) wherein the TOD, defines a model and transformation logic for determining a final shape using the ESOD and one or more EMOD; wherein the ESOD comprises one or more EMOD; wherein the TOD follows the shape of the ESOD and comprises one or more transformation paths, wherein the transformation path specifies a location associated with a value in the event standard object definition (ESOD) associated with a EMOD; receiving, by the event analytics server on at least one processor, a user triggered event input wherein the user triggered event input is defined by the event category hierarchy and type, and one or more values associated with the event, receiving, by the event analytics server, one or more context metadata value; associating the one or more context metadata value with the user triggered event input to define an initial user triggered event input; providing the initial user triggered event input to a listener module; identifying, based on evaluating the event category hierarchy and type, the first associated ESOD and the first associated TOD for the user triggered event input; transforming the values associated with the user triggered event input into a first provisional final shape (1 PFS); generating a validation shape (VS) using the associated ESOD to define a required shape structure and required value types; validating the first provisional final shape (1 PFS) against the VS, wherein validating the first provisional final shape (1PFS) against the VS comprises matching a data structure and value types; upon validating the first provisional final shape, identifying the first provisional final shape as a first final shape (1 FFS) and providing the first final shape (Mental Process), which are considered to be abstract ideas (See PEG 2019 and MPEP 2106.05). [Examiner notes the underlined limitations above recite the abstract idea]. The steps/functions disclosed above and in the independent claims recite the abstract idea of Mental Process because the claimed limitations are associating the one or more context metadata value with the user triggered event input to define an initial user triggered event input; identifying, based on evaluating the event category hierarchy and type, the first associated ESOD and the first associated TOD for the user triggered event input; transforming the values associated with the user triggered event input into a first provisional final shape (1 PFS); generating a validation shape (VS) using the associated ESOD to define a required shape structure and required value types; validating the first provisional final shape (1 PFS) against the VS by matching a data structure and value types; upon validating the first provisional final shape, identifying the first provisional final shape as a first final shape (1 FFS), which are functions of the human mind in the form of observation, judgment, and evaluation. The Applicant’s claimed limitations are event handling and analytics, which recite the abstract idea of Mental Process. In addition, dependent claims 2-3, 6, 8, 11-14, 16-21 further narrow the abstract idea and recite further defining generating one or more EMOD associated with one or more user defined shape elements; updating one or more ESOD associated with the one or more user defined shape element; the EMOD; determining that one or more secondary transformations is required for the user triggered event input; generating a second final shape by applying transformation logic to the first final shape; versioning validation; associating one or more context metadata values with the other user triggered event input to define another initial user triggered event input; associating the initial user triggered event input with a secondary analytics server type and secondary set of event logic comprising another event model; transforming the initial user triggered event input to match a set of protocols; monitoring validating of the first provisional final shape, determining common shape types, recommending changes to one or more EMOD, recommending changes to one or more ESOD, determining one or more errors requiring changes to one or more EMOD, determining one or more errors requiring changes to one or more ESOD, generating a new EMOD, and generating a new ESOD; and capturing one or more user gestures. These processes are similar to the abstract idea noted in the independent claims because they further the limitations of the independent claims which recite mental processes. Accordingly, these claim elements do not serve to confer subject matter eligibility to the claims since they recite abstract ideas. Dependent claims 4-5, 7, and 9-10 will be discussed in Prong 2 analysis below. Step 2A Prong 2: In this application, the above “receiving, using at least one hardware processor a set of event logic comprising an event model defining more than one user triggered event; wherein the event model comprises a set of elements associated with the more than one user triggered event, wherein the set of elements provide: one or more event model object definition (EMOD) wherein the EMOD defines default values and/or a data element relationship within the system; one or more event standard object definition (ESOD) wherein the ESOD, defines a data model, shape, and event logic comprising an event category hierarchy and type associated with one or more user triggered event; one or more transformation objects definition (TOD) wherein the TOD, defines a model and transformation logic for determining a final shape using the ESOD and one or more EMOD; wherein the ESOD comprises one or more EMOD; wherein the TOD follows the shape of the ESOD and comprises one or more transformation paths, wherein the transformation path specifies a location associated with a value in the event standard object definition (ESOD) associated with a EMOD; receiving, by the event analytics server on at least one processor, a user triggered event input wherein the user triggered event input is defined by the event category hierarchy and type, and one or more values associated with the event; receiving, by the event analytics server, one or more context metadata value; providing the initial user triggered event input to a listener module; providing the first final shape” steps/functions of the independent claims would not account for additional elements that integrate the judicial exception (e.g. abstract idea) into a practical application because receiving/storing data and displaying data merely add insignificant extra-solution activity and merely adds the words to apply it with the judicial exception. Also, the claimed “A computer; a system including an event analytics server associated with one or more listener module on at least one processor; at least one hardware processor a set of event logic; a user interface; a secondary analytics server; a tag manager component; A processing system that includes one or more processors and one or more memories coupled with the one or more processors; a user device comprising a hardware processor and an interface; Non-transitory computer readable medium having stored thereon machine interpretable instructions executable by a processor” would not account for additional elements that integrate the judicial exception (e.g. abstract idea) into a practical application because the claimed structure merely adds the words to apply it with the judicial exception and mere instructions to implement an abstract idea on a computer (See PEG 2019 and MPEP 2106.05). In addition, dependent claims 2-3, 6, 8, 11-14, 16-21 further narrow the abstract idea and dependent claims 2, 4-5, 7, 9-11, 13, 16-18, and 20 additionally recite “receiving one or more user defined shape element”; “providing comprises transmitting and/or outputting the first final shape to a user interface”; “providing comprises transmitting and/or outputting the first final shape to a secondary analytics server”; “providing comprises outputting the second final shape to a secondary analytics server”; “transmitting the final shape to a tag manager component”; “receiving a plurality of user triggered events and providing a plurality of first final shapes”; “receiving another user triggered event input”; “sending the transformed initial user triggered event input to the secondary analytics server”; “provide the user triggered event input”; “receives one or more user defined shape element”; “sends the transformed initial user triggered event input to the secondary analytics server”; “receives a plurality of user triggered events and provides a plurality of first final shapes” which do not account for additional elements that integrate the judicial exception (e.g. abstract idea) into a practical application because receiving/storing data and displaying data merely add insignificant extra-solution activity and the claimed “the event analytics server”, “user interface”, “secondary analytics server”, “a tag manager component”, “a user device comprising a hardware processor and an interface” which do not account for additional elements that integrate the judicial exception (e.g. abstract idea) into a practical application because the claimed structure merely adds the words to apply it with the judicial exception and mere instructions to implement an abstract idea on a computer (See PEG 2019 and MPEP 2106.05). The claimed “A computer; a system including an event analytics server associated with one or more listener module on at least one processor; at least one hardware processor a set of event logic; a user interface; a secondary analytics server; a tag manager component; A processing system that includes one or more processors and one or more memories coupled with the one or more processors; a user device comprising a hardware processor and an interface; Non-transitory computer readable medium having stored thereon machine interpretable instructions executable by a processor” are recited so generically (no details whatsoever are provided other than that they are general purpose computing components and regular office supplies) that they represent no more than mere instructions to apply the judicial exception on a computer. These limitations can also be viewed as nothing more than an attempt to generally link the use of the judicial exception to the technological environment of a computer. Even when viewed in combination, the additional elements in the claims do no more than use the computer components as a tool. There is no change to the computers and other technology that is recited in the claim, and thus the claims do not improve computer functionality or other technology (See PEG 2019). Step 2B: When analyzing the additional element(s) and/or combination of elements in the claim(s) other than the abstract idea per se the claim limitations amount(s) to no more than: a general link of the use of an abstract idea to a particular technological environment and merely amounts to the application or instructions to apply the abstract idea on a computer (See MPEP 2106.05 and PEG 2019). Further, method claims 1-14; system claims 15-21; and non-transitory computer-readable medium claim 22 recite “A computer; a system including an event analytics server associated with one or more listener module on at least one processor; at least one hardware processor a set of event logic; a user interface; a secondary analytics server; a tag manager component; A processing system that includes one or more processors and one or more memories coupled with the one or more processors; a user device comprising a hardware processor and an interface; Non-transitory computer readable medium having stored thereon machine interpretable instructions executable by a processor”; however, these elements merely facilitate the claimed functions at a high level of generality and they perform conventional functions and are considered to be general purpose computer components which is supported by Applicant’s specification in Paragraphs 0092-94 and Figures 1-2. The Applicant’s claimed additional elements are mere instructions to implement the abstract idea on a general purpose computer and generally link of the use of an abstract idea to a particular technological environment. Also, the above “receiving, using at least one hardware processor a set of event logic comprising an event model defining more than one user triggered event; wherein the event model comprises a set of elements associated with the more than one user triggered event, wherein the set of elements provide: one or more event model object definition (EMOD) wherein the EMOD defines default values and/or a data element relationship within the system; one or more event standard object definition (ESOD) wherein the ESOD, defines a data model, shape, and event logic comprising an event category hierarchy and type associated with one or more user triggered event; one or more transformation objects definition (TOD) wherein the TOD, defines a model and transformation logic for determining a final shape using the ESOD and one or more EMOD; wherein the ESOD comprises one or more EMOD; wherein the TOD follows the shape of the ESOD and comprises one or more transformation paths, wherein the transformation path specifies a location associated with a value in the event standard object definition (ESOD) associated with a EMOD; receiving, by the event analytics server on at least one processor, a user triggered event input wherein the user triggered event input is defined by the event category hierarchy and type, and one or more values associated with the event; receiving, by the event analytics server, one or more context metadata value; providing the initial user triggered event input to a listener module; providing the first final shape” steps/functions of the independent claims would not account for significantly more than the abstract idea because receiving data and displaying/presenting data (See MPEP 2106.05) have been identified as well-known, routine, and conventional steps/functions to one of ordinary skill in the art. When viewed as a whole, these additional claim element(s) do not provide meaningful limitation(s) to transform the abstract idea into a patent eligible application of the abstract idea such that the claim(s) amounts to significantly more than the abstract idea itself. In addition, claims 2-3, 6, 8, 11-14, 16-21 further narrow the abstract idea identified in the independent claims. The Examiner notes that the dependent claims merely further define the data being analyzed and how the data is being analyzed. Similarly, claims 2, 4-5, 7, 9-11, 13, 16-18, and 20 additionally recite “receiving one or more user defined shape element”; “providing comprises transmitting and/or outputting the first final shape to a user interface”; “providing comprises transmitting and/or outputting the first final shape to a secondary analytics server”; “providing comprises outputting the second final shape to a secondary analytics server”; “transmitting the final shape to a tag manager component”; “receiving a plurality of user triggered events and providing a plurality of first final shapes”; “receiving another user triggered event input”; “sending the transformed initial user triggered event input to the secondary analytics server”; “provide the user triggered event input”; “receives one or more user defined shape element”; “sends the transformed initial user triggered event input to the secondary analytics server”; “receives a plurality of user triggered events and provides a plurality of first final shapes” which do not account for additional elements that amount to significantly more than the abstract idea because receiving data and displaying/presenting data (See MPEP 2106.05) have been identified as well-known, routine, and conventional steps/functions to one of ordinary skill in the art and the claimed “the event analytics server”, “user interface”, “secondary analytics server”, “a tag manager component”, “a user device comprising a hardware processor and an interface” which do not account for additional elements that amount to significantly more than the abstract idea because the claimed structure merely amounts to the application or instructions to apply the abstract idea on a computer and does not move beyond a general link of the use of an abstract idea to a particular technological environment (See MPEP 2106.05). The additional limitations of the independent and dependent claim(s) when considered individually and as an ordered combination do not amount to significantly more than the abstract idea. The examiner has considered the dependent claims in a full analysis including the additional limitations individually and in combination as analyzed in the independent claim(s). Therefore, the claim(s) are rejected under 35 U.S.C. 101 as being directed to non-statutory 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. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention. Claim(s) 1-22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ash (U.S 2022/0292525 A1) in view of Pinto (U.S 2005/0234753 A1). Claim 1 Regarding Claim 1, Ash discloses the following: A computer implemented method of operation in a system including an event analytics server associated with one or more listener module on at least one processor, the method comprising [see at least Paragraph 0005 for reference to the multi-service business platform including a set of processors that may execute a set of computer-executable instructions that cause the set of processors to execute one or more listening threads; Paragraph 0006 for reference to the computer - executable instructions may further cause the set of processors to configure a custom listening thread that monitors the third -part data source for event instances of the new event type; Paragraph 0008 for reference to a computer-implemented method for maintaining unified events; Paragraph 0121 for reference to the auto-discovery engine including various methods, systems, components, modules, services, processes, applications, interfaces, and other elements; Figure 19 and related text regarding item 1914 ‘Analytics Module’ and item 1900-1 ‘Feedback Module’] receiving, using at least one hardware processor a set of event logic comprising an event model defining more than one user triggered event [see at least Paragraph 0143 for reference to the event extraction system receiving entity information including entity values and entity types extracted by the entity extraction system to assist in the event classification wherein an event classification model receives entity information along with features to classify events; Paragraph 0147 for reference to knowledge graph may further include event nodes which represent events that are identified by the event extraction system; Paragraph 0151 for reference to event classification model may refer to a machine learned model that is configured to receive features that are extracted from one or more documents and that output one or more potential events that may be indicated by the documents; Figure 20 and related text regarding item 2010 ‘Receive Request To Create New Client-Specific Service System’ and item 2012 ‘Receive One Or More Customization Parameters’; Figure 50 and related text regarding item 1002 ‘Receive user request for a custom object creation including custom object information’] wherein the event model comprises a set of elements associated with the more than one user triggered event, wherein the set of elements provide [see at least Paragraph 0143 for reference to an event classification model receives entity information along with features to classify events; Paragraph 0151 for reference to event classification model may refer to a machine learned model that is configured to receive features that are extracted from one or more documents and that output one or more potential events that may be indicated by the documents; Paragraph 0329 for reference to ontology and the instance knowledge graph may include the custom object with other custom objects and/or core objects (e.g., contact objects, company objects, deal objects, and/or ticket objects) along with one or more associations (e.g., as added or selected associations by the user) between the objects] one or more event model object definition (EMOD) wherein the EMOD defines default values and/or a data element relationship within the system [see at least Paragraph 0076 for reference to the multi-service business platform having a preset or fixed core object; Paragraph 0348 for reference to a core object having a name, a type, and properties; Figure 46 and related text regarding item 634 ‘core objects’] one or more event standard object definition (ESOD) wherein the ESOD, defines a data model, shape, and event logic comprising an event category hierarchy and type associated with one or more user triggered event [see at least Paragraph 0309 for reference to custom objects being created to be specific to each user's (e.g., client's) business and the custom objects may be used on the multi-service business platform; Paragraph 0310 for reference to custom objects definition may include an object type, properties (e.g., some properties may be set on an instance), and possible associations; Paragraph 0346 for reference to a user may decide to define associations in terms of hierarchy by defining names of associations (e.g., user may name one association as “Parent” between two objects and/or may name another association as “child” between the same two objects but in the opposite direction) based on their business model; Paragraph 0419 for reference to the user may select a custom object and may define the types of events that may occur with respect to the custom object, such that the custom object may be the primary object of the new event record; Figure 46 and related text regarding item 632 ‘custom objects’] one or more transformation objects definition (TOD) wherein the TOD, defines a model and transformation logic for determining a final shape using the ESOD and one or more EMOD [see at least Paragraph 0306 for reference to two objects may be associated using one or more different types of associations and the associations may be directed in both directions (e.g., association and inverse association); Paragraph 0316 for reference to instances of associations between the object instances (e.g., between custom object instances and/or core object instances) may be used to determine these properties; Figure 46 and related text regarding item 636 ‘associations’] wherein the ESOD comprises one or more EMOD [see at least Paragraph 0361 for reference to custom objects existing with core objects in the multi-system business platform; Paragraph 0361 for reference to custom objects may be linked and/or associated to the core objects or other custom objects; Paragraph 0419 for reference to each event may occur with respect to one or more object types that may be associated with each respective event] wherein the TOD follows the shape of the ESOD and comprises one or more transformation paths, wherein the transformation path specifies a location associated with a value in the event standard object definition (ESOD) associated with a EMOD [see at least Paragraph 0315 for reference to the example of associations between objects determining the location properties of the corresponding objects; Paragraph 0316 for reference to instances of associations between the object instances (e.g., between custom object instances and/or core object instances) may be used to determine these properties; Paragraph 0419 for reference to the user defining the associations that give rise to the event or other actions that occur that may trigger the event; Figure 46 and related text regarding item 636 ‘associations’] receiving, by the event analytics server on at least one processor, a user triggered event input wherein the user triggered event input is defined by the event category hierarchy and type, and one or more values associated with the event [see at least Paragraph 0143 for reference to the event extraction system receiving entity information including entity values and entity types extracted by the entity extraction system to assist in the event classification wherein an event classification model receives entity information along with features to classify events; Paragraph 0369 for reference to a user request for a custom object creation including custom object information is received; Paragraph 0420 for reference to a user may define a custom object (or multiple custom objects) and may define the events that occur with respect to the custom object and other objects (custom objects, core objects, and/or standard objects) that may be related to the client's business via the customization system; Figure 20 and related text regarding item 2010 ‘Receive Request To Create New Client-Specific Service System’ and item 2012 ‘Receive One Or More Customization Parameters’; Figure 50 and related text regarding item 1002 ‘Receive user request for a custom object creation including custom object information’] receiving, by the event analytics server, one or more context metadata value [see at least Paragraph 0328 for reference to the customization system executing a business logic/sensible default service (e.g., may use business logic and/or sensible defaults) to interpret custom object information in order to convert the custom object information into custom object metadata; Figure 50 and related text regarding item 1004 ‘Interpret and convert custom object information into custom object metadata’] associating the one or more context metadata value with the user triggered event input to define an initial user triggered event input [see at least Paragraph 0369 for reference to custom object information may be interpreted and converted into custom object metadata and custom object metadata may be converted into language-independent data creating a custom object; Figure 50 and related text regarding item 1008 ‘Convert custom object metadata into a language independent data creating a custom object’] providing the initial user triggered event input to a listener module [see at least Paragraph 0419 for reference to the customization system may further configure a custom listening thread that listens for a new event type, for example, from an event source identified by the configuring user; Paragraph 0420 for reference to the event system may instantiate and execute listening threads that may listen to various services of the multi-service business platform (e.g., payment services, ticketing services, CRM services, CMS services, machine-learning services, geolocation services, identity resolution services, telemetry services, and/or the like) and/or external event sources for particular types of data and may update the event data store(s) and/or the knowledge graph based on the data obtained from the various services; Figure 50 and related text regarding item 1006 ‘Insert and store custom object metadata in a relational-type database’] identifying, based on evaluating the event category hierarchy and type, the first associated ESOD and the first associated TOD for the user triggered event input [see at least Paragraph 0419 for reference to the customization system may update the ontology (e.g., ontology datastore) to reflect the new type of event and/or may update schemas of one or more object event records to reflect the new event type that is being tracked with respect to one or more respective object types; Paragraph 0420 for reference to event instances corresponding to the custom object may be detected and recorded when data is received from a specific source] providing the first final shape [see at least Paragraph 00322 for reference to the multi-service business platform may communicate with user device(s) (e.g., user may be using the customization system from the user device to create custom objects via network), client device(s) (e.g., tracking various activities of the client device of a customer for purposes of sales and marketing with respect to custom objects), and various external information sources; Figure 50 and related text regarding item 1010 ‘Send custom object in language independent data form to a user device and/or services of an integrated business platform for use with at least one of a marketing process, a sales process, and a customer service process’] While Ash discloses the limitations above, it does not disclose transforming the values associated with the user triggered event input into a first provisional final shape (1 PFS); generating a validation shape (VS) using the associated ESOD to define a required shape structure and required value types; validating the first provisional final shape (1 PFS) against the VS, wherein validating the first provisional final shape (1PFS) against the VS comprises matching a data structure and value types; and upon validating the first provisional final shape, identifying the first provisional final shape as a first final shape (1 FFS) and providing the first final shape. However, Pinto discloses the following: transforming the values associated with the user triggered event input into a first provisional final shape (1 PFS) [see at least Paragraph 0044 for reference to analysis informs the appropriate variable transformation to maximize predictive power to Supplement the automatic transformation of variables to that purpose preceding or following dimension reduction; Paragraph 0052 for reference to a model method being selected and fitted to convergence with the sample dataset; Paragraph 0098 for reference to fit or train the model to the sample subset of the historical data using the predictive variables generated by a set of variable transformation to maximum univariate predictive capability and a set of dimension reduction filters to retain only the most predictive subgroup of variables, including up to level of interaction; Figure 4 and related text regarding item 72 ‘Dimension Reduction’, item 74 ‘Model Generation’, and item 82 ‘Variable Transformation’] generating a validation shape (VS) using the associated ESOD to define a required shape structure and required value types [see at least Paragraph 0042 for reference to the model development platform including candidate model generation; Paragraph 0108 for reference to the model generation platform automates a modeling process that leads to a candidate model for assessment; Figure 1 and related text regarding item 20 ‘Validate Model Process’; Figure 4 and related text regarding item 74 ‘candidate model generation’; Figure 12 and related text regarding item 210 ‘Select Validation Datasets’] validating the first provisional final shape (1 PFS) against the VS, wherein validating the first provisional final shape (1PFS) against the VS comprises matching a data structure and value types [see at least Paragraph 0103 for reference to after a candidate model has been determined in the model development procedure, the model is applied to the holdout or validation subset for comparison; Paragraph 0103 for reference to selected measures, for example, the similarity of the c-statistics (obtained from the ROC curves) and the cumulative and non-cumulative gain functions provide the basis for candidate model validation; Paragraph 0103 for reference to the validation set being fitted independently and the common variables compared; Paragraph 0195 for reference to Validating the model generation process involves a comparison of the proposed model candidate features to the initial entry information on the development dataset and the targeted values of the key features together with a validation of the candidate using the hold-out validation dataset; Paragraph 0210 for reference to the activation of a compare file variable statistics displaying a side-by-side comparison of model variables; Figure 1 and related text regarding item 20 ‘Validate Model Process’ and item 22 ‘Evaluate Model’; Figure 4 and related text regarding item 76 ‘Model Process Validation’; Figure 12 and related text regarding item 214 ‘Evaluate Performance Generalization’; Figure 25A and related text regarding an exemplary graphical user representation of a gains chart and some statistical results comparison of a predictive model developed from a sample dataset and an application of the same model to a validation dataset] upon validating the first provisional final shape, identifying the first provisional final shape as a first final shape (1 FFS) and providing the first final shape [see at least Paragraph 0036 for reference to deployment of model including delivering the model to a client for use with current and future data that is similar to the originally analyzed data referenced in the database; Paragraph 0052 for reference to the validated model generated processes a final model; Paragraph 0150 for reference to after completing the selections for the candidate model properties and model constraints which serve as descriptive guides or embedded filters parameters for selecting a final model; Figure 4 and related text regarding item 78 ‘Final Model Selection’; Figure 5 and related text regarding item 110 ‘Final Model Selection’] Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the events modeling method of Ash to include the model shape validation and output ability of Pinto. By enforcing a carefully managed project paradigm, models can be generated, updated, changed, reviewed, and deployed in a high-volume production process, at lower cost, and with better results, as stated by Pinto (Paragraph 0035). Claim 2 While the combination of Ash and Pinto disclose the limitations above, regarding Claim 2, Ash discloses the following: receiving one or more user defined shape element, generating one or more EMOD associated with the one or more user defined shape element, and updating one or more ESOD associated with the one or more user defined shape element [see at least Paragraph 0310 for reference to custom objects definition may include an object type, properties (e.g., some properties may be set on an instance), and possible associations; Paragraph 0348 for reference to a core object having a name, a type, and properties; Paragraph 0363 for reference to creating or updating properties for the custom objects; Paragraph 0420 for reference to a user may define a custom object (or multiple custom objects) and may define the events that occur with respect to the custom object and other objects (custom objects, core objects, and/or standard objects) that may be related to the client's business via the customization system] Claim 3 While the combination of Ash and Pinto disclose the limitations above, regarding Claim 3, Ash discloses the following: wherein the one or more event model object definition (EMOD) defines a nested, hierarchical, or recursive data element relationship within the system [see at least Paragraph 0076 for reference to the multi-service business platform having a preset or fixed core object; Paragraph 0346 for reference to a user may decide to define associations in terms of hierarchy by defining names of associations (e.g., user may name one association as “Parent” between two objects and/or may name another association as “child” between the same two objects but in the opposite direction) based on their business model; Paragraph 0348 for reference to a core object having a name, a type, and properties; Figure 46 and related text regarding item 634 ‘core objects’] Claim 4 While the combination of Ash and Pinto disclose the limitations above, regarding Claim 4, Ash discloses the following: wherein providing comprises transmitting and/or outputting the first final shape to a user interface [see at least Paragraph 00322 for reference to the multi-service business platform may communicate with user device(s) (e.g., user may be using the customization system from the user device to create custom objects via network), client device(s) (e.g., tracking various activities of the client device of a customer for purposes of sales and marketing with respect to custom objects), and various external information sources; Figure 50 and related text regarding item 1010 ‘Send custom object in language independent data form to a user device and/or services of an integrated business platform for use with at least one of a marketing process, a sales process, and a customer service process’] Claim 5 While the combination of Ash and Pinto disclose the limitations above, Ash does not disclose wherein providing comprises transmitting and/or outputting the first final shape to a secondary analytics server. Regarding Claim 5, Pinto discloses the following: wherein providing comprises transmitting and/or outputting the first final shape to a secondary analytics server [see at least Paragraph 0036 for reference to deployment of model including delivering the model to a client for use with current and future data that is similar to the originally analyzed data referenced in the database; Paragraph 0052 for reference to the validated model generated processes a final model; Paragraph 0139 for reference to server pipelining may be enhanced to be able to handle a large number of concurrent active models and new products incorporating models; Figure 1 and related text regarding item 24 ‘Deploy Model’] Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the events modeling method of Ash to include the deployment method of Pinto. By enforcing a carefully managed project paradigm, models can be generated, updated, changed, reviewed, and deployed in a high-volume production process, at lower cost, and with better results, as stated by Pinto (Paragraph 0035). Claim 6 While the combination of Ash and Pinto disclose the limitations above, Ash does not disclose determining that one or more secondary transformations is required for the user triggered event input, and generating a second final shape by applying transformation logic to the first final shape. Regarding Claim 6, Pinto discloses the following: determining that one or more secondary transformations is required for the user triggered event input [see at least Paragraph 0044 for reference to analysis informs the appropriate variable transformation to maximize predictive power to Supplement the automatic transformation of variables to that purpose preceding or following dimension reduction; Paragraph 0052 for reference to a model method being selected and fitted to convergence with the sample dataset; Paragraph 0098 for reference to fit or train the model to the sample subset of the historical data using the predictive variables generated by a set of variable transformation to maximum univariate predictive capability and a set of dimension reduction filters to retain only the most predictive subgroup of variables, including up to level of interaction; Figure 4 and related text regarding item 72 ‘Dimension Reduction’, item 74 ‘Model Generation’, and item 82 ‘Variable Transformation’] generating a second final shape by applying transformation logic to the first final shape [see at least Paragraph 0205 for reference to the model development process the full development dataset is subjected to the same process, resulting in a final candidate model and that model is applied to the sample dataset and to the validation dataset with the final candidate model equation and the results displayed in a report; Paragraph 0223-0224 for reference to the revision of completed models wherein the final model is rejected and re-analyzed] Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the events modeling method of Ash to include the secondary transformation and secondary final shape method of Pinto. By enforcing a carefully managed project paradigm, models can be generated, updated, changed, reviewed, and deployed in a high-volume production process, at lower cost, and with better results, as stated by Pinto (Paragraph 0035). Claim 7 While the combination of Ash and Pinto disclose the limitations above, Ash does not disclose providing comprises outputting the second final shape to a secondary analytics server. Regarding Claim 7, Pinto discloses the following: providing comprises outputting the second final shape to a secondary analytics server [see at least Paragraph 0036 for reference to deployment of model including delivering the model to a client for use with current and future data that is similar to the originally analyzed data referenced in the database; Paragraph 0052 for reference to the validated model generated processes a final model; Paragraph 0139 for reference to server pipelining may be enhanced to be able to handle a large number of concurrent active models and new products incorporating models; Figure 1 and related text regarding item 24 ‘Deploy Model’] Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the events modeling method of Ash to include the deployment method of Pinto. By enforcing a carefully managed project paradigm, models can be generated, updated, changed, reviewed, and deployed in a high-volume production process, at lower cost, and with better results, as stated by Pinto (Paragraph 0035). Claim 8 While the combination of Ash and Pinto disclose the limitations above, Ash does not disclose versioning validation wherein a hierarchical version identifier associated with the event analytics server, the ESOD and the one or more EMOD associated with the ESOD share one or more hierarchical elements within the version identifier. Regarding Claim 8, Pinto discloses the following: versioning validation wherein a hierarchical version identifier associated with the event analytics server, the ESOD and the one or more EMOD associated with the ESOD share one or more hierarchical elements within the version identifier [see at least Paragraph 0103 for reference to If the model generation process fails validation then the process is revised using model persistence analysis; Paragraph 0103 for reference to after a candidate model has been determined in the model development procedure, the model is applied to the holdout or validation subset for comparison; Paragraph 0103 for reference to selected measures, for example, the similarity of the c-statistics (obtained from the ROC curves) and the cumulative and non-cumulative gain functions provide the basis for candidate model validation; Paragraph 0195 for reference to Validating the model generation process involves a comparison of the proposed model candidate features to the initial entry information on the development dataset and the targeted values of the key features together with a validation of the candidate using the hold-out validation dataset; Figure 1 and related text regarding item 20 ‘Validate Model Process’ and item 22 ‘Evaluate Model’; Figure 4 and related text regarding item 76 ‘Model Process Validation’; Figure 12 and related text regarding the model process validation] Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the events modeling method of Ash to include the versioning validation method of Pinto. By enforcing a carefully managed project paradigm, models can be generated, updated, changed, reviewed, and deployed in a high-volume production process, at lower cost, and with better results, as stated by Pinto (Paragraph 0035). Claim 9 While the combination of Ash and Pinto disclose the limitations above, regarding Claim 9, Ash discloses the following: transmitting the final shape to a tag manager component [see at least Paragraph 00322 for reference to the multi-service business platform may communicate with user device(s) (e.g., user may be using the customization system from the user device to create custom objects via network), client device(s) (e.g., tracking various activities of the client device of a customer for purposes of sales and marketing with respect to custom objects), and various external information sources; Paragraph 0323 for reference to the multi-service business platform communicating with integrator devices which are devices used by third-party integrator users to create and define a series of custom objects; Figure 50 and related text regarding item 1010 ‘Send custom object in language independent data form to a user device and/or services of an integrated business platform for use with at least one of a marketing process, a sales process, and a customer service process’] Claim 10 While the combination of Ash and Pinto disclose the limitations above, regarding Claim 10, Ash discloses the following: receiving a plurality of user triggered events and providing a plurality of first final shapes, wherein the plurality of user triggered events are triggered simultaneously [see at least Paragraph 0143 for reference to the event extraction system receiving entity information including entity values and entity types extracted by the entity extraction system to assist in the event classification wherein an event classification model receives entity information along with features to classify events; Paragraph 0369 for reference to a user request for a custom object creation including custom object information is received; Paragraph 0420 for reference to a user may define a custom object (or multiple custom objects) and may define the events that occur with respect to the custom object and other objects (custom objects, core objects, and/or standard objects) that may be related to the client's business via the customization system; Figure 20 and related text regarding item 2010 ‘Receive Request To Create New Client-Specific Service System’ and item 2012 ‘Receive One Or More Customization Parameters’; Figure 50 and related text regarding item 1002 ‘Receive user request for a custom object creation including custom object information’] Claim 11 While the combination of Ash and Pinto disclose the limitations above, regarding Claim 11, Ash discloses the following: receiving another user triggered event input, wherein the other user triggered event input is associated with user engagement [see at least Paragraph 0367 for reference to the user went in and added a new property, the new property may show up in this list, and the user may trigger logic based on values of the “service” custom objects; Paragraph 0369 for reference to a user request for a custom object creation including custom object information is received; Paragraph 0420 for reference to a user may define a custom object (or multiple custom objects) and may define the events that occur with respect to the custom object and other objects (custom objects, core objects, and/or standard objects) that may be related to the client's business via the customization system; Figure 20 and related text regarding item 2010 ‘Receive Request To Create New Client-Specific Service System’ and item 2012 ‘Receive One Or More Customization Parameters’; Figure 50 and related text regarding item 1002 ‘Receive user request for a custom object creation including custom object information’] associating one or more context metadata values with the other user triggered event input to define another initial user triggered event input [see at least Paragraph 0369 for reference to custom object information may be interpreted and converted into custom object metadata and custom object metadata may be converted into language-independent data creating a custom object; Figure 50 and related text regarding item 1008 ‘Convert custom object metadata into a language independent data creating a custom object’] Claim 12 While the combination of Ash and Pinto disclose the limitations above, Ash does not disclose associating the initial user triggered event input with a secondary analytics server type and secondary set of event logic comprising another event model. Regarding Claim 12, Pinto discloses the following: associating the initial user triggered event input with a secondary analytics server type and secondary set of event logic comprising another event model [see at least Paragraph 0037 for reference to input devices enabling a user to interact with the model platform to generate a model by a series of steps; Paragraph 0039 for reference to the model generation platform being based on a project paradigm wherein the model development platform automatically stores structured project information that captures a state of the project at successive steps in generating the model] Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the events modeling method of Ash to include the association method of Pinto. By enforcing a carefully managed project paradigm, models can be generated, updated, changed, reviewed, and deployed in a high-volume production process, at lower cost, and with better results, as stated by Pinto (Paragraph 0035). Claim 13 While the combination of Ash and Pinto disclose the limitations above, Ash does not disclose transforming the initial user triggered event input to match a set of protocols for the secondary analytics server, and sending the transformed initial user triggered event input to the secondary analytics server. Regarding Claim 13, Pinto discloses the following: transforming the initial user triggered event input to match a set of protocols for the secondary analytics server and sending the transformed initial user triggered event input to the secondary analytics server [see at least Paragraph 0037 for reference to input devices enabling a user to interact with the model platform to generate a model by a series of steps; Paragraph 0038 for reference to the system being implemented in a client-server mod using a server on a network wherein access to the features of the model generation platform software being permitted using an application service provider (ASP) model of distribution such as a web service over the internet] Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the events modeling method of Ash to include the distribution method of Pinto. By enforcing a carefully managed project paradigm, models can be generated, updated, changed, reviewed, and deployed in a high-volume production process, at lower cost, and with better results, as stated by Pinto (Paragraph 0035). Claim 14 While the combination of Ash and Pinto disclose the limitations above, regarding Claim 14, Ash discloses the following: one or more operations selected from a group of providing additional context metadata for the user triggered event input, monitoring validating of the first provisional final shape, determining common shape types, recommending changes to one or more EMOD, recommending changes to one or more ESOD, determining one or more errors requiring changes to one or more EMOD, determining one or more errors requiring changes to one or more ESOD, generating a new EMOD, and generating a new ESOD [see at least Paragraph 0316 for reference to the multi-service business platform may provide prompts for a user to define inputs into a machine learning model, e.g., the user may submit via prompts several properties (e.g., how often does student attend, how many classes is student signed up for, subscription plan, etc.) that may impact whether a student may be likely or unlikely to attend a class and the machine learning model may be used to perform calculations based on these inputs; Paragraph 0381 for reference to instances of custom objects may be used with machine learning system to train machine-learned models that may be used with the user (e.g., related to a user's business) for all objects (e.g., custom objects and core objects); Paragraph 0397 for reference to machine learning process may use the feedback to train the artificial intelligence system to produce the duplicate likelihood value that approximates the corresponding duplicate entity indication value (e.g., minimizes the error value)] Claim 15 Regarding Claim 15, Ash discloses the following: A processing system that includes one or more processors and one or more memories coupled with the one or more processors, the processing system for event handling and analytics, the system comprising an event analytics server associated with one or more listener module [see at least Paragraph 0005 for reference to the multi-service business platform including a set of processors that may execute a set of computer-executable instructions that cause the set of processors to execute one or more listening threads; Paragraph 0006 for reference to the computer - executable instructions may further cause the set of processors to configure a custom listening thread that monitors the third -part data source for event instances of the new event type; Paragraph 0121 for reference to the auto-discovery engine including various methods, systems, components, modules, services, processes, applications, interfaces, and other elements; Figure 19 and related text regarding item 1914 ‘Analytics Module’ and item 1900-1 ‘Feedback Module’] one or more non-transitory memory storing a set of event logic comprising an event model defining more than one user triggered event [see at least Paragraph 0012 for reference to a non-transitory computer readable storage medium having a plurality of instructions stored thereon which, when executed across one or more processors, causes at least a portion of the one or more processors to perform operations; Paragraph 0201 for reference to storage devices being any suitable type of computer readable mediums; Figure 14 and related text regarding item 320 ‘storage system’] wherein the event model comprises a set of elements associated with the more than one user triggered event, wherein the set of elements provide [see at least Paragraph 0143 for reference to an event classification model receives entity information along with features to classify events; Paragraph 0151 for reference to event classification model may refer to a machine learned model that is configured to receive features that are extracted from one or more documents and that output one or more potential events that may be indicated by the documents; Paragraph 0329 for reference to ontology and the instance knowledge graph may include the custom object with other custom objects and/or core objects (e.g., contact objects, company objects, deal objects, and/or ticket objects) along with one or more associations (e.g., as added or selected associations by the user) between the objects] one or more event model object definition (EMOD) wherein the EMOD defines default values and/or a data element relationship within the system [see at least Paragraph 0076 for reference to the multi-service business platform having a preset or fixed core object; Paragraph 0348 for reference to a core object having a name, a type, and properties; Figure 46 and related text regarding item 634 ‘core objects’] one or more event standard object definition (ESOD) wherein the ESOD, defines a data model, shape, and event logic comprising an event category hierarchy and type associated with one or more user triggered event [see at least Paragraph 0309 for reference to custom objects being created to be specific to each user's (e.g., client's) business and the custom objects may be used on the multi-service business platform; Paragraph 0310 for reference to custom objects definition may include an object type, properties (e.g., some properties may be set on an instance), and possible associations; Paragraph 0346 for reference to a user may decide to define associations in terms of hierarchy by defining names of associations (e.g., user may name one association as “Parent” between two objects and/or may name another association as “child” between the same two objects but in the opposite direction) based on their business model; Paragraph 0419 for reference to the user may select a custom object and may define the types of events that may occur with respect to the custom object, such that the custom object may be the primary object of the new event record; Figure 46 and related text regarding item 632 ‘custom objects’] one or more transformation objects definition (TOD) wherein the TOD, defines a model and transformation logic for determining a final shape using the ESOD and one or more EMOD [see at least Paragraph 0306 for reference to two objects may be associated using one or more different types of associations and the associations may be directed in both directions (e.g., association and inverse association); Paragraph 0316 for reference to instances of associations between the object instances (e.g., between custom object instances and/or core object instances) may be used to determine these properties; Figure 46 and related text regarding item 636 ‘associations’] wherein the ESOD comprises one or more EMOD [see at least Paragraph 0361 for reference to custom objects existing with core objects in the multi-system business platform; Paragraph 0361 for reference to custom objects may be linked and/or associated to the core objects or other custom objects; Paragraph 0419 for reference to each event may occur with respect to one or more object types that may be associated with each respective event] wherein the TOD follows the shape of the ESOD and comprises one or more transformation paths, wherein the transformation path specifies a location associated with a value in the event standard object definition (ESOD) associated with a EMOD [see at least Paragraph 0315 for reference to the example of associations between objects determining the location properties of the corresponding objects; Paragraph 0316 for reference to instances of associations between the object instances (e.g., between custom object instances and/or core object instances) may be used to determine these properties; Paragraph 0419 for reference to the user defining the associations that give rise to the event or other actions that occur that may trigger the event; Figure 46 and related text regarding item 636 ‘associations’] receiving, by the event analytics server on at least one processor, a user triggered event input wherein the user triggered event input is defined by the event category hierarchy and type, and one or more values associated with the event [see at least Paragraph 0143 for reference to the event extraction system receiving entity information including entity values and entity types extracted by the entity extraction system to assist in the event classification wherein an event classification model receives entity information along with features to classify events; Paragraph 0369 for reference to a user request for a custom object creation including custom object information is received; Paragraph 0420 for reference to a user may define a custom object (or multiple custom objects) and may define the events that occur with respect to the custom object and other objects (custom objects, core objects, and/or standard objects) that may be related to the client's business via the customization system; Figure 20 and related text regarding item 2010 ‘Receive Request To Create New Client-Specific Service System’ and item 2012 ‘Receive One Or More Customization Parameters’; Figure 50 and related text regarding item 1002 ‘Receive user request for a custom object creation including custom object information’] receiving, by the event analytics server, one or more context metadata value [see at least Paragraph 0328 for reference to the customization system executing a business logic/sensible default service (e.g., may use business logic and/or sensible defaults) to interpret custom object information in order to convert the custom object information into custom object metadata; Figure 50 and related text regarding item 1004 ‘Interpret and convert custom object information into custom object metadata’] associating the one or more context metadata value with the user triggered event input to define an initial user triggered event input [see at least Paragraph 0369 for reference to custom object information may be interpreted and converted into custom object metadata and custom object metadata may be converted into language-independent data creating a custom object; Figure 50 and related text regarding item 1008 ‘Convert custom object metadata into a language independent data creating a custom object’] providing the initial user triggered event input to a listener module [see at least Paragraph 0419 for reference to the customization system may further configure a custom listening thread that listens for a new event type, for example, from an event source identified by the configuring user; Paragraph 0420 for reference to the event system may instantiate and execute listening threads that may listen to various services of the multi-service business platform (e.g., payment services, ticketing services, CRM services, CMS services, machine-learning services, geolocation services, identity resolution services, telemetry services, and/or the like) and/or external event sources for particular types of data and may update the event data store(s) and/or the knowledge graph based on the data obtained from the various services; Figure 50 and related text regarding item 1006 ‘Insert and store custom object metadata in a relational-type database’] identifying, based on evaluating the event category hierarchy and type, the first associated ESOD and the first associated TOD for the user triggered event input [see at least Paragraph 0419 for reference to the customization system may update the ontology (e.g., ontology datastore) to reflect the new type of event and/or may update schemas of one or more object event records to reflect the new event type that is being tracked with respect to one or more respective object types; Paragraph 0420 for reference to event instances corresponding to the custom object may be detected and recorded when data is received from a specific source] providing the first final shape [see at least Paragraph 00322 for reference to the multi-service business platform may communicate with user device(s) (e.g., user may be using the customization system from the user device to create custom objects via network), client device(s) (e.g., tracking various activities of the client device of a customer for purposes of sales and marketing with respect to custom objects), and various external information sources; Figure 50 and related text regarding item 1010 ‘Send custom object in language independent data form to a user device and/or services of an integrated business platform for use with at least one of a marketing process, a sales process, and a customer service process’] While Ash discloses the limitations above, it does not disclose transforming the values associated with the user triggered event input into a first provisional final shape (1 PFS); generating a validation shape (VS) using the associated ESOD to define a required shape structure and required value types; validating the first provisional final shape (1 PFS) against the VS, wherein validating the first provisional final shape (1PFS) against the VS comprises matching a data structure and value types; and upon validating the first provisional final shape, identifying the first provisional final shape as a first final shape (1 FFS) and providing the first final shape. However, Pinto discloses the following: transforming the values associated with the user triggered event input into a first provisional final shape (1 PFS) [see at least Paragraph 0044 for reference to analysis informs the appropriate variable transformation to maximize predictive power to Supplement the automatic transformation of variables to that purpose preceding or following dimension reduction; Paragraph 0052 for reference to a model method being selected and fitted to convergence with the sample dataset; Paragraph 0098 for reference to fit or train the model to the sample subset of the historical data using the predictive variables generated by a set of variable transformation to maximum univariate predictive capability and a set of dimension reduction filters to retain only the most predictive subgroup of variables, including up to level of interaction; Figure 4 and related text regarding item 72 ‘Dimension Reduction’, item 74 ‘Model Generation’, and item 82 ‘Variable Transformation’] generating a validation shape (VS) using the associated ESOD to define a required shape structure and required value types [see at least Paragraph 0042 for reference to the model development platform including candidate model generation; Paragraph 0108 for reference to the model generation platform automates a modeling process that leads to a candidate model for assessment; Figure 1 and related text regarding item 20 ‘Validate Model Process’; Figure 4 and related text regarding item 74 ‘candidate model generation’; Figure 12 and related text regarding item 210 ‘Select Validation Datasets’] validating the first provisional final shape (1 PFS) against the VS, wherein validating the first provisional final shape (1PFS) against the VS comprises matching a data structure and value types [see at least Paragraph 0103 for reference to after a candidate model has been determined in the model development procedure, the model is applied to the holdout or validation subset for comparison; Paragraph 0103 for reference to selected measures, for example, the similarity of the c-statistics (obtained from the ROC curves) and the cumulative and non-cumulative gain functions provide the basis for candidate model validation; Paragraph 0103 for reference to the validation set being fitted independently and the common variables compared; Paragraph 0195 for reference to Validating the model generation process involves a comparison of the proposed model candidate features to the initial entry information on the development dataset and the targeted values of the key features together with a validation of the candidate using the hold-out validation dataset; Paragraph 0210 for reference to the activation of a compare file variable statistics displaying a side-by-side comparison of model variables; Figure 1 and related text regarding item 20 ‘Validate Model Process’ and item 22 ‘Evaluate Model’; Figure 4 and related text regarding item 76 ‘Model Process Validation’; Figure 12 and related text regarding item 214 ‘Evaluate Performance Generalization’; Figure 25A and related text regarding an exemplary graphical user representation of a gains chart and some statistical results comparison of a predictive model developed from a sample dataset and an application of the same model to a validation dataset] upon validating the first provisional final shape, identifying the first provisional final shape as a first final shape (1 FFS) and providing the first final shape [see at least Paragraph 0036 for reference to deployment of model including delivering the model to a client for use with current and future data that is similar to the originally analyzed data referenced in the database; Paragraph 0052 for reference to the validated model generated processes a final model; Paragraph 0150 for reference to after completing the selections for the candidate model properties and model constraints which serve as descriptive guides or embedded filters parameters for selecting a final model; Figure 4 and related text regarding item 78 ‘Final Model Selection’; Figure 5 and related text regarding item 110 ‘Final Model Selection’] Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the events modeling method of Ash to include the model shape validation and output ability of Pinto. By enforcing a carefully managed project paradigm, models can be generated, updated, changed, reviewed, and deployed in a high-volume production process, at lower cost, and with better results, as stated by Pinto (Paragraph 0035). Claim 16 While the combination of Ash and Pinto disclose the limitations above, regarding Claim 16, Ash discloses the following: The system of claim 15 further comprising a user device comprising a hardware processor and an interface to provide the user triggered event input, and one or more sensor to perform measurements for capturing one or more user gestures, wherein the user triggered event input is associated with the one or more user gestures [see at least [see at least Paragraph 0143 for reference to the event extraction system receiving entity information including entity values and entity types extracted by the entity extraction system to assist in the event classification wherein an event classification model receives entity information along with features to classify events; Paragraph 0369 for reference to a user request for a custom object creation including custom object information is received; Paragraph 0420 for reference to a user may define a custom object (or multiple custom objects) and may define the events that occur with respect to the custom object and other objects (custom objects, core objects, and/or standard objects) that may be related to the client's business via the customization system; Paragraph 0600 for reference to hardware may integrate and/or receive signals from sensors wherein the sensors allow observation and measurement of conditions; Figure 20 and related text regarding item 2010 ‘Receive Request To Create New Client-Specific Service System’ and item 2012 ‘Receive One Or More Customization Parameters’; Figure 50 and related text regarding item 1002 ‘Receive user request for a custom object creation including custom object information’] Claim 17 While the combination of Ash and Pinto disclose the limitations above, regarding Claim 17, Ash discloses the following: wherein the event analytics server receives one or more user defined shape element, generates one or more EMOD associated with the one or more user defined shape element, and updates one or more ESOD associated with the one or more user defined shape element, wherein the one or more event model object definition (EMOD) defines a nested, hierarchical, or recursive data element relationship within the system [see at least Paragraph 0310 for reference to custom objects definition may include an object type, properties (e.g., some properties may be set on an instance), and possible associations; Paragraph 0346 for reference to a user may decide to define associations in terms of hierarchy by defining names of associations (e.g., user may name one association as “Parent” between two objects and/or may name another association as “child” between the same two objects but in the opposite direction) based on their business model; Paragraph 0348 for reference to a core object having a name, a type, and properties; Paragraph 0363 for reference to creating or updating properties for the custom objects; Paragraph 0420 for reference to a user may define a custom object (or multiple custom objects) and may define the events that occur with respect to the custom object and other objects (custom objects, core objects, and/or standard objects) that may be related to the client's business via the customization system] Claim 18 While the combination of Ash and Pinto disclose the limitations above, Ash does not disclose wherein the event analytics server determines that one or more secondary transformations is required for the user triggered event input, and generates a second final shape by applying transformation logic to the first final shape, wherein the event analytics server associates the initial user triggered event input with the secondary analytics server type and secondary set of event logic comprising another event model, and transforms the initial user triggered event input to match a set of protocols for the secondary analytics server, and transforms the initial user triggered event input to match a set of protocols for the secondary analytics server, and sends the transformed initial user triggered event input to the secondary analytics server. Regarding Claim 18, Pinto discloses the following: wherein the event analytics server determines that one or more secondary transformations is required for the user triggered event input [see at least Paragraph 0044 for reference to analysis informs the appropriate variable transformation to maximize predictive power to Supplement the automatic transformation of variables to that purpose preceding or following dimension reduction; Paragraph 0052 for reference to a model method being selected and fitted to convergence with the sample dataset; Paragraph 0098 for reference to fit or train the model to the sample subset of the historical data using the predictive variables generated by a set of variable transformation to maximum univariate predictive capability and a set of dimension reduction filters to retain only the most predictive subgroup of variables, including up to level of interaction; Figure 4 and related text regarding item 72 ‘Dimension Reduction’, item 74 ‘Model Generation’, and item 82 ‘Variable Transformation’] generates a second final shape by applying transformation logic to the first final shape [see at least Paragraph 0205 for reference to the model development process the full development dataset is subjected to the same process, resulting in a final candidate model and that model is applied to the sample dataset and to the validation dataset with the final candidate model equation and the results displayed in a report; Paragraph 0223-0224 for reference to the revision of completed models wherein the final model is rejected and re-analyzed] wherein the event analytics server associates the initial user triggered event input with the secondary analytics server type and secondary set of event logic comprising another event model [see at least Paragraph 0037 for reference to input devices enabling a user to interact with the model platform to generate a model by a series of steps; Paragraph 0039 for reference to the model generation platform being based on a project paradigm wherein the model development platform automatically stores structured project information that captures a state of the project at successive steps in generating the model] transforms the initial user triggered event input to match a set of protocols for the secondary analytics server, and sends the transformed initial user triggered event input to the secondary analytics server [see at least Paragraph 0037 for reference to input devices enabling a user to interact with the model platform to generate a model by a series of steps; Paragraph 0038 for reference to the system being implemented in a client-server mod using a server on a network wherein access to the features of the model generation platform software being permitted using an application service provider (ASP) model of distribution such as a web service over the internet] Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the events modeling method of Ash to include the distribution method of Pinto. By enforcing a carefully managed project paradigm, models can be generated, updated, changed, reviewed, and deployed in a high-volume production process, at lower cost, and with better results, as stated by Pinto (Paragraph 0035). Claim 19 While the combination of Ash and Pinto disclose the limitations above, Ash does not disclose version validation wherein a hierarchical version identifier associated with the event analytics server, the ESOD and the one or more EMOD associated with the ESOD share one or more hierarchical elements within the version identifier. Regarding Claim 19, Pinto discloses the following: wherein the processor is further configured to version validation using a hierarchical version identifier associated with the event analytics server, the ESOD and the one or more EMOD associated with the ESOD share one or more hierarchical elements within the version identifier [see at least Paragraph 0103 for reference to If the model generation process fails validation then the process is revised using model persistence analysis; Paragraph 0103 for reference to after a candidate model has been determined in the model development procedure, the model is applied to the holdout or validation subset for comparison; Paragraph 0103 for reference to selected measures, for example, the similarity of the c-statistics (obtained from the ROC curves) and the cumulative and non-cumulative gain functions provide the basis for candidate model validation; Paragraph 0195 for reference to Validating the model generation process involves a comparison of the proposed model candidate features to the initial entry information on the development dataset and the targeted values of the key features together with a validation of the candidate using the hold-out validation dataset; Figure 1 and related text regarding item 20 ‘Validate Model Process’ and item 22 ‘Evaluate Model’; Figure 4 and related text regarding item 76 ‘Model Process Validation’; Figure 12 and related text regarding the model process validation] Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the events modeling method of Ash to include the versioning validation method of Pinto. By enforcing a carefully managed project paradigm, models can be generated, updated, changed, reviewed, and deployed in a high-volume production process, at lower cost, and with better results, as stated by Pinto (Paragraph 0035). Claim 20 While the combination of Ash and Pinto disclose the limitations above, regarding Claim 20, Ash discloses the following: wherein the event analytics server receives a plurality of user triggered events and provides a plurality of first final shapes, wherein the plurality of user triggered events are triggered simultaneously [see at least Paragraph 0143 for reference to the event extraction system receiving entity information including entity values and entity types extracted by the entity extraction system to assist in the event classification wherein an event classification model receives entity information along with features to classify events; Paragraph 0369 for reference to a user request for a custom object creation including custom object information is received; Paragraph 0420 for reference to a user may define a custom object (or multiple custom objects) and may define the events that occur with respect to the custom object and other objects (custom objects, core objects, and/or standard objects) that may be related to the client's business via the customization system; Figure 20 and related text regarding item 2010 ‘Receive Request To Create New Client-Specific Service System’ and item 2012 ‘Receive One Or More Customization Parameters’; Figure 50 and related text regarding item 1002 ‘Receive user request for a custom object creation including custom object information’] wherein the plurality of user triggered events comprises user triggered event input associated with user engagement [see at least Paragraph 0367 for reference to the user went in and added a new property, the new property may show up in this list, and the user may trigger logic based on values of the “service” custom objects; Paragraph 0369 for reference to a user request for a custom object creation including custom object information is received; Paragraph 0420 for reference to a user may define a custom object (or multiple custom objects) and may define the events that occur with respect to the custom object and other objects (custom objects, core objects, and/or standard objects) that may be related to the client's business via the customization system; Figure 20 and related text regarding item 2010 ‘Receive Request To Create New Client-Specific Service System’ and item 2012 ‘Receive One Or More Customization Parameters’; Figure 50 and related text regarding item 1002 ‘Receive user request for a custom object creation including custom object information’] wherein the event analytics server associates one or more context metadata values with the other user triggered event input to define another initial user triggered event input [see at least Paragraph 0369 for reference to custom object information may be interpreted and converted into custom object metadata and custom object metadata may be converted into language-independent data creating a custom object; Figure 50 and related text regarding item 1008 ‘Convert custom object metadata into a language independent data creating a custom object’] Claim 21 While the combination of Ash and Pinto disclose the limitations above, regarding Claim 21, Ash discloses the following: The system of claim 15 wherein the processor is further configured to generate machine logic to implement one or more operations selected from the group of providing additional context metadata for the user triggered event input, monitoring validating of the first provisional final shape, determining common shape types, recommending changes to one or more EMOD, recommending changes to one or more ESOD, determining one or more errors requiring changes to one or more EMOD, determining one or more errors requiring changes to one or more ESOD, generating a new EMOD, and generating a new ESOD [see at least Paragraph 0316 for reference to the multi-service business platform may provide prompts for a user to define inputs into a machine learning model, e.g., the user may submit via prompts several properties (e.g., how often does student attend, how many classes is student signed up for, subscription plan, etc.) that may impact whether a student may be likely or unlikely to attend a class and the machine learning model may be used to perform calculations based on these inputs; Paragraph 0381 for reference to instances of custom objects may be used with machine learning system to train machine-learned models that may be used with the user (e.g., related to a user's business) for all objects (e.g., custom objects and core objects); Paragraph 0397 for reference to machine learning process may use the feedback to train the artificial intelligence system to produce the duplicate likelihood value that approximates the corresponding duplicate entity indication value (e.g., minimizes the error value)] Claim 22 Regarding Claim 22, Ash discloses the following: A non-transitory computer readable medium having stored thereon machine interpretable instructions executable by a processor to cause the processor to [see at least Paragraph 0012 for reference to a non-transitory computer readable storage medium having a plurality of instructions stored thereon which, when executed across one or more processors, causes at least a portion of the one or more processors to perform operations; Paragraph 0201 for reference to storage devices being any suitable type of computer readable mediums; Figure 14 and related text regarding item 320 ‘storage system’] receive a set of event logic comprising an event model defining more than one user triggered event [see at least Paragraph 0143 for reference to the event extraction system receiving entity information including entity values and entity types extracted by the entity extraction system to assist in the event classification wherein an event classification model receives entity information along with features to classify events; Paragraph 0147 for reference to knowledge graph may further include event nodes which represent events that are identified by the event extraction system; Paragraph 0151 for reference to event classification model may refer to a machine learned model that is configured to receive features that are extracted from one or more documents and that output one or more potential events that may be indicated by the documents; Figure 20 and related text regarding item 2010 ‘Receive Request To Create New Client-Specific Service System’ and item 2012 ‘Receive One Or More Customization Parameters’; Figure 50 and related text regarding item 1002 ‘Receive user request for a custom object creation including custom object information’] wherein the event model comprises a set of elements associated with the more than one user triggered event, wherein the set of elements provide [see at least Paragraph 0143 for reference to an event classification model receives entity information along with features to classify events; Paragraph 0151 for reference to event classification model may refer to a machine learned model that is configured to receive features that are extracted from one or more documents and that output one or more potential events that may be indicated by the documents; Paragraph 0329 for reference to ontology and the instance knowledge graph may include the custom object with other custom objects and/or core objects (e.g., contact objects, company objects, deal objects, and/or ticket objects) along with one or more associations (e.g., as added or selected associations by the user) between the objects] one or more event model object definition (EMOD) wherein the EMOD defines default values and/or a data element relationship within the system [see at least Paragraph 0076 for reference to the multi-service business platform having a preset or fixed core object; Paragraph 0348 for reference to a core object having a name, a type, and properties; Figure 46 and related text regarding item 634 ‘core objects’] one or more event standard object definition (ESOD) wherein the ESOD, defines a data model, shape, and event logic comprising an event category hierarchy and type associated with one or more user triggered event [see at least Paragraph 0309 for reference to custom objects being created to be specific to each user's (e.g., client's) business and the custom objects may be used on the multi-service business platform; Paragraph 0310 for reference to custom objects definition may include an object type, properties (e.g., some properties may be set on an instance), and possible associations; Paragraph 0346 for reference to a user may decide to define associations in terms of hierarchy by defining names of associations (e.g., user may name one association as “Parent” between two objects and/or may name another association as “child” between the same two objects but in the opposite direction) based on their business model; Paragraph 0419 for reference to the user may select a custom object and may define the types of events that may occur with respect to the custom object, such that the custom object may be the primary object of the new event record; Figure 46 and related text regarding item 632 ‘custom objects’] one or more transformation objects definition (TOD) wherein the TOD, defines a model and transformation logic for determining a final shape using the ESOD and one or more EMOD [see at least Paragraph 0306 for reference to two objects may be associated using one or more different types of associations and the associations may be directed in both directions (e.g., association and inverse association); Paragraph 0316 for reference to instances of associations between the object instances (e.g., between custom object instances and/or core object instances) may be used to determine these properties; Figure 46 and related text regarding item 636 ‘associations’] wherein the ESOD comprises one or more EMOD [see at least Paragraph 0361 for reference to custom objects existing with core objects in the multi-system business platform; Paragraph 0361 for reference to custom objects may be linked and/or associated to the core objects or other custom objects; Paragraph 0419 for reference to each event may occur with respect to one or more object types that may be associated with each respective event] wherein the TOD follows the shape of the ESOD and comprises one or more transformation paths, wherein the transformation path specifies a location associated with a value in the event standard object definition (ESOD) associated with a EMOD [see at least Paragraph 0315 for reference to the example of associations between objects determining the location properties of the corresponding objects; Paragraph 0316 for reference to instances of associations between the object instances (e.g., between custom object instances and/or core object instances) may be used to determine these properties; Paragraph 0419 for reference to the user defining the associations that give rise to the event or other actions that occur that may trigger the event; Figure 46 and related text regarding item 636 ‘associations’] receiving, by the event analytics server on at least one processor, a user triggered event input wherein the user triggered event input is defined by the event category hierarchy and type, and one or more values associated with the event [see at least Paragraph 0143 for reference to the event extraction system receiving entity information including entity values and entity types extracted by the entity extraction system to assist in the event classification wherein an event classification model receives entity information along with features to classify events; Paragraph 0369 for reference to a user request for a custom object creation including custom object information is received; Paragraph 0420 for reference to a user may define a custom object (or multiple custom objects) and may define the events that occur with respect to the custom object and other objects (custom objects, core objects, and/or standard objects) that may be related to the client's business via the customization system; Figure 20 and related text regarding item 2010 ‘Receive Request To Create New Client-Specific Service System’ and item 2012 ‘Receive One Or More Customization Parameters’; Figure 50 and related text regarding item 1002 ‘Receive user request for a custom object creation including custom object information’] receiving, by the event analytics server, one or more context metadata value [see at least Paragraph 0328 for reference to the customization system executing a business logic/sensible default service (e.g., may use business logic and/or sensible defaults) to interpret custom object information in order to convert the custom object information into custom object metadata; Figure 50 and related text regarding item 1004 ‘Interpret and convert custom object information into custom object metadata’] associating the one or more context metadata value with the user triggered event input to define an initial user triggered event input [see at least Paragraph 0369 for reference to custom object information may be interpreted and converted into custom object metadata and custom object metadata may be converted into language-independent data creating a custom object; Figure 50 and related text regarding item 1008 ‘Convert custom object metadata into a language independent data creating a custom object’] providing the initial user triggered event input to a listener module [see at least Paragraph 0419 for reference to the customization system may further configure a custom listening thread that listens for a new event type, for example, from an event source identified by the configuring user; Paragraph 0420 for reference to the event system may instantiate and execute listening threads that may listen to various services of the multi-service business platform (e.g., payment services, ticketing services, CRM services, CMS services, machine-learning services, geolocation services, identity resolution services, telemetry services, and/or the like) and/or external event sources for particular types of data and may update the event data store(s) and/or the knowledge graph based on the data obtained from the various services; Figure 50 and related text regarding item 1006 ‘Insert and store custom object metadata in a relational-type database’] identifying, based on evaluating the event category hierarchy and type, the first associated ESOD and the first associated TOD for the user triggered event input [see at least Paragraph 0419 for reference to the customization system may update the ontology (e.g., ontology datastore) to reflect the new type of event and/or may update schemas of one or more object event records to reflect the new event type that is being tracked with respect to one or more respective object types; Paragraph 0420 for reference to event instances corresponding to the custom object may be detected and recorded when data is received from a specific source] providing the first final shape [see at least Paragraph 00322 for reference to the multi-service business platform may communicate with user device(s) (e.g., user may be using the customization system from the user device to create custom objects via network), client device(s) (e.g., tracking various activities of the client device of a customer for purposes of sales and marketing with respect to custom objects), and various external information sources; Figure 50 and related text regarding item 1010 ‘Send custom object in language independent data form to a user device and/or services of an integrated business platform for use with at least one of a marketing process, a sales process, and a customer service process’] While Ash discloses the limitations above, it does not disclose transforming the values associated with the user triggered event input into a first provisional final shape (1 PFS); generating a validation shape (VS) using the associated ESOD to define a required shape structure and required value types; validating the first provisional final shape (1 PFS) against the VS, wherein validating the first provisional final shape (1PFS) against the VS comprises matching a data structure and value types; and upon validating the first provisional final shape, identifying the first provisional final shape as a first final shape (1 FFS) and providing the first final shape. However, Pinto discloses the following: transforming the values associated with the user triggered event input into a first provisional final shape (1 PFS) [see at least Paragraph 0044 for reference to analysis informs the appropriate variable transformation to maximize predictive power to Supplement the automatic transformation of variables to that purpose preceding or following dimension reduction; Paragraph 0052 for reference to a model method being selected and fitted to convergence with the sample dataset; Paragraph 0098 for reference to fit or train the model to the sample subset of the historical data using the predictive variables generated by a set of variable transformation to maximum univariate predictive capability and a set of dimension reduction filters to retain only the most predictive subgroup of variables, including up to level of interaction; Figure 4 and related text regarding item 72 ‘Dimension Reduction’, item 74 ‘Model Generation’, and item 82 ‘Variable Transformation’] generating a validation shape (VS) using the associated ESOD to define a required shape structure and required value types [see at least Paragraph 0042 for reference to the model development platform including candidate model generation; Paragraph 0108 for reference to the model generation platform automates a modeling process that leads to a candidate model for assessment; Figure 1 and related text regarding item 20 ‘Validate Model Process’; Figure 4 and related text regarding item 74 ‘candidate model generation’; Figure 12 and related text regarding item 210 ‘Select Validation Datasets’] validating the first provisional final shape (1 PFS) against the VS, wherein validating the first provisional final shape (1PFS) against the VS comprises matching a data structure and value types [see at least Paragraph 0103 for reference to after a candidate model has been determined in the model development procedure, the model is applied to the holdout or validation subset for comparison; Paragraph 0103 for reference to selected measures, for example, the similarity of the c-statistics (obtained from the ROC curves) and the cumulative and non-cumulative gain functions provide the basis for candidate model validation; Paragraph 0103 for reference to the validation set being fitted independently and the common variables compared; Paragraph 0195 for reference to Validating the model generation process involves a comparison of the proposed model candidate features to the initial entry information on the development dataset and the targeted values of the key features together with a validation of the candidate using the hold-out validation dataset; Paragraph 0210 for reference to the activation of a compare file variable statistics displaying a side-by-side comparison of model variables; Figure 1 and related text regarding item 20 ‘Validate Model Process’ and item 22 ‘Evaluate Model’; Figure 4 and related text regarding item 76 ‘Model Process Validation’; Figure 12 and related text regarding item 214 ‘Evaluate Performance Generalization’; Figure 25A and related text regarding an exemplary graphical user representation of a gains chart and some statistical results comparison of a predictive model developed from a sample dataset and an application of the same model to a validation dataset] upon validating the first provisional final shape, identifying the first provisional final shape as a first final shape (1 FFS) and providing the first final shape [see at least Paragraph 0036 for reference to deployment of model including delivering the model to a client for use with current and future data that is similar to the originally analyzed data referenced in the database; Paragraph 0052 for reference to the validated model generated processes a final model; Paragraph 0150 for reference to after completing the selections for the candidate model properties and model constraints which serve as descriptive guides or embedded filters parameters for selecting a final model; Figure 4 and related text regarding item 78 ‘Final Model Selection’; Figure 5 and related text regarding item 110 ‘Final Model Selection’] Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the events modeling method of Ash to include the model shape validation and output ability of Pinto. By enforcing a carefully managed project paradigm, models can be generated, updated, changed, reviewed, and deployed in a high-volume production process, at lower cost, and with better results, as stated by Pinto (Paragraph 0035). Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. DOCUMENT ID INVENTOR(S) TITLE US 8,214,308 B2 Chu, Chengwen Robert Computer-Implemented Systems And Methods For Updating Predictive Models US 2022/0398605 A1 Chen et al. TRAINING A MODEL TO PREDICT LIKELIHOODS OF USERS PERFORMING AN ACTION AFTER BEING PRESENTED WITH A CONTENT ITEM THIS ACTION IS MADE FINAL. 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 KRISTIN ELIZABETH GAVIN whose telephone number is (571)270-7019. The examiner can normally be reached M-F 7:30-4:30 PM EST. 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, Jerry O'Connor can be reached at 571-272-6787. 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. /KRISTIN E GAVIN/Primary Examiner, Art Unit 3624
Read full office action

Prosecution Timeline

Dec 05, 2023
Application Filed
Oct 31, 2025
Non-Final Rejection — §101, §103
Feb 04, 2026
Response Filed
Feb 20, 2026
Final Rejection — §101, §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12591899
CASINO PATRON ENGAGEMENT SYSTEM
2y 5m to grant Granted Mar 31, 2026
Patent 12586089
METHOD AND SYSTEM FOR PROCESSING EXPERIENCE DIGITAL CONTENTS
2y 5m to grant Granted Mar 24, 2026
Patent 12555138
SYSTEMS AND METHODS FOR TRACKED ELECTRONIC COMMUNICATIONS APPORTIONMENT
2y 5m to grant Granted Feb 17, 2026
Patent 12443911
APPARATUS AND METHODS FOR DETERMINING DELIVERY ROUTES AND TIMES BASED ON GENERATED MACHINE LEARNING MODELS
2y 5m to grant Granted Oct 14, 2025
Patent 12443966
DISTRIBUTED TRACING TECHNIQUES FOR ACQUIRING BUSINESS INSIGHTS
2y 5m to grant Granted Oct 14, 2025
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

3-4
Expected OA Rounds
14%
Grant Probability
29%
With Interview (+15.2%)
3y 8m
Median Time to Grant
Moderate
PTA Risk
Based on 154 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month