DETAILED ACTION
This final Office action is responsive to amendments filed July 6th, 2026. Claims 1, 8, 14-15, and 20 have been amended. Claims 1-20 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 .
Priority
Applicant’s claim for the benefit of a prior-filed application under 35 U.S.C. 119(e) or under 35 U.S.C. 120, 121, 365(c), or 386(c) is acknowledged.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 04/06/26 and 07/06/26 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Response to Arguments
Applicant's arguments regarding claim rejections under 35 USC 101 filed 07/06/26 have been fully considered but they are not persuasive.
On pages 8-12 of the provided remarks, Applicant argues that the amended claims are directed to statutory and patent-eligible technological implementations for real-time data aggregation, normalization, analytics, and API-based synchronization in a multi-tiered software subscription ecosystem. Following detailing the filed amendments to the independent claims, Applicant argues on pages 10-11 of the provided remarks, “the amended claims do not merely recite collecting information, analyzing information, and displaying results. Rather, the claims recite a particular computerized architecture that aggregates and normalizes data from heterogeneous enterprise systems, maintains standardized and synchronized subscription records, uses the standardized records to generate subscription configuration and pricing outputs, and automatically implements configured subscription offers by API-based updates to quote, order, billing, and subscription records across vendor, distributor, and reseller systems. These limitations are integral to the claimed computerized process and system, not insignificant extra-solution activity.” Examiner respectfully disagrees and asserts that the amended limitations high-level recitation of “aggregates and standardizes the subscription data from a plurality of sources” is a commercial interaction in the form of marketing/sales activity utilizing the subscription data of customers as well as a mental evaluation. Further, the amended “the one or more APIs are automatically orchestrated to exchange data” 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. Applicant’s arguments are not persuasive.
Applicant argues on page 11 of the provided remarks, regarding Step 2A Prong 2 analysis, “the claims integrate any alleged abstract idea into a practical application. The claimed RTDM, AAML Module, Subscription Management Module, SPoG UI, and Subscription APIs cooperate to address the data fragmentation, inconsistent formatting, and synchronization problems that arise in multi-tiered software subscription systems. The claimed solution is rooted in computer data processing and distributed system integration.” Examiner respectfully disagrees and asserts that while Specification paragraphs [0002-0006] detail the argued “inefficiencies, delays, and inaccuracies” of current supply-chain platforms per MPEP 2106.05(a) “If it is asserted that the invention improves upon conventional functioning of a computer, or upon conventional technology or technological processes, a technical explanation as to how to implement the invention should be present in the specification. That is, the disclosure must provide sufficient details such that one of ordinary skill in the art would recognize the claimed invention as providing an improvement. The specification need not explicitly set forth the improvement, but it must describe the invention such that the improvement would be apparent to one of ordinary skill in the art. Conversely, if the specification explicitly sets forth an improvement but in a conclusory manner (i.e., a bare assertion of an improvement without the detail necessary to be apparent to a person of ordinary skill in the art), the examiner should not determine the claim improves technology. An indication that the claimed invention provides an improvement can include a discussion in the specification that identifies a technical problem and explains the details of an unconventional technical solution expressed in the claim, or identifies technical improvements realized by the claim over the prior art.” Examiner begins by asserting that the argued “inefficiencies, delays, and inaccuracies” of the current supply chain platforms are not technical problems. Further, "claiming the improved speed or efficiency inherent with applying the abstract idea on a computer" does not integrate a judicial exception into a practical application or provide an inventive concept. Intellectual Ventures I LLC v. Capital One Bank (USA), 792 F.3d 1363, 1367, 115 USPQ2d 1636, 1639 (Fed. Cir. 2015). Examiner asserts that the argued “RTDM, AAML Module, Subscription Management Module, SPoG UI, and Subscription APIs” 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). Applicant’s arguments are not persuasive.
Continuing on page 11 of the provided remarks, Applicant argues “The claims recite how the subscription data is aggregated and standardized, how analytics are performed on the standardized records, and how the resulting subscription offers and pricing terms are implemented through APIs across external vendor, distributor, and reseller systems. The claim as a whole therefore applies any alleged commercial concept using a specific technological mechanism for real-time synchronization and implementation across distributed systems.” Examiner respectfully disagrees and asserts, as stated above, the amended “aggregates and standardizes the subscription data” does not recite “how the subscription data is aggregated and standardized” as argued by Applicant other than merely reciting “the RTDM” which is analogous 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). Further, the claimed “analyzing, by an Advanced Analytics and Machine Learning (AAML) module, subscription data” does not recite “how analytics are performed on the standardized records” other than merely reciting “by an Advanced Analytics and Machine Learning (AAML) module” which is analogous 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). Finally, the amended “wherein the one or more APIs are automatically orchestrated to exchange data” does not disclose “how the resulting subscription offers and pricing terms are implemented through APIs across external vendor, distributor, and reseller systems” as the claimed “automatically orchestrated” 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. Applicant’s arguments are not persuasive.
Continuing on pages 11-12 of the provided remarks, Applicant argues “The amended claims do not rely on a generic computer merely to automate a manual subscription process. The claims recite a specific arrangement of components and operations in which the RTDM standardizes data from defined enterprise source systems, the AAML module performs defined analytical operations on the standardized records, the Subscription Management Module configures subscription offers based on those outputs, and the APIs update quote, order, billing, and subscription records across the multi-tiered ecosystem.” Examiner respectfully disagrees and asserts the argued “RTDM, AAML module, Subscription Management Module, and APIs” 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). Applicant’s arguments are not persuasive.
Finally, regarding Step 2B analysis, Applicant argues “The claims do not simply append "Al" or "machine learning" to a business concept. The amended claims require the use of the RTDM, AAML module, Subscription Management Module, SPoG UI, and Subscription APIs in a defined data-processing pipeline that maintains synchronized subscription records and implements configured offers across external systems. The combination provides an inventive concept in the non-conventional arrangement and interaction of the claimed components to perform real-time data standardization, analytics- driven configuration, and API-based implementation across vendor, distributor, and reseller systems.” Examiner respectfully disagrees and asserts that the argued pipeline 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 0049 and 0078 and Figures 1-5, 7, and 11. 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. Therefore, the 35 USC 101 rejection is maintained. Applicant’s arguments are not persuasive.
Applicant’s arguments, see pages 12-17, filed 07/06/26, with respect to the rejection(s) of claim(s) 1-20 under 35 USC 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Parekh (U.S 2022/0210141 A1) in view of Sakamoto (U.S 2023/0275973 A1) in view of Nguyen (U.S 10,354,239 B1).
Applicant’s arguments, see pages 17-18, filed 07/06/26, with respect to claims 1, 8, 14-15, and 20 have been fully considered and are persuasive. The objections of 04/06/26 has been withdrawn.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter;
When considering subject matter eligibility under 35 U.S.C. 101, 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.
Claims 1-7
Step 1: Independent claim 1 (method) and dependent claims 2-7, 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).
Step 2A Prong 1: The independent claim recites managing multi-tiered software subscriptions via a Single Pane of Glass (SPoG) user interface (UI) in a multi-tiered software subscription ecosystem, the method comprising: initiating a user session through a Single Pane of Glass User Interface (SPoG UI) to manage subscriptions across entities including vendors, distributors, resellers, and customers; ingesting, by a Real-Time Data Mesh (RTDM), subscription data in real-time across these entities, wherein the RTDM aggregates and standardizes the subscription data from a plurality of data sources including enterprise resource planning systems, customer relationship management systems, and market intelligence data sources using extraction, transformation, and loading processes and data normalization techniques to maintain standardized subscription records; analyzing, by an Advanced Analytics and Machine Learning (AAML) module, the subscription data to optimize service offerings based on customer segmentation and market demand; generating dynamic pricing models considering factors such as market trends and subscription tier through the AAML module; automating a subscription lifecycle management utilizing the SPoG UI and RTDM; deploying one or more Application Program Interfaces (APIs) for data exchange and synchronization across the multi-tiered software subscription ecosystem, wherein the one or more APIs are automatically orchestrated to exchange data across vendor systems, distributor systems, and reseller systems to implement configured subscription offers; creating quotes, updating billing records, and processing orders automatically through the SPoG UI and the one or more APIs, leveraging real-time data from the RTDM; adjusting subscription terms dynamically to reflect market conditions and user consumption patterns, employing AI-driven insights; validating subscription configurations and terms for accuracy and compliance; implementing a feedback mechanism to refine subscription offerings and pricing strategies based on user interactions and market feedback (Certain Method of Organizing Human Activity & 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 Certain Methods of Organizing Human Activity because the claimed limitations are managing multi-tiered software subscriptions including: initiating a user session to manage subscriptions across entities including vendors, distributors, resellers, and customers; aggregating and standardizing subscription data; analyzing subscription data to optimize service offerings based on customer segmentation and market demand; generating dynamic pricing models considering factors such as market trends and subscription tier; creating quotes, updating billing records, and processing orders; adjusting subscription terms to reflect market conditions and user consumption patterns; and implementing a feedback mechanism to refine subscription offerings and pricing strategies based on user interactions and market feedback, which is commercial interactions in the form of marketing. The Applicant’s claimed limitations are managing multi-tiered software subscriptions, which recite the abstract idea of Organizing Human Activity.
The steps/functions disclosed above and in the independent claims recite the abstract idea of Mental Process because the claimed limitations are managing multi-tiered software subscriptions including: aggregating and standardizing subscription data; analyzing subscription data to optimize service offerings based on customer segmentation and market demand; generating dynamic pricing models considering factors such as market trends and subscription tier; creating quotes, updating billing records, and processing orders; adjusting subscription terms to reflect market conditions and user consumption patterns; validating subscription configurations and terms for accuracy and compliance; and implementing a feedback mechanism to refine subscription offerings and pricing strategies based on user interactions and market feedback, which are observations, judgments, and evaluations of the human mind. The Applicant’s claimed limitations are managing multi-tiered software subscriptions, which recite the abstract idea of Mental Process.
In addition, dependent claims 2-6 further narrow the abstract idea and recite further defining the management of co-terming subscriptions; anomaly detection and prevention in subscription usage and billing; forecasting subscription trends and adjusting offering preemptively; implementing tiered access control; and encryption protocols for data exchange between software vendors, distributors, and resellers. These processes are similar to the abstract idea noted in the independent claims because they further the limitations of the independent claims which recite a certain method of organizing human activity which include commercial interactions such as marketing as well as mental processes. Accordingly, these claim elements do not serve to confer subject matter eligibility to the claims since they recite abstract ideas. Dependent claim 7 will be discussed in Prong 2 analysis below.
Step 2A Prong 2: In this application, the above “ingesting, by a Real-Time Data Mesh (RTDM), subscription data in real-time across these entities; deploying one or more Application Program Interfaces (APIs) for data exchange and synchronization across the ecosystem the multi-tiered software subscription ecosystem, wherein the one or more APIs are automatically orchestrated to exchange data across vendor systems, distributor systems, and reseller systems to implement configured subscription offers” 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 computerized method; a Single Pane of Glass (SPoG) user interface (UI); Real-Time Data Mesh; an Advanced Analytics and Machine Learning (AAML) module; one or more Application Program Interfaces (APIs); a feedback mechanism; a tiered access control mechanism within the SPoG UI; a user engagement tracking module within the SPoG UI” 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).
Independent claim 1 recite the following limitation, “employing AI-driven insights”. The “employ AI-driven insights” are recited so generically (no details whatsoever are provided other than that they are general purpose computing components) 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. These limitations 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-6 further narrow the abstract idea and dependent claim 7 additionally recites “collect feedback and usage data, informing continuous improvement of the subscription offerings and user interface design” 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 “a user engagement tracking module within the SPoG UI” 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 computerized method; a Single Pane of Glass (SPoG) user interface (UI); Real-Time Data Mesh; an Advanced Analytics and Machine Learning (AAML) module; one or more Application Program Interfaces (APIs); a feedback mechanism; a tiered access control mechanism within the SPoG UI; a user engagement tracking module within the SPoG UI” 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-7; recite “A computerized method; a Single Pane of Glass (SPoG) user interface (UI); Real-Time Data Mesh; an Advanced Analytics and Machine Learning (AAML) module; one or more Application Program Interfaces (APIs); a feedback mechanism; a tiered access control mechanism within the SPoG UI; a user engagement tracking module within the SPoG UI”; 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 0049 and 0078 and Figures 1-5, 7, and 11. 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 “ingesting, by a Real-Time Data Mesh (RTDM), subscription data in real-time across these entities; deploying one or more Application Program Interfaces (APIs) for data exchange and synchronization across the ecosystem the multi-tiered software subscription ecosystem, wherein the one or more APIs are automatically orchestrated to exchange data across vendor systems, distributor systems, and reseller systems to implement configured subscription offers” 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.
Next, when the “AI/machine learning” is evaluated as an additional element, this feature is recited at a high level of generality and encompasses well-understood, routine, and conventional prior art activity. See, e.g., Balsiger et al., US 2012/0054642, noting in paragraph [0077] that “Machine learning is well known to those skilled in the art.” See also, Djordjevic et al. US 2013/0018651, noting in paragraph [0019] that “As known in the art, a generative model can be used in machine learning to model observed data directly.” See also, Bauer et al., US 2017/0147941, noting at paragraph [0002] that “Problems of understanding the behavior or decisions made by machine learning models have been recognized in the conventional art and various techniques have been developed to provide solutions.” Accordingly, the use of AI to generate a insights does not add significantly more to the claim.
In addition, claims 2-6 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, claim 7 additionally recite “collect feedback and usage data, informing continuous improvement of the subscription offerings and user interface design” 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 “a user engagement tracking module within the SPoG UI” 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.
Claims 8-14
Step 1: Independent claim 8 (system) dependent claims 9-14, 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 8 is directed to a system (i.e. machine).
Step 2A Prong 1: The independent claim recites managing multi-tiered software subscriptions in a multi-tiered software subscription ecosystem, comprising: a Single Pane of Glass User Interface (SPoG UI) configured to provide a unified management interface across multiple subscription tiers for vendors, distributors, resellers, and customers; a Real-Time Data Mesh (RTDM) designed for real-time ingestion and synchronization of subscription data across vendors, distributors, and resellers, wherein the RTDM is configured to aggregate and standardize the subscription data from enterprise resource planning systems, customer relationship management systems, and market intelligence data sources using extraction, transformation, and loading processes and data normalization techniques to maintain standardized subscription records; an Advanced Analytics and Machine Learning (AAML) Module tasked with analyzing subscription data to optimize service offerings, generate dynamic pricing models, and adjust subscription terms based on customer segmentation, market demand, and consumption patterns; a Subscription Management Module configured to configure subscription offers including tier-specific terms, conditions, and pricing based on outputs of the RTDM and the AAML Module; and one or more Application Programming Interfaces (APIs) enabling integration and data exchange across the multi-tiered software subscription ecosystem, wherein the one or more APIs are configured to automatically exchange data with vendor systems, distributor systems, and reseller systems to implement configured subscription offers including quote generation, order processing, and billing, wherein the system is configured to automate subscription lifecycle processes, including initiation, modification, renewal, and termination, leveraging data-driven insights to facilitate personalized and market-responsive subscription management (Certain Method of Organizing Human Activity & 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 Certain Methods of Organizing Human Activity because the claimed limitations are managing multi-tiered software subscriptions comprising: aggregating and standardizing the subscription data; analyzing subscription data to optimize service offerings, generate dynamic pricing models, and adjust subscription terms based on customer segmentation, market demand, and consumption patterns; configurate subscription offers including tier-specific terms, conditions, and pricing; subscription lifecycle processes, including initiation, modification, renewal, and termination, leveraging data-driven insights to facilitate personalized and market-responsive subscription management, which is commercial interaction in the form of marketing. The Applicant’s claimed limitations are managing multi-tiered software subscriptions, which recite the abstract idea of Organizing Human Activity.
The steps/functions disclosed above and in the independent claims recite the abstract idea of Mental Process because the claimed limitations are managing multi-tiered software subscriptions comprising: aggregating and standardizing the subscription data; analyzing subscription data to optimize service offerings, generate dynamic pricing models, and adjust subscription terms based on customer segmentation, market demand, and consumption patterns; configurate subscription offers including tier-specific terms, conditions, and pricing; subscription lifecycle processes, including initiation, modification, renewal, and termination, leveraging data-driven insights to facilitate personalized and market-responsive subscription management, which are observations, judgments, and evaluations of the human mind. The Applicant’s claimed limitations are managing multi-tiered software subscriptions, which recite the abstract idea of Mental Process.
In addition, dependent claims 9-13 further narrow the abstract idea and recite further defining management of co-terming subscriptions; anomaly detection and prevention in subscription usage and billing; forecasting subscription trends and adjusting offering preemptively; implementing tiered access control; and encryption protocols for data exchange between software vendors, distributors, and resellers. These processes are similar to the abstract idea noted in the independent claims because they further the limitations of the independent claims which recite a certain method of organizing human activity which include commercial interactions such as marketing as well as mental processes. Accordingly, these claim elements do not serve to confer subject matter eligibility to the claims since they recite abstract ideas. Dependent claim 14 will be discussed in Prong 2 analysis below.
Step 2A Prong 2: In this application, the above “provide a unified management interface across multiple subscription tiers; real-time ingestion and synchronization of subscription data across vendors, distributors, and resellers; enabling integration and data exchange across the multi-tiered software subscription ecosystem; wherein the one or more APIs are configured to automatically exchange data with vendor systems, distributor systems, and reseller systems to implement configured subscription offers including quote generation, order processing, and billing” 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 system for managing multi-tiered software subscriptions, comprising: a Single Pane of Glass User Interface (SPoG UI); a Real-Time Data Mesh (RTDM); an Advanced Analytics and Machine Learning (AAML) Module; one or more Application Programming Interfaces (APIs); a Subscription Management Module; a tiered access control mechanism within the SPoG UI; a user engagement tracking module within the SPoG UI” 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 9-13 further narrow the abstract idea and dependent claim 14 additionally recites “collect feedback and usage data to inform continuous improvement of the subscription offerings and user interface design” 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 “a user engagement tracking module within the SPoG UI” 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 system for managing multi-tiered software subscriptions, comprising: a Single Pane of Glass User Interface (SPoG UI); a Real-Time Data Mesh (RTDM); an Advanced Analytics and Machine Learning (AAML) Module; one or more Application Programming Interfaces (APIs); a Subscription Management Module; a tiered access control mechanism within the SPoG UI; a user engagement tracking module within the SPoG UI” 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, system claims 8-14 recite “A system for managing multi-tiered software subscriptions, comprising: a Single Pane of Glass User Interface (SPoG UI); a Real-Time Data Mesh (RTDM); an Advanced Analytics and Machine Learning (AAML) Module; one or more Application Programming Interfaces (APIs); a Subscription Management Module; a tiered access control mechanism within the SPoG UI; a user engagement tracking module within the SPoG UI”; 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 0049 and 0078 and Figures 1-5, 7, and 11. 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 “provide a unified management interface across multiple subscription tiers; real-time ingestion and synchronization of subscription data across vendors, distributors, and resellers; enabling integration and data exchange across the multi-tiered software subscription ecosystem; wherein the one or more APIs are configured to automatically exchange data with vendor systems, distributor systems, and reseller systems to implement configured subscription offers including quote generation, order processing, and billing” 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 9-13 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, claim 14 additionally recite “collect feedback and usage data to inform continuous improvement of the subscription offerings and user interface design” 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 “a user engagement tracking module within the SPoG UI” 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.
Claims 15-20
Step 1: Independent claim 15 (method) and dependent claims 16-20, 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 15 is directed to a method (i.e. process).
Step 2A Prong 1: The independent claim recites dynamically adjusting pricing and subscription terms within a software subscription management system including a Real- Time Data Mesh (RTDM), an Advanced Analytics and Machine Learning (AAML) module, a Single Pane of Glass User Interface (SPoG UI), and one or more Subscription APIs, the method comprising: collecting, by the Real-Time Data Mesh (RTDM), subscription data across multiple tiers from a distribution network, wherein the RTDM aggregates and standardizes the subscription data from multiple sources within the distribution network to maintain synchronized subscription records; analyzing, by the Advanced Analytics and Machine Learning (AAML) module, the collected data to identify opportunities for optimization of pricing and subscription terms based on market demand, customer segmentation, consumption patterns, and the requirements for co-terming alignments, wherein the AAML module applies time-series analysis and anomaly detection to identify trends and unexpected patterns in the subscription data and applies clustering to segment subscription usage patterns;; dynamically adjusting, by the AAML module a Subscription Management Module based on output of the AAML module, the subscription pricing and terms in response to the analysis, incorporating predictive analytics to anticipate future market trends and customer needs; communicating, via the Single Pane of Glass User Interface (SPoG UI) and the one or more Subscription APIs, the adjusted pricing and terms to all relevant stakeholders within the subscription ecosystem a multi-tiered software subscription ecosystem including vendors, distributors, resellers, and end-users, ensuring informed and timely updates; implementing the pricing and terms adjustments across the subscription management system, facilitated by the RTDM, to reflect changes in real-time billing and service delivery, wherein the one or more Subscription APIs update subscription offers, terms, conditions, quote records, order records, and billing records across the multi-tiered software subscription ecosystem; monitoring and refining, by the AAML module in conjunction with feedback collected through the SPoG UI, an effectiveness of the pricing and terms adjustments in an iterative feedback loop (Certain Method of Organizing Human Activity & 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 Certain Methods of Organizing Human Activity because the claimed limitations are dynamically adjusting pricing and subscription terms within a software subscription management system comprising: aggregating and standardizing the subscription data from multiple sources to maintain synchronization subscription records; analyzing the collected data to identify opportunities for optimization of pricing and subscription terms based on market demand, customer segmentation, consumption patterns, and the requirements for co-terming alignments; applying time-series analysis and anomaly detection to identify trends and unexpected patterns in the subscription data and applies clustering to segment subscription usage patterns; dynamically adjusting, the subscription pricing and terms in response to the analysis, incorporating predictive analytics to anticipate future market trends and customer needs; implementing the pricing and terms adjustments across the subscription management system, to reflect changes in real-time billing and service delivery; updating subscription offers, terms, conditions, quote records, order records, and billing records across the multi-tiered software subscription ecosystem; monitoring and refining, the effectiveness of the pricing and terms adjustments in an iterative feedback loop, which is commercial interactions in the form of sales activity. The Applicant’s claimed limitations are dynamically adjusting pricing and subscription terms within a software subscription management system, which recite the abstract idea of Organizing Human Activity.
The steps/functions disclosed above and in the independent claims recite the abstract idea of Mental Process because the claimed limitations are aggregating and standardizing the subscription data from multiple sources to maintain synchronization subscription records; analyzing the collected data to identify opportunities for optimization of pricing and subscription terms based on market demand, customer segmentation, consumption patterns, and the requirements for co-terming alignments; applying time-series analysis and anomaly detection to identify trends and unexpected patterns in the subscription data and applies clustering to segment subscription usage patterns; dynamically adjusting, the subscription pricing and terms in response to the analysis, incorporating predictive analytics to anticipate future market trends and customer needs; and monitoring and refining, the effectiveness of the pricing and terms adjustments in an iterative feedback loop, which are observations, judgments, and evaluations of the human mind. The Applicant’s claimed limitations are dynamically adjusting pricing and subscription terms within a software subscription management system, which recite the abstract idea of Mental Process.
In addition, dependent claims 16 and 18-20 further narrow the abstract idea and recite further defining customizing subscription terms to reflect user preferences and consumption patterns; integrating feedback from users and market analysis to refine predictive models related to pricing strategies and subscription terms; anomaly detection in subscription usage patterns; and suggest optimal subscription packages to resellers based on historical data and predictive modeling. These processes are similar to the abstract idea noted in the independent claims because they further the limitations of the independent claims which recite a certain method of organizing human activity which include commercial interactions such as marketing/sales activity as well as mental process. Accordingly, these claim elements do not serve to confer subject matter eligibility to the claims since they recite abstract ideas. Dependent claim 17 will be discussed in Prong 2 analysis below.
Step 2A Prong 2: In this application, the above “collecting, by the Real-Time Data Mesh (RTDM), subscription data across multiple tiers from a distribution network; communicating, via a Single Pane of Glass User Interface (SPoG UI) and the one or more Subscription APIs, the adjusted pricing and terms to all relevant stakeholders within the subscription ecosystem a multi-tiered software subscription ecosystem including vendors, distributors, resellers, and end-users, ensuring informed and timely updates” 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 computerized method; a software subscription management system including a Real- Time Data Mesh (RTDM), an Advanced Analytics and Machine Learning (AAML) module, a Single Pane of Glass User Interface (SPoG UI), and one or more Subscription APIs; a recommendation engine within the AAML Module” 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 16 and 18-20 further narrow the abstract idea and dependent claim 17 additionally recite “automatically communicating pricing adjustments to users” 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 SPoG UI” 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).
Dependent claim 19 recite the following limitation, “employing machine learning algorithms for real-time anomaly detection in subscription usage patterns”. The “employing machine learning algorithms” are recited so generically (no details whatsoever are provided other than that they are general purpose computing components) 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. These limitations 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).
The claimed “A computerized method; a software subscription management system including a Real- Time Data Mesh (RTDM), an Advanced Analytics and Machine Learning (AAML) module, a Single Pane of Glass User Interface (SPoG UI), and one or more Subscription APIs; a recommendation engine within the AAML Module” 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 15-20 recite “A computerized method; a software subscription management system including a Real- Time Data Mesh (RTDM), an Advanced Analytics and Machine Learning (AAML) module, a Single Pane of Glass User Interface (SPoG UI), and one or more Subscription APIs; a recommendation engine within the AAML Module”; 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 0049 and 0078 and Figures 1-5, 7, and 11. 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 “collecting, by the Real-Time Data Mesh (RTDM), subscription data across multiple tiers from a distribution network; communicating, via a Single Pane of Glass User Interface (SPoG UI) and the one or more Subscription APIs, the adjusted pricing and terms to all relevant stakeholders within the subscription ecosystem a multi-tiered software subscription ecosystem including vendors, distributors, resellers, and end-users, ensuring informed and timely updates” 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.
Next, when the “machine learning” is evaluated as an additional element, this feature is recited at a high level of generality and encompasses well-understood, routine, and conventional prior art activity. See, e.g., Balsiger et al., US 2012/0054642, noting in paragraph [0077] that “Machine learning is well known to those skilled in the art.” See also, Djordjevic et al. US 2013/0018651, noting in paragraph [0019] that “As known in the art, a generative model can be used in machine learning to model observed data directly.” See also, Bauer et al., US 2017/0147941, noting at paragraph [0002] that “Problems of understanding the behavior or decisions made by machine learning models have been recognized in the conventional art and various techniques have been developed to provide solutions.” Accordingly, the use of machine learning for real-time anomaly detection in subscription usage patterns does not add significantly more to the claim.
In addition, claims 16 and 18-20 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, claim 17 additionally recite “automatically communicating pricing adjustments to users” 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 SPoG UI” 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.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Parekh (U.S 2022/0210141 A1) in view of Sakamoto (U.S 2023/0275973 A1) in view of Nguyen (U.S 10,354,239 B1).
Claim 1
Regarding Claim 1, Parekh discloses the following:
A computerized method for managing multi-tiered software subscriptions via a Single Pane of Glass (SPoG) user interface (UI) in a multi-tiered software subscription ecosystem, the method comprising [see at least Paragraph 0003 for reference to techniques for access management for multi-cloud workloads; Paragraph 0005 for reference to illustrative embodiments including methods; Paragraph 0038 for reference to the trust platform implementing the trust platform GUI to provide users with a “single pane of glass” for managing cloud assets on any combination of the CSPs; Paragraph 0081 for reference to the trust platform offering services in different tiers; Figure 1 and related text regarding item 112 ‘GUI’; Figure 3 and related text regarding examples of different tiers of bundled managed services]
initiating a user session through a Single Pane of Glass User Interface (SPoG UI) to manage subscriptions across entities including vendors, distributors, resellers, and customers [see at least Paragraph 0038 for reference to the trust platform implementing the trust platform GUI to provide users with a “single pane of glass” for managing cloud assets on any combination of the CSPs; Paragraph 0076 for reference to functionality of the trust platform 102 may be offered in accordance with a subscription model that enables end - users to scale their cloud security operations on-demand as their cloud footprint grows; Paragraph 0134 for reference to access to the trust plat form 102 (e.g., the trust platform GUI 112 providing the single pane of glass for real - time or near real - time visibility; Figure 1 and related text regarding item 112 ‘GUI’]
analyzing, by an Advanced Analytics and Machine Learning (AAML) module, the subscription data to optimize service offerings based on customer segmentation and market demand [see at least Paragraph 0036 for reference to the trust platform being implemented on a processing device comprising and implementing functional modules for controlling certain features of the trust platform; Paragraph 0045 for reference to the ephemeral just - in - time access management module 122 of the trust platform 102 is configured to manage accounts for cloud assets (e.g. , used to run hybrid and multi - cloud workloads); Paragraph 0080 for reference to the trust platform, via the trust platform GUI providing interfaces for log management trend analysis and searching, monitoring, and analyzing “big data”]
automating a subscription lifecycle management utilizing the SPoG UI [see at least Paragraph 0038 trust platform GUI includes various interface features that facilitate automated management of the cloud assets through use of the trust platform APIs and the functionality of the modules; Paragraph 0038 for reference to the trust platform implementing the trust platform GUI to provide users with a “single pane of glass” for managing cloud assets on any combination of the CSPs; Paragraph 0134 for reference to access to the trust plat form 102 (e.g., the trust platform GUI 112 providing the single pane of glass for real - time or near real - time visibility; Figure 1 and related text regarding item 112 ‘GUI’]
deploying one or more Application Program Interfaces (APIs) for data exchange and synchronization across the multi-tiered software subscription ecosystem, wherein the one or more APIs are automatically orchestrated to exchange data [see at least Paragraph 0036 for reference to processing device generally comprises at least one processor and an associated memory, and implements one or more functional modules for controlling certain features of the trust platform 102, such as the trust platform GUI 112 and trust platform application programming interfaces (APIs) 114; Paragraph 0038 for reference to the trust platform 102 utilizes the trust platform APIs 114 to interact with the various CSPs 110 (e.g., to collect data from the various CSPs 110 which may be aggregated and formatted for view in a dashboard of the trust platform GUI 112, to deploy controls and manage accounts for cloud assets, etc.); Paragraph 0081 for reference to the trust platform offering services in different tiers; Paragraph 0086 for reference to the trust platform 102 may offer pre-selected bundles of managed security services (e.g., xStreamCare Services® for a Virtustream Trust Platform), possibly in conjunction with professional service hours to be delivered by cloud security experts of the trust platform; Figure 1 and related text regarding item 114 ‘APIs’]
validating subscription configurations and terms for accuracy and compliance [see at least Paragraph 0076 for reference to validated and preconfigured security bundles (e.g., for different CSPs 110) enable end - users to choose options based on their desired security posture without facing the complexity of dealing with multiple vendors, training existing staff, or selecting, procuring, architecting, deploying and maintaining a complex security ecosystem manually; Paragraph 0085 for reference to deployment being validated prior to go-live stage, which enables real-time or near real-time visibility]
While Parekh discloses the limitations above, it does not disclose ingesting, by a Real-Time Data Mesh (RTDM), subscription data in real-time across these entities, wherein the RTDM aggregates and standardizes the subscription data from a plurality of data sources including enterprise resource planning systems, customer relationship management systems, and market intelligence data sources using extraction, transformation, and loading processes and data normalization techniques to maintain standardized subscription records; generating dynamic pricing models considering factors such as market trends and subscription tier through the AAML module; deploying one or more Application Program Interfaces (APIs) for data exchange and synchronization across the multi-tiered software subscription ecosystem, wherein the one or more APIs are automatically orchestrated to exchange data across vendor systems, distributor systems, and reseller systems to implement configured subscription offers; creating quotes, updating billing records, and processing orders automatically through the SPoG UI and the one or more APIs, leveraging real-time data from the RTDM; adjusting subscription terms dynamically to reflect market conditions and user consumption patterns, employing AI-driven insights; and implementing a feedback mechanism to refine subscription offerings and pricing strategies based on user interactions and market feedback.
However, Sakamoto discloses the following:
ingesting, by a Real-Time Data Mesh (RTDM), subscription data in real-time across these entities, wherein the RTDM aggregates and standardizes the subscription data from a plurality of data sources including enterprise resource planning systems, customer relationship management systems, and market intelligence data sources using extraction, transformation, and loading processes and data normalization techniques to maintain standardized subscription records [see at least Paragraph 0055 for reference to the distributed Wi-Fi system 10 contemplates operation in any physical location where it is inefficient or impractical to service with a single access point, repeaters, or a mesh system; Paragraph 0062 for reference to it is possible for unified control via the cloud using standardized techniques for communication with the cloud; Paragraph 0076 for reference to Wi-Fi data can include aggregated network-wide statistics used to derive network-wide metrics, and the user can drill down to groups or individual accounts; Paragraph 0114 for reference to the cloud-based Wi-Fi monitoring system includes data ingestion of the inputs, and the processing can perform data aggregation, filtering, and pattern matching (aggregation/grouping of users); Paragraph 0116 for reference to network-related data can also include reporting of Wi-Fi related performance metrics via a standardized technique, such as OpenSync; Paragraph 0191 for reference to the system being configured to receive service-based metrics and subscription-based metrics from each subscriber network; Paragraph 0191 for reference to the subscriber churn prediction component being configured to obtain the service and subscription data in order to determine the likelihood of subscriber churn]
analyzing, by an Advanced Analytics and Machine Learning (AAML) module, the subscription data to optimize service offerings based on customer segmentation and market demand [see at least Paragraph 0065 for reference to components (202, 204, 206, 208, and 210) are communicatively coupled via a local interface; Paragraph 0195 for reference to which provides an ML model that can be used by the subscriber churn prediction component 812 to predict the likelihood of churn; Figure 8 and related text regarding item 812 ‘subscriber churn prediction component’]
generating dynamic pricing models considering factors such as market trends and subscription tier through the AAML module [see at least Paragraph 0206 for reference to each impact factor may be associated with one or more weights for defining how much the likelihood of subscriber churn is increased or decreased; Paragraph 0207 for reference to impact factors may also include service-based metrics and/or subscription-based metrics and may be obtained from one or more sources; Paragraph 0207 for reference to subscription-based metrics including i) payment information, j) number of payment activities, k) amounts of payments; Paragraph 0213 for reference to correlating the subscriber churn data with a variety of other datasets including, but not limited to, customer subscription, contract, billing, and/or payment data; Figure 8 and related text regarding item 812 ‘subscriber churn prediction component’]
automating a subscription lifecycle management utilizing the UI and RTDM [see at least Paragraph 0051 for reference to NOC dashboard is a user interface, e.g., web-based, application-based, etc. connected to multiple Wi-Fi networks via the cloud; Paragraph 0063 for reference to the single access point system 30, the Wi-Fi mesh network 32, and the Wi-Fi repeater network 33 can support cloud-based management; Paragraph 0150 for reference to customer outreach being automated wherein autonomous workflows are enabled that inform the end consumer about outages affecting the end consumer's user experience, scheduled maintenance of the ISP infrastructure, downtimes of the cloud based Wi-Fi network controllers, local Wi-Fi network topology and optimization issues, or any similar notifications to inform the end consumer about any local, regional, and global issues potentially affecting the end consumer's service]
creating quotes, updating billing records, and processing orders automatically through the UI and the one or more APIs, leveraging real-time data from the RTDM [see at least Paragraph 0054 for reference to dashboard can be used for customer support. If a customer calls, emails, texts, etc., a service representative can call up the customer's account live or off-line to help diagnose any problem; Paragraph 0192 for reference to the subscriber churn prediction component 812 may include Zuora tables 820 that include, for example, subscription, billing, and payment information; Paragraph 0207 for reference to the subscription-based metric including billing information; Paragraph 0214 for reference to the timeframe over which a subscriber may churn can also be predicted, and the predictions may be updated using the most recent data, with some frequency (e.g., hourly, daily, weekly, monthly, etc.), depending on various use cases; Paragraph 0255 for reference to the framework can perform timely processing of data to dynamically update the churn prediction for each subscriber based on their changes over time; Paragraph 0279 for reference to non-limiting campaigns can include, but are not limited to, proactive maintenance for identified users with degraded network performance, upsell campaigns for users with matched services, new package pricing for users in competitive locations, proactive outreach from call centers to address low NPS users, and the like]
adjusting subscription terms dynamically to reflect market conditions and user consumption patterns, employing AI-driven insights [see at least Paragraph 0281 for reference to the data can be automatically adjusted and/or updated for each user(s) so as to realize the determined churn prediction and/or provided campaign; Paragraph 0281 for reference to different subscriber segments can be suggested by AI/ML models and/or be specified by marketers for new campaign generation with measurable churn reduction results; Paragraph 0283 for reference to using the churn AI/ML model analysis discussed above respective to the steps of Process 3700, engine 3610 can identify and segment subscribers with predicted 20× and 10× more likely to churn cohorts compared to the base case churn rate; Paragraph 0283 for reference to Once accurate churn predictions and their associated risk factors are generated for each subscriber, associated campaigns may be generated and carried out by the CSP for churn prevention]
implementing a feedback mechanism to refine subscription offerings and pricing strategies based on user interactions and market feedback [see at least Paragraph 0119 for reference to Customer Satisfaction Score (CSAT) is a tool for measuring customer satisfaction at certain touchpoints, usually based on survey feedback; Paragraph 0158 for reference to cloud-based Wi-Fi monitoring system 600 can further utilize customer feedback; Paragraph 0206 for reference to impact factors including feedback information that is received from the subscriber (e.g., via a survey, service call, etc.)]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the trust platform user interface of Parekh to include the real time data mesh subscription data processing of Sakamoto. Doing so would provide a framework or architecture to enable service providers to improve customer experience, as stated by Sakamoto (Paragraph 0050).
While the combination of Parekh and Sakamoto disclose the limitations above, they do not disclose deploying one or more Application Program Interfaces (APIs) for data exchange and synchronization across the multi-tiered software subscription ecosystem, wherein the one or more APIs are automatically orchestrated to exchange data across vendor systems, distributor systems, and reseller systems to implement configured subscription offers; creating quotes, updating billing records, and processing orders automatically through the SPoG UI and the one or more APIs.
However, Nguyen discloses the following:
deploying one or more Application Program Interfaces (APIs) for data exchange and synchronization across the multi-tiered software subscription ecosystem, wherein the one or more APIs are automatically orchestrated to exchange data across vendor systems, distributor systems, and reseller systems to implement configured subscription offers [see at least Col 7 lines 22-27 for reference to the customer application via the API server accessing customer’s merchants and members including exchange of information and data with payment processors, financing processors, and product manufacturers; Col 7 lines 34-67 for reference to the subscription management system providing a rich set application programming interface (API) for developers to seamlessly integrate with their own system utilizing modules within the API to customize the subscription management system including billing plans, fulfillment plants, service providers, invoices, etc.; Figure 1 and related text regarding item 110 ‘API’]
creating quotes, updating billing records, and processing orders automatically through the UI and the one or more APIs [see at least Col 7 lines 34-67 for reference to the subscription management system providing a rich set application programming interface (API) for developers to seamlessly integrate with their own system utilizing modules within the API to customize the subscription management system including billing plans, fulfillment plants, service providers, invoices, etc.; Figure 1 and related text regarding item 110 ‘API’]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the APIs of Parekh to include the subscription-based offering of Nguyen. Doing so would allow for configurability and flexibility in the creation of a bundle of subscriptions, for a specific consumer, to one or more products or services, as stated by Nguyen (Col 3 lines 14-18).
Claim 2
While the combination of Parekh, Sakamoto, and Nguyen disclose the limitations above, Parekh does not disclose comprising managing co-terming of subscriptions using the RTDM to allow for synchronized end dates across different subscription tiers, facilitating subscription lifecycle management.
Regarding Claim 2, Sakamoto discloses the following:
comprising managing co-terming of subscriptions using the RTDM to allow for synchronized end dates across different subscription tiers, facilitating subscription lifecycle management [see at least Paragraph 0197 for reference to if a subscriber has been a customer for a long time, a “length of subscription” data point, for example, may be used to influence the prediction of subscriber churn; Paragraph 0207 for reference to length of subscription lifespan being a subscription-based metric managed by the system; Paragraph 0211 for reference to subscriber-based churn dataset including a length of time that a subscriber has been subscribed to a service]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the trust platform user interface of Parekh to include the real time data mesh subscription data processing of Sakamoto. Doing so would provide a framework or architecture to enable service providers to improve customer experience, as stated by Sakamoto (Paragraph 0050).
Claim 3
While the combination of Parekh, Sakamoto, and Nguyen disclose the limitations above, Parekh does not disclose additionally incorporating an optimization algorithm within the AAML Module for real-time anomaly detection and prevention in subscription usage and billing to maintain accurate and fair pricing.
Regarding Claim 3, Sakamoto discloses the following:
additionally incorporating an optimization algorithm within the AAML Module for real-time anomaly detection and prevention in subscription usage and billing to maintain accurate and fair pricing [see at least Paragraph 0149 for reference to machine learning model can look at anomaly detection for CIR, stability, etc.; Paragraph 0262 for reference to engine may be configured to utilize one or more AI/ML techniques chosen from, but not limited to, computer vision, feature vector analysis, anomaly detection, timeseries forecasting, causal inference, decision trees, boosting, support-vector machines, neural networks, nearest neighbor algorithms, naïve Bayes, bagging, random forests, logistic regression, and the like]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the trust platform user interface of Parekh to include the real time anomaly detection subscription data processing of Sakamoto. Doing so would provide a framework or architecture to enable service providers to improve customer experience, as stated by Sakamoto (Paragraph 0050).
Claim 4
While the combination of Parekh, Sakamoto, and Nguyen disclose the limitations above, Parekh does not disclose utilizing the AAML Module's predictive analytics function to forecast subscription trends and adjust offerings preemptively, ensuring responsiveness to evolving market and customer needs.
Regarding Claim 4, Sakamoto discloses the following:
utilizing the AAML Module's predictive analytics function to forecast subscription trends and adjust offerings preemptively, ensuring responsiveness to evolving market and customer needs [see at least Paragraph 0113 for reference to engine 604 is configured to make predictions based on the statistics and the resolution information (step 612), and the predictions are used to implement network configuration changes to resolve any issues or predicted issues; Paragraph 0114 for reference to engine 604 is configured to perform prediction (step 612) modeling for the identification of specific issues, as described below. The outputs 608 can be proactive monitoring, actionable alerts, at-risk customer predictions, and autonomous resolution outreach; Paragraph 0262 for reference to engine may be configured to utilize one or more AI/ML techniques chosen from, but not limited to, computer vision, feature vector analysis, anomaly detection, timeseries forecasting, causal inference, decision trees, boosting, support-vector machines, neural networks, nearest neighbor algorithms, naïve Bayes, bagging, random forests, logistic regression, and the like]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the trust platform user interface of Parekh to include the predictive analytics detection subscription data processing of Sakamoto. Doing so would provide a framework or architecture to enable service providers to improve customer experience, as stated by Sakamoto (Paragraph 0050).
Claim 5
While the combination of Parekh, Sakamoto, and Nguyen disclose the limitations above, regarding Claim 5, Parekh discloses the following:
implementing a tiered access control mechanism within the SPoG UI, enabling differentiated user experiences based on roles and permissions, thereby safeguarding sensitive subscription data and operations [see at least Paragraph 0028 for reference to depending on permissions, the given user may manage all or some subset of that organization's cloud assets across the CSPs; Paragraph 0087 for reference to examples of different tiers of bundled managed security services, including an “Essentials” tier, an “Enhanced” tier, a “Healthcare” tier, and a “Premium” tier. Each of these tiers includes subscriptions to various services and a set of professional services hours; Paragraph 0138 for reference to the access token comprises a JavaScript Object Notation (JSON) Web Token (JWT) with a set of SAML assertions indicating the user's permissions for the trust platform 102 (e.g., the CSPs 110 or tenants or accounts thereof that the user can access information for)]
Claim 6
While the combination of Parekh, Sakamoto, and Nguyen disclose the limitations above, regarding Claim 6, Parekh discloses the following:
equipping APIs with advanced encryption and authentication protocols to ensure secure data exchange and integration with external software vendors, distributors, and resellers [see at least Paragraph 0043 for reference to security and compliance control management module 118 may utilize the trust platform APIs 114 to automate management and delivery of the security and compliance controls across all managed cloud assets for a particular user or set of users across all of the cloud assets of that user or set of users in the different clouds of the CSPs; Paragraph 0059 for reference to trust platform APIs 114, when accessing the CSPs 110, may obtain any necessary credentials from the key vault; Paragraph 0138 for reference to trust platform APIs 114 then provide the access token to the trust platform GUI]
Claim 7
While the combination of Parekh, Sakamoto, and Nguyen disclose the limitations above, Parekh does not disclose integrating a user engagement tracking module within the SPoG UI to collect feedback and usage data, informing continuous improvement of the subscription offerings and user interface design.
Regarding Claim 7, Sakamoto discloses the following:
integrating a user engagement tracking module within the SPoG UI to collect feedback and usage data, informing continuous improvement of the subscription offerings and user interface design [see at least Paragraph 0119 for reference to Customer Satisfaction Score (CSAT) is a tool for measuring customer satisfaction at certain touchpoints, usually based on survey feedback; Paragraph 0158 for reference to cloud-based Wi-Fi monitoring system 600 can further utilize customer feedback; Paragraph 0206 for reference to impact factors including feedback information that is received from the subscriber (e.g., via a survey, service call, etc.)]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the trust platform user interface of Parekh to include the feedback collection subscription data processing of Sakamoto. Doing so would provide a framework or architecture to enable service providers to improve customer experience, as stated by Sakamoto (Paragraph 0050).
Claim 8
Regarding Claim 8, Parekh discloses the following:
A system for managing multi-tiered software subscriptions in a multi-tiered software subscription ecosystem, comprising [see at least Paragraph 0003 for reference to techniques for access management for multi-cloud workloads; Paragraph 0005 for reference to illustrative embodiments including methods; Paragraph 0038 for reference to the trust platform implementing the trust platform GUI to provide users with a “single pane of glass” for managing cloud assets on any combination of the CSPs; Paragraph 0081 for reference to the trust platform offering services in different tiers; Figure 1 and related text regarding item 112 ‘GUI’; Figure 3 and related text regarding examples of different tiers of bundled managed services]
a Single Pane of Glass User Interface (SPoG UI) configured to provide a unified management interface across multiple subscription tiers for vendors, distributors, resellers, and customers [see at least Paragraph 0038 for reference to the trust platform implementing the trust platform GUI to provide users with a “single pane of glass” for managing cloud assets on any combination of the CSPs; Paragraph 0076 for reference to functionality of the trust platform 102 may be offered in accordance with a subscription model that enables end - users to scale their cloud security operations on-demand as their cloud footprint grows; Paragraph 0134 for reference to access to the trust plat form 102 (e.g., the trust platform GUI 112 providing the single pane of glass for real - time or near real - time visibility; Figure 1 and related text regarding item 112 ‘GUI’]
an Advanced Analytics and Machine Learning (AAML) Module tasked with analyzing subscription data [see at least Paragraph 0036 for reference to the trust platform being implemented on a processing device comprising and implementing functional modules for controlling certain features of the trust platform; Paragraph 0045 for reference to the ephemeral just - in - time access management module 122 of the trust platform 102 is configured to manage accounts for cloud assets (e.g. , used to run hybrid and multi - cloud workloads); Paragraph 0080 for reference to the trust platform, via the trust platform GUI providing interfaces for log management trend analysis and searching, monitoring, and analyzing “big data”]
one or more Application Programming Interfaces (APIs) enabling integration and data exchange across the multi-tiered software subscription ecosystem [see at least Paragraph 0036 for reference to processing device generally comprises at least one processor and an associated memory, and implements one or more functional modules for controlling certain features of the trust platform 102, such as the trust platform GUI 112 and trust platform application programming interfaces (APIs) 114; Paragraph 0038 for reference to the trust platform 102 utilizes the trust platform APIs 114 to interact with the various CSPs 110 (e.g., to collect data from the various CSPs 110 which may be aggregated and formatted for view in a dashboard of the trust platform GUI 112, to deploy controls and manage accounts for cloud assets, etc.); Figure 1 and related text regarding item 114 ‘APIs’]
While Parekh discloses the limitations above, it does not disclose a Real-Time Data Mesh (RTDM) designed for real-time ingestion and synchronization of subscription data across vendors, distributors, and resellers, wherein the RTDM is configured to aggregate and standardize the subscription data from enterprise resource planning systems, customer relationship management systems, and market intelligence data sources using extraction, transformation, and loading processes and data normalization techniques to maintain standardized subscription records; optimize service offerings, generate dynamic pricing models, and adjust subscription terms based on customer segmentation, market demand, and consumption patterns; a Subscription Management Module configured to configure subscription offers including tier-specific terms, conditions, and pricing based on outputs of the RTDM and the AAML Module; wherein the one or more APIs are configured to automatically exchange data with vendor systems, distributor systems, and reseller systems to implement configured subscription offers including quote generation, order processing, and billing; wherein the system is configured to automate subscription lifecycle processes, including initiation, modification, renewal, and termination, leveraging data-driven insights to facilitate personalized and market-responsive subscription management.
However, Sakamoto discloses the following:
a Real-Time Data Mesh (RTDM) designed for real-time ingestion and synchronization of subscription data across vendors, distributors, and resellers, wherein the RTDM is configured to aggregate and standardize the subscription data from enterprise resource planning systems, customer relationship management systems, and market intelligence data sources using extraction, transformation, and loading processes and data normalization techniques to maintain standardized subscription records [see at least Paragraph 0055 for reference to the distributed Wi-Fi system 10 contemplates operation in any physical location where it is inefficient or impractical to service with a single access point, repeaters, or a mesh system; Paragraph 0062 for reference to it is possible for unified control via the cloud using standardized techniques for communication with the cloud; Paragraph 0076 for reference to Wi-Fi data can include aggregated network-wide statistics used to derive network-wide metrics, and the user can drill down to groups or individual accounts; Paragraph 0114 for reference to the cloud-based Wi-Fi monitoring system includes data ingestion of the inputs, and the processing can perform data aggregation, filtering, and pattern matching (aggregation/grouping of users); Paragraph 0116 for reference to network-related data can also include reporting of Wi-Fi related performance metrics via a standardized technique, such as OpenSync; Paragraph 0191 for reference to the system being configured to receive service-based metrics and subscription-based metrics from each subscriber network; Paragraph 0191 for reference to the subscriber churn prediction component being configured to obtain the service and subscription data in order to determine the likelihood of subscriber churn]
optimize service offerings, generate dynamic pricing models, and adjust subscription terms based on customer segmentation, market demand, and consumption patterns [see at least Paragraph 0206 for reference to each impact factor may be associated with one or more weights for defining how much the likelihood of subscriber churn is increased or decreased; Paragraph 0207 for reference to impact factors may also include service-based metrics and/or subscription-based metrics and may be obtained from one or more sources; Paragraph 0207 for reference to subscription-based metrics including i) payment information, j) number of payment activities, k) amounts of payments; Paragraph 0213 for reference to correlating the subscriber churn data with a variety of other datasets including, but not limited to, customer subscription, contract, billing, and/or payment data; Paragraph 0281 for reference to the data can be automatically adjusted and/or updated for each user(s) so as to realize the determined churn prediction and/or provided campaign; Paragraph 0281 for reference to different subscriber segments can be suggested by AI/ML models and/or be specified by marketers for new campaign generation with measurable churn reduction results; Paragraph 0283 for reference to using the churn AI/ML model analysis discussed above respective to the steps of Process 3700, engine 3610 can identify and segment subscribers with predicted 20× and 10× more likely to churn cohorts compared to the base case churn rate; Paragraph 0283 for reference to Once accurate churn predictions and their associated risk factors are generated for each subscriber, associated campaigns may be generated and carried out by the CSP for churn prevention; Figure 8 and related text regarding item 812 ‘subscriber churn prediction component’]
a Subscription Management Module configured to configure subscription offers including tier-specific terms, conditions, and pricing based on outputs of the RTDM and the AAML Module [see at least Paragraph 0236 for reference to the disclosed framework can enable CSP's to target churn-risk subscribers with the following churn prevention campaigns: i) matching the subscriber services to their needs; ii) upselling the subscriber to new or upgraded existing services based on their interests; iii) providing at-risk subscribers with competitive pricing and bundles based on their competitive landscape; Paragraph 0257 for reference to the steps 3706-3710 being performed by a determination module of the prediction engine and steps 3712-3714 being performed by the output module; Paragraph 0281 for reference to the data can be automatically adjusted and/or updated for each user(s) so as to realize the determined churn prediction and/or provided campaign; Paragraph 0281 for reference to different subscriber segments can be suggested by AI/ML models and/or be specified by marketers for new campaign generation with measurable churn reduction results; Paragraph 0283 for reference to using the churn AI/ML model analysis discussed above respective to the steps of Process 3700, engine 3610 can identify and segment subscribers with predicted 20× and 10× more likely to churn cohorts compared to the base case churn rate; Paragraph 0283 for reference to once accurate churn predictions and their associated risk factors are generated for each subscriber, associated campaigns may be generated and carried out by the CSP for churn prevention]
wherein the system is configured to automate subscription lifecycle processes, including initiation, modification, renewal, and termination, leveraging data-driven insights to facilitate personalized and market-responsive subscription management [see at least Paragraph 0150 for reference to customer outreach being automated wherein autonomous workflows are enabled that inform the end consumer about outages affecting the end consumer's user experience, scheduled maintenance of the ISP infrastructure, downtimes of the cloud based Wi-Fi network controllers, local Wi-Fi network topology and optimization issues, or any similar notifications to inform the end consumer about any local, regional, and global issues potentially affecting the end consumer's service; Paragraph 0283 for reference to using the churn AI/ML model analysis discussed above respective to the steps of Process 3700, engine 3610 can identify and segment subscribers with predicted 20× and 10× more likely to churn cohorts compared to the base case churn rate; Paragraph 0283 for reference to Once accurate churn predictions and their associated risk factors are generated for each subscriber, associated campaigns may be generated and carried out by the CSP for churn prevention]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the trust platform user interface of Parekh to include the real time data mesh subscription data processing of Sakamoto. Doing so would provide a framework or architecture to enable service providers to improve customer experience, as stated by Sakamoto (Paragraph 0050).
While the combination of Parekh and Sakamoto disclose the limitations above, they do not disclose wherein the one or more APIs are configured to automatically exchange data with vendor systems, distributor systems, and reseller systems to implement configured subscription offers including quote generation, order processing, and billing.
However, Nguyen discloses the following:
wherein the one or more APIs are configured to automatically exchange data with vendor systems, distributor systems, and reseller systems to implement configured subscription offers including quote generation, order processing, and billing [see at least Col 7 lines 22-27 for reference to the customer application via the API server accessing customer’s merchants and members including exchange of information and data with payment processors, financing processors, and product manufacturers; Col 7 lines 34-67 for reference to the subscription management system providing a rich set application programming interface (API) for developers to seamlessly integrate with their own system utilizing modules within the API to customize the subscription management system including billing plans, fulfillment plants, service providers, invoices, etc.; Figure 1 and related text regarding item 110 ‘API’]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the APIs of Parekh to include the subscription-based offering of Nguyen. Doing so would allow for configurability and flexibility in the creation of a bundle of subscriptions, for a specific consumer, to one or more products or services, as stated by Nguyen (Col 3 lines 14-18).
Claim 9
While the combination of Parekh, Sakamoto, and Nguyen disclose the limitations above, Parekh does not disclose wherein the RTDM is further configured to manage co-terming of subscriptions, allowing for synchronized end dates across different subscription tiers and services, facilitating subscription lifecycle management.
Regarding Claim 9, Sakamoto discloses the following:
wherein the RTDM is further configured to manage co-terming of subscriptions, allowing for synchronized end dates across different subscription tiers and services, facilitating subscription lifecycle management [see at least Paragraph 0197 for reference to if a subscriber has been a customer for a long time, a “length of subscription” data point, for example, may be used to influence the prediction of subscriber churn; Paragraph 0207 for reference to length of subscription lifespan being a subscription-based metric managed by the system; Paragraph 0211 for reference to subscriber-based churn dataset including a length of time that a subscriber has been subscribed to a service]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the trust platform user interface of Parekh to include the real time data mesh subscription data processing of Sakamoto. Doing so would provide a framework or architecture to enable service providers to improve customer experience, as stated by Sakamoto (Paragraph 0050).
Claim 10
While the combination of Parekh, Sakamoto, and Nguyen disclose the limitations above, Parekh does not disclose incorporating an optimization algorithm within the AAML Module for real-time anomaly detection and prevention in subscription usage and billing, enhancing the system's ability to maintain accurate and fair pricing.
Regarding Claim 10, Sakamoto discloses the following:
incorporating an optimization algorithm within the AAML Module for real-time anomaly detection and prevention in subscription usage and billing, enhancing the system's ability to maintain accurate and fair pricing [see at least Paragraph 0149 for reference to machine learning model can look at anomaly detection for CIR, stability, etc.; Paragraph 0262 for reference to engine may be configured to utilize one or more AI/ML techniques chosen from, but not limited to, computer vision, feature vector analysis, anomaly detection, timeseries forecasting, causal inference, decision trees, boosting, support-vector machines, neural networks, nearest neighbor algorithms, naïve Bayes, bagging, random forests, logistic regression, and the like]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the trust platform user interface of Parekh to include the real time anomaly detection subscription data processing of Sakamoto. Doing so would provide a framework or architecture to enable service providers to improve customer experience, as stated by Sakamoto (Paragraph 0050).
Claim 11
While the combination of Parekh, Sakamoto, and Nguyen disclose the limitations above, Parekh does not disclose featuring a predictive analytics function in the AAML Module to forecast subscription trends and adjust offerings preemptively, ensuring the system remains responsive to evolving market and customer needs.
Regarding Claim 11, Sakamoto discloses the following:
featuring a predictive analytics function in the AAML Module to forecast subscription trends and adjust offerings preemptively, ensuring the system remains responsive to evolving market and customer needs [see at least Paragraph 0113 for reference to engine 604 is configured to make predictions based on the statistics and the resolution information (step 612), and the predictions are used to implement network configuration changes to resolve any issues or predicted issues; Paragraph 0114 for reference to engine 604 is configured to perform prediction (step 612) modeling for the identification of specific issues, as described below. The outputs 608 can be proactive monitoring, actionable alerts, at-risk customer predictions, and autonomous resolution outreach; Paragraph 0262 for reference to engine may be configured to utilize one or more AI/ML techniques chosen from, but not limited to, computer vision, feature vector analysis, anomaly detection, timeseries forecasting, causal inference, decision trees, boosting, support-vector machines, neural networks, nearest neighbor algorithms, naïve Bayes, bagging, random forests, logistic regression, and the like]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the trust platform user interface of Parekh to include the predictive analytics detection subscription data processing of Sakamoto. Doing so would provide a framework or architecture to enable service providers to improve customer experience, as stated by Sakamoto (Paragraph 0050).
Claim 12
While the combination of Parekh, Sakamoto, and Nguyen disclose the limitations above, regarding Claim 12, Parekh discloses the following:
further including a tiered access control mechanism within the SPoG UI, enabling differentiated user experiences based on roles and permissions, thereby safeguarding sensitive subscription data and operations [see at least Paragraph 0028 for reference to depending on permissions, the given user may manage all or some subset of that organization's cloud assets across the CSPs; Paragraph 0087 for reference to examples of different tiers of bundled managed security services, including an “Essentials” tier, an “Enhanced” tier, a “Healthcare” tier, and a “Premium” tier. Each of these tiers includes subscriptions to various services and a set of professional services hours; Paragraph 0138 for reference to the access token comprises a JavaScript Object Notation (JSON) Web Token (JWT) with a set of SAML assertions indicating the user's permissions for the trust platform 102 (e.g., the CSPs 110 or tenants or accounts thereof that the user can access information for)]
Claim 13
While the combination of Parekh, Sakamoto, and Nguyen disclose the limitations above, regarding Claim 13, Parekh discloses the following:
wherein the APIs are equipped with advanced encryption and authentication protocols, ensuring secure data exchange and integration with external software vendors, distributors, and resellers [see at least Paragraph 0043 for reference to security and compliance control management module 118 may utilize the trust platform APIs 114 to automate management and delivery of the security and compliance controls across all managed cloud assets for a particular user or set of users across all of the cloud assets of that user or set of users in the different clouds of the CSPs; Paragraph 0059 for reference to trust platform APIs 114, when accessing the CSPs 110, may obtain any necessary credentials from the key vault; Paragraph 0138 for reference to trust platform APIs 114 then provide the access token to the trust platform GUI]
Claim 14
While the combination of Parekh, Sakamoto, and Nguyen disclose the limitations above, Parekh does not disclose comprising a user engagement tracking module within the SPoG UI, designed to collect feedback and usage data to inform continuous improvement of subscription offerings and user interface design.
Regarding Claim 14, Sakamoto discloses the following:
comprising a user engagement tracking module within the SPoG UI, designed to collect feedback and usage data to inform continuous improvement of subscription offerings and user interface design [see at least Paragraph 0119 for reference to Customer Satisfaction Score (CSAT) is a tool for measuring customer satisfaction at certain touchpoints, usually based on survey feedback; Paragraph 0158 for reference to cloud-based Wi-Fi monitoring system 600 can further utilize customer feedback; Paragraph 0206 for reference to impact factors including feedback information that is received from the subscriber (e.g., via a survey, service call, etc.)]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the trust platform user interface of Parekh to include the real time data mesh subscription data processing of Sakamoto. Doing so would provide a framework or architecture to enable service providers to improve customer experience, as stated by Sakamoto (Paragraph 0050).
Claim 15
Regarding Claim 15, Parekh discloses the following:
A computerized method for dynamically adjusting pricing and subscription terms within a software subscription management system including an Advanced Analytics and Machine Learning (AAML) module, a Single Pane of Glass User Interface (SPoG UI), and one or more APIs, the method comprising [see at least Paragraph 0003 for reference to techniques for access management for multi-cloud workloads; Paragraph 0005 for reference to illustrative embodiments including methods; Paragraph 0038 for reference to the trust platform implementing the trust platform GUI to provide users with a “single pane of glass” for managing cloud assets on any combination of the CSPs; Paragraph 0081 for reference to the trust platform offering services in different tiers; Figure 1 and related text regarding item 112 ‘GUI’; Figure 3 and related text regarding examples of different tiers of bundled managed services]
analyzing, by the Advanced Analytics and Machine Learning (AAML) module, the collected data to identify opportunities for optimization of pricing and subscription terms based on market demand, customer segmentation, consumption patterns, and the requirements for co-terming alignments [see at least Paragraph 0036 for reference to the trust platform being implemented on a processing device comprising and implementing functional modules for controlling certain features of the trust platform; Paragraph 0045 for reference to the ephemeral just - in - time access management module 122 of the trust platform 102 is configured to manage accounts for cloud assets (e.g., used to run hybrid and multi - cloud workloads); Paragraph 0080 for reference to the trust platform, via the trust platform GUI providing interfaces for log management trend analysis and searching, monitoring, and analyzing “big data”]
communicating, via the Single Pane of Glass User Interface (SPoG UI) and the one or more APIs, the adjusted terms to all relevant stakeholders within the subscription ecosystem a multi-tiered software subscription ecosystem including vendors, distributors, resellers, and end-users, ensuring informed and timely updates [see at least Paragraph 0038 for reference to the trust platform implementing the trust platform GUI to provide users with a “single pane of glass” for managing cloud assets on any combination of the CSPs; Paragraph 0146 for reference to the plot of the alerts in the first pane is dynamically updated in response to filtering of the table of the alerts utilizing the second set of user interface features; Paragraph 0081 for reference to the trust platform offering services in different tiers; Figure 1 and related text regarding item 112 ‘GUI’]
While Parekh discloses the limitations above, it does not disclose a Real-time Data Mesh (RTDM) and one or more Subscription APIs; collecting, by the Real-Time Data Mesh (RTDM), subscription data across multiple tiers from a distribution network, wherein the RTDM aggregates and standardizes the subscription data from multiple sources within the distribution network to maintain synchronized subscription records; wherein the AAML module applies time-series analysis and anomaly detection to identify trends and unexpected patterns in the subscription data and applies clustering to segment subscription usage patterns; dynamically adjusting, by the AAML module a Subscription Management Module based on output of the AAML module, the subscription pricing and terms in response to the analysis, incorporating predictive analytics to anticipate future market trends and customer needs; communicating, via the Single Pane of Glass User Interface (SPoG UI) and the one or more Subscription APIs, the adjusted pricing and terms to all relevant stakeholders within the subscription ecosystem a multi-tiered software subscription ecosystem including vendors, distributors, resellers, and end-users, ensuring informed and timely updates; implementing the pricing and terms adjustments across the subscription management system, facilitated by the RTDM, to reflect changes in real-time billing and service delivery, wherein the one or more Subscription APIs update subscription offers, terms, conditions, quote records, order records, and billing records across the multi-tiered software subscription ecosystem; and monitoring and refining, by the AAML module in conjunction with feedback collected through the SPoG UI, an effectiveness of the pricing and terms adjustments in an iterative feedback loop.
However, Sakamoto discloses the following:
A computerized method for dynamically adjusting pricing and subscription terms within a software subscription management system included a Real-Time Data Mesh (RTDM) [see at least Paragraph 0050 for reference for reference to intelligent monitoring systems and methods for cloud-based Wi-Fi; Paragraph 0055 for reference to the distributed Wi-Fi system 10 contemplates operation in any physical location where it is inefficient or impractical to service with a single access point, repeaters, or a mesh system; Paragraph 0062 for reference to it is possible for unified control via the cloud using standardized techniques for communication with the cloud]
collecting, by the Real-Time Data Mesh (RTDM), subscription data across multiple tiers from a distribution network, wherein the RTDM aggregates and standardizes the subscription data from multiple sources within the distribution network to maintain synchronized subscription records [see at least Paragraph 0055 for reference to the distributed Wi-Fi system 10 contemplates operation in any physical location where it is inefficient or impractical to service with a single access point, repeaters, or a mesh system; Paragraph 0062 for reference to it is possible for unified control via the cloud using standardized techniques for communication with the cloud; Paragraph 0076 for reference to Wi-Fi data can include aggregated network-wide statistics used to derive network-wide metrics, and the user can drill down to groups or individual accounts; Paragraph 0114 for reference to the cloud-based Wi-Fi monitoring system includes data ingestion of the inputs, and the processing can perform data aggregation, filtering, and pattern matching (aggregation/grouping of users); Paragraph 0116 for reference to network-related data can also include reporting of Wi-Fi related performance metrics via a standardized technique, such as OpenSync; Paragraph 0191 for reference to the system being configured to receive service-based metrics and subscription-based metrics from each subscriber network; Paragraph 0191 for reference to the subscriber churn prediction component being configured to obtain the service and subscription data in order to determine the likelihood of subscriber churn]
wherein the AAML module applies time-series analysis and anomaly detection to identify trends and unexpected patterns in the subscription data and applies clustering to segment subscription usage patterns [see at least Paragraph 0128 for reference to cloud-based Wi-Fi monitoring system 600 is for proactively enhancing customer experience, proactively determine problems, proactively implement solutions, identify trends of issues across entire deployment, and proactively recommend new products and services; Paragraph 0164 for reference to the monitor dashboard including a side panel of trend analysis to illustrate trends of time series data; Paragraph 0228 for reference to the disclosed framework recommending target consumer segments for associated actions, and track churn factors, trends, and actions' progress over time]
dynamically adjusting, by the AAML module a Subscription Management Module based on output of the AAML module, the subscription pricing and terms in response to the analysis, incorporating predictive analytics to anticipate future market trends and customer needs [see at least Paragraph 0281 for reference to the data can be automatically adjusted and/or updated for each user(s) so as to realize the determined churn prediction and/or provided campaign; Paragraph 0281 for reference to different subscriber segments can be suggested by AI/ML models and/or be specified by marketers for new campaign generation with measurable churn reduction results; Paragraph 0283 for reference to using the churn AI/ML model analysis discussed above respective to the steps of Process 3700, engine 3610 can identify and segment subscribers with predicted 20× and 10× more likely to churn cohorts compared to the base case churn rate; Paragraph 0283 for reference to once accurate churn predictions and their associated risk factors are generated for each subscriber, associated campaigns may be generated and carried out by the CSP for churn prevention]
communicating, via a User Interface (UI), the adjusted pricing and terms to all relevant stakeholders within the subscription ecosystem, ensuring informed and timely updates [see at least Paragraph 0280 for reference to engine can communicate information related to the campaign, which can be sent as a message to a device and/or account of the user and/or a device of the user; Paragraph 0281 for reference to via the dashboard, which provides interactive interface objects for each displayed item of data, functionality for exploring problematic cohorts, launch churn prevention campaigns, and track churn rate and trends over time and be enabled]
implementing the pricing and terms adjustments across the subscription management system, facilitated by the RTDM, to reflect changes in real-time billing and service delivery [see at least Paragraph 0055 for reference to the distributed Wi-Fi system contemplates operation in any physical location where it is inefficient or impractical to service with a single access point, repeaters, or a mesh system; Paragraph 0059 for reference to the Wi-Fi mesh network is a fully interconnected grid, sharing the same channel, and allowing multiple different paths between the mesh nodes and the Wi-Fi client device; Paragraph 0283 for reference to Once accurate churn predictions and their associated risk factors are generated for each subscriber, associated campaigns may be generated and carried out by the CSP for churn prevention]
monitoring and refining, by the AAML module in conjunction with feedback collected through the UI, the effectiveness of the pricing and terms adjustments in an iterative feedback loop [see at least Paragraph 0119 for reference to Customer Satisfaction Score (CSAT) is a tool for measuring customer satisfaction at certain touchpoints, usually based on survey feedback; Paragraph 0158 for reference to cloud-based Wi-Fi monitoring system 600 can further utilize customer feedback; Paragraph 0206 for reference to impact factors including feedback information that is received from the subscriber (e.g., via a survey, service call, etc.)]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the trust platform user interface of Parekh to include the real time data mesh subscription data processing of Sakamoto. Doing so would provide a framework or architecture to enable service providers to improve customer experience, as stated by Sakamoto (Paragraph 0050).
While the combination of Parekh and Sakamoto disclose the limitations above, they do not disclose one or more Subscription APIs; communicating, via a User Interface (UI) and the one or more Subscription APIs, the adjusted pricing and terms to all relevant stakeholders within the subscription ecosystem a multi-tiered software subscription ecosystem including vendors, distributors, resellers, and end-users, ensuring informed and timely updates; wherein the one or more Subscription APIs update subscription offers, terms, conditions, quote records, order records, and billing records across the multi-tiered software subscription ecosystem
However, Nguyen discloses the following:
A computerized method for dynamically adjusting pricing and subscription terms within a software subscription management system including one or more Subscription APIs [see at least Figure 1 and related text regarding item 110 ‘API’; Figure 11 and related text regarding a method to create a subscription plan data structure and to facilitate financing of the subscription plan reflected in the data structure; Figure 12 and related text regarding the method of presenting combined one-time payment and subscription payment information to a user on a subscription engine]
communicating, via a User Interface (UI) and the one or more Subscription APIs, the adjusted pricing and terms to all relevant stakeholders within the subscription ecosystem a multi-tiered software subscription ecosystem including vendors, distributors, resellers, and end-users, ensuring informed and timely updates [see at least Col 7 lines 22-27 for reference to the customer application via the API server accessing customer’s merchants and members including exchange of information and data with payment processors, financing processors, and product manufacturers; Col 7 lines 34-67 for reference to the subscription management system providing a rich set application programming interface (API) for developers to seamlessly integrate with their own system utilizing modules within the API to customize the subscription management system including billing plans, fulfillment plants, service providers, invoices, etc.; Col 11 lines 46-51 for reference to the subscription engine combining first and second order presented via a user interface to a user; Figure 1 and related text regarding item 110 ‘API’; Figures 13-21 and related text for reference to user interfaces that a user may be presented via a subscription engine of subscription offerings; Figure 28 and 29 and related text regarding presentation of subscription payment amount on user interface]
wherein the one or more Subscription APIs update subscription offers, terms, conditions, quote records, order records, and billing records across the multi-tiered software subscription ecosystem [see at least Col 7 lines 22-27 for reference to the customer application via the API server accessing customer’s merchants and members including exchange of information and data with payment processors, financing processors, and product manufacturers; Col 7 lines 34-67 for reference to the subscription management system providing a rich set application programming interface (API) for developers to seamlessly integrate with their own system utilizing modules within the API to customize the subscription management system including billing plans, fulfillment plants, service providers, invoices, etc.; Figure 1 and related text regarding item 110 ‘API’]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the APIs of Parekh to include the subscription-based offering of Nguyen. Doing so would allow for configurability and flexibility in the creation of a bundle of subscriptions, for a specific consumer, to one or more products or services, as stated by Nguyen (Col 3 lines 14-18).
Claim 16
While the combination of Parekh, Sakamoto, and Nguyen disclose the limitations above, Parekh does not disclose customizing subscription terms to reflect user preferences and consumption patterns.
Regarding Claim 16, Sakamoto discloses the following:
customizing subscription terms to reflect user preferences and consumption patterns [see at least Paragraph 0197 for reference to if a subscriber has been a customer for a long time, a “length of subscription” data point, for example, may be used to influence the prediction of subscriber churn; Paragraph 0207 for reference to length of subscription lifespan being a subscription-based metric managed by the system; Paragraph 0211 for reference to subscriber-based churn dataset including a length of time that a subscriber has been subscribed to a service]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the trust platform user interface of Parekh to include the real time data mesh subscription data processing of Sakamoto. Doing so would provide a framework or architecture to enable service providers to improve customer experience, as stated by Sakamoto (Paragraph 0050).
Claim 17
While the combination of Parekh, Sakamoto, and Nguyen disclose the limitations above, regarding Claim 17, Parekh discloses the following:
automatically communicating adjustments to users via the SPoG UI [see at least Paragraph 0038 for reference to the trust platform implementing the trust platform GUI to provide users with a “single pane of glass” for managing cloud assets on any combination of the CSPs; Paragraph 0146 for reference to the plot of the alerts in the first pane is dynamically updated in response to filtering of the table of the alerts utilizing the second set of user interface features; Paragraph 0081 for reference to the trust platform offering services in different tiers; Figure 1 and related text regarding item 112 ‘GUI’]
While Parekh discloses the limitations above, it does not disclose automatically communicating pricing adjustments to users via the UI.
However, Sakamoto discloses the following:
automatically communicating pricing adjustments to users via the UI [see at least Paragraph 0280 for reference to engine can communicate information related to the campaign, which can be sent as a message to a device and/or account of the user and/or a device of the user; Paragraph 0281 for reference to via the dashboard, which provides interactive interface objects for each displayed item of data, functionality for exploring problematic cohorts, launch churn prevention campaigns, and track churn rate and trends over time and be enabled]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the trust platform user interface of Parekh to include the pricing adjustment display of Sakamoto. Doing so would provide a framework or architecture to enable service providers to improve customer experience, as stated by Sakamoto (Paragraph 0050).
Claim 18
While the combination of Parekh, Sakamoto, and Nguyen disclose the limitations above, Parekh does not disclose integrating feedback from users and market analysis to refine predictive models related to pricing strategies and subscription terms
Regarding Claim 18, Sakamoto discloses the following:
integrating feedback from users and market analysis to refine predictive models related to pricing strategies and subscription terms [see at least Paragraph 0119 for reference to Customer Satisfaction Score (CSAT) is a tool for measuring customer satisfaction at certain touchpoints, usually based on survey feedback; Paragraph 0158 for reference to cloud-based Wi-Fi monitoring system 600 can further utilize customer feedback; Paragraph 0206 for reference to impact factors including feedback information that is received from the subscriber (e.g., via a survey, service call, etc.)]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the trust platform user interface of Parekh to include the real time data mesh subscription data processing of Sakamoto. Doing so would provide a framework or architecture to enable service providers to improve customer experience, as stated by Sakamoto (Paragraph 0050).
Claim 19
While the combination of Parekh, Sakamoto, and Nguyen disclose the limitations above, Parekh does not disclose employing machine learning algorithms for real-time anomaly detection in subscription usage patterns.
Regarding Claim 19, Sakamoto discloses the following:
employing machine learning algorithms for real-time anomaly detection in subscription usage patterns [see at least Paragraph 0149 for reference to machine learning model can look at anomaly detection for CIR, stability, etc.; Paragraph 0262 for reference to engine may be configured to utilize one or more AI/ML techniques chosen from, but not limited to, computer vision, feature vector analysis, anomaly detection, timeseries forecasting, causal inference, decision trees, boosting, support-vector machines, neural networks, nearest neighbor algorithms, naïve Bayes, bagging, random forests, logistic regression, and the like]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the trust platform user interface of Parekh to include the real time anomaly detection subscription data processing of Sakamoto. Doing so would provide a framework or architecture to enable service providers to improve customer experience, as stated by Sakamoto (Paragraph 0050).
Claim 20
While the combination of Parekh, Sakamoto, and Nguyen disclose the limitations above, Parekh does not disclose utilizing a recommendation engine within the AAML Module to suggest optimal subscription packages to resellers based on historical data and predictive modeling.
Regarding Claim 20, Sakamoto discloses the following:
utilizing a recommendation engine within the AAML Module to suggest optimal subscription packages to resellers based on historical data and predictive modeling [see at least Paragraph 0125 for reference to the autonomous workflow can be triggered with recommended solutions to the most common customer issues; Paragraph 0212 for reference to the process may include suggesting or recommending solutions (e.g., to the customer himself or herself or to a customer service representative) or proactively initiate steps to address issues related to the reasons why a subscriber might churn (e.g., send an email, offer a discount, etc.); Paragraph 0255 for reference to the framework can perform timely processing of data to dynamically update the churn prediction for each subscriber based on their changes over time; Paragraph 0279 for reference to non-limiting campaigns can include, but are not limited to, proactive maintenance for identified users with degraded network performance, upsell campaigns for users with matched services, new package pricing for users in competitive locations, proactive outreach from call centers to address low NPS users, and the like]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the trust platform user interface of Parekh to include the recommendation subscription data processing of Sakamoto. Doing so would provide a framework or architecture to enable service providers to improve customer experience, as stated by Sakamoto (Paragraph 0050).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
DOCUMENT ID
INVENTOR(S)
TITLE
US 2012/0163225 A1
Mishkin et al.
Determining Telecommunication Subscriber Metrics
WO9962261A1
Goode et al.
Interactive information distribution system and method
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
Prosecution Insights