DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Introductory Remarks
In response to communications filed on 14 October 2025, claims 1, 8, 10, 13-14, and 16 are amended per Applicant's request. No claims were cancelled. No claims were withdrawn. No new claims were added. Therefore, claims 1-21 are presently pending in the application, of which claims 1, 8, and 16 are presented in independent form.
The previously raised objection of the claims is withdrawn in view of the amendments to the claims. A new objection has been raised for claim 1 in view of the amendments to claim 1.
The previously raised 112 rejection of the independent claims is withdrawn in view of the amendments to the claims. By virtue of their dependency on their respective independent claims, the 112 rejection has been withdrawn for some of the dependent claims. The 112 rejection has been maintained for some of the dependent claims. A new ground(s) of rejection has been issued for some of the dependent claims.
The previously raised 103 rejection of the pending claims is withdrawn in view of the amendments to the claims. A new ground(s) of rejection has been issued.
Response to Arguments
Applicant’s arguments filed 14 October 2025 with respect to the objection of the claims (see Remarks, p. 10) have been fully considered and are persuasive. The previously raised objections have been withdrawn. However, amendments to claim 1 have raised a new issue. See the objection below for further detail.
Applicant’s arguments filed 14 October 2025 with respect to the 112(f) invocation of the claims (see Remarks, p. 10-11) have been fully considered and are persuasive.
Applicant’s arguments filed 14 October 2025 with respect to the rejection of the claims under 35 U.S.C. 112 (see Remarks, p. 11-14) have been fully considered and are persuasive with respect to the independent claims (as Applicant’s arguments are primarily concerned with the independent claims). Accordingly, the 112 rejections for the independent claims and any dependent claims that were rejected under 35 U.S.C. 112 solely by virtue of their dependency on their independent claims, have been withdrawn.
The 112 rejections have been maintained for the rest of the dependent claims, and new ground(s) have been raised for one or more of the dependent claims in view of the amendments to the independent claims (i.e., lack of antecedent basis).
It is suggested that Applicant amend the dependent claims in a similar manner as the independent claims to overcome the 112 rejections.
Applicant’s arguments filed 14 October 2025 with respect to the rejection of the claims under 35 U.S.C. 103 (see Remarks, p. 14-17) have been fully considered but are not persuasive for claims 1-15 and 21, and moot with respect to claims 16-20 (which do not utilize Jacobs in rejecting the claimed features, and in which the rejection had been modified to conform to the amended claim language).
Applicant argues against Hoang not disclosing the claimed RTDM functionality. However, Jacobs was used to disclose this feature. Furthermore, Applicant argues that Jacobs does not deliver machine-learning insights. However, this feature was rejected using Hoang. Applicant concludes that it is nonobvious to therefore combine the two. However, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co, Inc., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
Furthermore, because Hoang discloses the machine-learning insights which are delivered to end users, with Jacobs disclosing the more particulars of the notification delivery system/architecture, therefore the combination of Hoang and Jacobs (and Keiser) do disclose the claimed invention, contrary to Applicant’s arguments.
A Note on Intended Use
The Examiner notes there are multiple elements in the claims that will be interpreted as intended use. A recitation directed to the manner in which a claimed apparatus is intended to be used does not distinguish the claimed apparatus from the prior art, if the prior art has the capability to so perform, see MPEP 2114 (II) and Ex parte Masham, 2 USPQ2d 1647 (Bd. Pat. App. & Inter. 1987). “Language that suggest or makes optional but does not require steps to be performed does not limit a claim to a particular structure, nor limits the scope of a claim or claim limitation”, see MPEP 2111.04. The Examiner notes the recited prior art has the capability to perform the limitations indicated as intended use.
An incomplete list of the limitations that could be interpreted as intended use is as follows:
Claim 2 recites “ensuring data quality for subsequent analysis within the system”;
Claim 3 and 19 recite “for enhanced analysis”;
Claim 4 recites “enabling data-driven decision-making within the system”;
Claim 6 recites “facilitating communication within the system”;
Claim 7 recites “to optimize system operations” and “to enhance system responsiveness”;
Claim 9 recites “optimizes” screen real estate, “facilitates user engagement” and “ensuring a consistent and user-friendly experience across various devices and platforms”;
Claim 10 recites a standardized format “compatible with analysis and integration processes, ensuring data consistency and compatibility across the data mesh”;
Claim 13 recites “ensuring uninterrupted functionality” and “optimizing user experience and maintaining data consistency”;
Claim 14 recites “ensures data integrity and user privacy”;
Claim 15 recites “facilitating order processing and inventory management”
Claim Objections
Claim 1 is objected to because of the following informalities: in step (f), the claim recites “…wherein the Push Notification Service configured to: (i) monitors real-time data streams…; (ii) identifies data patterns or events…; and (iii) triggers notifications…”. “Configured to” appears to create a grammatical error in the subsequent (i)-(iii) steps, and therefore it appears to be most appropriate to remove the “configured to” language here. Appropriate correction is required.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
This application includes one or more claim limitations that use the word “means” or “step” but are nonetheless not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph because the claim limitation(s) recite(s) sufficient structure, materials, or acts to entirely perform the recited function. Such claim limitation(s) is/are: “a data layer configured to” (in Claims 1 and 10), a “Push Notification Service is configured to” (in Claim 1).
Because this/these claim limitation(s) is/are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are not being interpreted to cover only the corresponding structure, material, or acts described in the specification as performing the claimed function, and equivalents thereof.
If applicant intends to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to remove the structure, materials, or acts that performs the claimed function; or (2) present a sufficient showing that the claim limitation(s) does/do not recite sufficient structure, materials, or acts to perform the claimed function.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 2-3, 7, 9, 14-15, and 19 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the enablement requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to enable one skilled in the art to which it pertains, or with which it is most nearly connected, to make and/or use the invention.
Claim 2 recites “ensuring data quality”. There is a lack of written description to indicate how data quality can be “ensured” by the use of the signal preprocessing methods (including Fourier and wavelet transforms) beyond their pre-existing use. In other words, there is nothing in the Specification to indicate that data quality can be guaranteed, i.e., ensured, every time, simply by the use of signal preprocessing methods (e.g., Fourier and wavelet transforms). In essence, the simple application/use of a pre-existing method does not necessarily guarantee/ensure data quality, nor has Applicant claimed to have invented any sort of different signal preprocessing method to ensure, i.e., guarantee, such a result. Therefore, one of ordinary skill in the art would not be able to use the Specification to implement the claimed invention to effect such a result, and thus the specification is not enabling of such a claimed feature.
Claim 3 and 19 recite “enhanced analysis”. However, there is nothing in the Specification to guarantee that the mere use of deep learning algorithms that extract semantic associations and patterns results in “enhanced” analysis. Therefore, there is a lack of information regarding the relationship between the extraction of semantic associations and patterns, and “enhanced analysis”, and therefore, one skilled in the art could not make or use the claimed invention, as there is insufficient information in the Specification, which only broadly claims the use of deep learning algorithms “for enhanced analysis” as claimed.
Claim 7 recites “optimize system operations” and “enhance system responsiveness”. The Specification only recites the use of an adaptive feedback process and one or more reinforcement learning models, but does not further provide any detail as to how the simple invocation of such components (i.e., the adaptive feedback process and one or more reinforcement learning models), which Applicant has not claimed to have invented nor provide details with respect to their implementation, would guarantee the result of “optimiz[ing] system operations” and “enhanc[ing] system responsiveness” as claimed.
Furthermore, “optimized” is a subjective term that lacks a specific scope, and the scope of “system operations” is undetermined such that it would enable one of ordinary skill in the art to utilize the adaptive feedback process that would lend to optimized system operations. Similarly, “enhancing” also does not have a specific scope, and “system responsiveness” also lacks specificity to be measured. Therefore, one skilled in the art would not be enabled to make or use Applicant’s specification to effect these results.
Additionally, there is no clear relationship between “system responsiveness” and “system operations” (see, e.g., the 112(b), indefiniteness rejection below), and thus one of ordinary skill could not make or use this aspect of the claimed invention.
Claim 9 recites “wherein the UI layer optimizes screen real estate”.
As the claims are directed to the utilization of certain components, but are not directed to any specific implementation, e.g., UI layer is very broad to encompass any sort of layer capable of acting as some sort of gateway or interface between the user and a computer. Therefore, there is a lack of enablement with respect to simply utilizing a UI layer that would necessarily effect the desired result of optimizing screen real estate.
Claim 9 further recites “wherein the UI layer…[ensures] a consistent and user-friendly experience across various devices and platforms”.
As discussed previously, “ensuring” means a “guarantee”. However, simply utilizing a UI layer that “optimizes screen real estate, employs responsive design elements, and facilitates user engagement by prioritizing a perspective of a user” does not “ensure” a consistent and user-friendly experience across various devices and platforms as claimed, as the claims are only directed to utilizing a UI layer that includes characteristics whose implementation is not described by the Specification such that one could make or use the invention to result in a guarantee of a consistent and user-friendly experience across various devices and platforms.
Claim 14 recites “a security and authentication layer that…ensures data integrity and user privacy…”
As indicated previously, the simple invocation/claim to a “security and authentication layer” does not necessarily ensure, i.e., “guarantee”, that data integrity and user privacy are accomplished. A “security and authentication layer”, at best, only allows some degree of protection with respect to the user’s privacy (and may or may not be related to data integrity), but does not “ensure”, i.e., guarantee, that data integrity and user privacy are maintained. As the claimed invention itself is directed simply to the utilization but not to the particular methods of making or using, therefore there is a lack of lack of enablement between the use of a security and authentication layer and the claimed result of ensuring data integrity and user privacy.
Claim 15 recites “a device compatibility module that ensures the mobile application is accessible and functional across a wide range of devices”.
The simple invocation of utilizing a device compatibility module does not necessarily “ensure[] the mobile application is accessible and functional across a wide range of devices”. As noted previously with respect to the data cache, a wide range of processes may be involved with respect to functionality (and accessibility) (not just with device compatibility). Therefore, there is no singular relationship between functionality and the device compatibility module, and thus there is a lack of enablement that ensures an uninterrupted functionality simply by virtue of utilizing a data cache module.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 2-7, 9-11, 13-15 and 19-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 2 recites “wherein the preprocessing employs the signal processing methods…to remove noise from the data, ensuring data quality for subsequent analysis within the system”. It is unclear whether the result is attempting to be claimed (i.e., data quality is ensured), or that this expands upon the preprocessing employing the signal processing method. This language appears to almost be colloquially written. If this is a result, Applicant is recommended to clearly disambiguate the meaning of such language, e.g., using the words “thereby”, or rewriting to, e.g., “wherein the preprocessing ensures data quality for subsequent analysis within the system by employing the signal processing methods…to remove noise from the data”.
Claims 3 and 19 recite “extracting semantic associations and patterns for enhanced analysis”. It is unclear what the metes and bounds of “enhanced” are, as the language appears to indicate that the mere extraction of semantic associations and patterns result in “enhanced” analysis.
Furthermore, it is unclear whether this “enhanced” analysis refers to already-claimed limitations within the independent claims, e.g., whether these are linked to the already-claimed operations of claim 1, or encompass other types of enhanced analysis as well. Therefore, it is unclear what precisely is meant by such a limitation.
Claims 3 and 19 recite “wherein the AAML engine utilizes deep learning to process textual data, extracting semantic associations and patterns for enhanced analysis”. This appears to be written almost colloquially without an explicit linkage between these two steps. Thus, it is not entirely clear what is intended to be claimed here, e.g., Applicant is recommended to amend the language such as “process textual data comprising/including”, for example, in order to disambiguate the meaning of the relationship between these two steps.
Claim 4 recites “wherein the AAML engine employs one or more algorithms…to derive recommended actions based on the analyzed data, enabling data-driven decision-making within the system”. It is unclear whether the result is attempting to be claimed (i.e., the data-driven decision-making within the system), or that this expands upon the recommendation of actions based on the analyzed data. This language appears to almost be colloquially written. If this is a result, Applicant is recommended to clearly disambiguate the meaning of such language, e.g., using the words “thereby”, or rewriting to, e.g., “wherein the AAML engine enables data-driven decision-making within the system by employing one or more algorithms…to derive recommended actions based on the analyzed data”.
Claims 5 and 20 recite delivering notifications to “one or more users”. However, independent claims 1 and 16 (which claims 5 and 20 depend upon) utilize the language “targeted subscribers”. Therefore, it cannot be ascertained whether those “one or more users” are supposed to be the same as “targeted subscribers” due to the lack of consistency in claim language.
Claim 6 recites “wherein the Push Notification Service delivers customized notifications to end-users”. However, independent claim 1 utilizes the language “targeted subscribers”. Therefore, it cannot be ascertained whether those “end-users” are supposed to be the same as “targeted subscribers” due to the lack of consistency in claim language.
It is unclear which step in particular “facilitates communication within the system”, e.g., whether it is the delivering of customized notifications to end-users, or the categorization and prioritization of events step.
Furthermore, this language appears to be written almost colloquially, e.g., to elaborate on a pre-established concept; however, it is unclear whether this was the intention of the claim. Thus, it is unclear whether this is meant to be claimed as the “result” of the first part (i.e., the delivery of notifications or categorization/prioritizing of events), or whether these are separate claim limitations. Applicant is recommended to include language such as “thereby” or “resulting in”, for example, to disambiguate the meaning of such language.
Claim 7 recites “performing an adaptive feedback process to optimize system operations…”. It cannot be ascertained what the relationship between “adaptive feedback process” and “optimiz[ing] system operations” is within the context of the claimed invention, as there are no clear ties between the reinforcement learning models being implemented by the adaptive feedback process and any specific system operations. Furthermore, it is unclear what is “optimizing” of system operations in the context of the claimed invention, e.g., what system operations, what is considered optimized, etc. Therefore, it is unclear what is meant by “optimizing” system operations.
Claim 7 further recites that “wherein the adaptive feedback process comprises implementing one or more reinforcement learning models comprising Proximal Policy Optimization to enhance system responsiveness” is also unclear for a similar reason as the immediate bullet point above (i.e., there are no clear links between the reinforcement learning model and any system operation; thus, it is unclear what is meant by “enhancing” system responsiveness or “optimizing” system operations). Furthermore, it is unclear what is considered “enhanced” system responsiveness within the context of the claimed invention, i.e., how is this evaluated by the system, etc.
Furthermore, the relationship between the system responsiveness and the system operations aspects cannot be established, e.g., whether the system responsiveness is meant to just be one part of the system operations aspect, or whether the system responsiveness is the system operation.
Claim 9 recites “wherein the UI layer optimizes screen real estate”. It is unclear whether this language is referring to the end result (i.e., that the screen real estate is optimized) or the process itself (i.e., that the UI layer performs the operation of optimizing screen real estate).
Claim 10 recites “wherein…the Global Data Lake is configured to transform and harmonize the captured data into a standardized format compatible with analysis and integration processes, ensuring data consistency and compatibility across the mesh…”. There is a lack of antecedent basis issue with “Global Data Lake”, as this language was removed from independent claim 8, which claim 10 depends upon.
Claim 11 recites “wherein the push notification service operates based on an event-driven architecture to deliver real-time notifications based on distribution platform events, communicating information to users about distribution platform events”. This language appears to be written almost colloquially, e.g., to elaborate on a pre-established concept; however, it is unclear whether this was the intention of the claim. Thus, it is unclear whether this is meant to be claimed as the “result” of the first part (i.e., the push notification service operating based on an event-driven architecture to deliver real-time notifications), or whether this is a separate claim limitation.
Claim 13 recites “wherein the offline data cache module store critical data locally on a user device”. However, claim 8, which claim 13 depends upon, already recites “an offline data cache module configured to store data locally on a user device…”. Therefore, there is a lack of antecedent basis issue with such claim language, as Claim 13 substantially overlaps with Claim 8, but ignores that such a limitation had already been mostly claimed, with the exception of adding the language “critical” data. Applicant is recommended to amend the claim, e.g., either “further” stores critical data locally, or that the data being stored locally includes critical data, etc.
Claim 13 further recites “wherein the offline data cache module stores critical data locally on a user device…ensuring uninterrupted functionality” and “[wherein the offline data cache module]…synchronizes with backend servers when connectivity is restored, optimizing user experience and maintaining data consistency”. It is unclear what step is particularly tied to the “optimizing” of user experience. Furthermore, as indicated in claims 8 and 11 above, such language appears to be written almost colloquially, e.g., to elaborate on a pre-established concept; however, it is unclear whether this was the intention of the claim. Thus, it is unclear whether this is meant to be claimed as the “result” of the first part (i.e., the offline data cache module storing critical data locally, and synchronizing with backend servers when connectivity is restored), or whether these are separate claim limitations. Applicant is recommended to include language such as “thereby” or “resulting in”, for example, to disambiguate the meaning of such language.
Claim 13 further recites “optimizing user experience”. The term “optimizing” appears to be a subjective term within the context of “user experience”, and the metes and bounds of such a limitation cannot be established.
Claim 14 recites “and ensures data integrity and user privacy”. It is unclear whether the result is intended to be claimed as a function, as it is claimed separately from the previous steps of performing encryption and decryption on data, enforcing authentication protocols to verify user identities, etc., which are specific functions. Therefore, the metes and bounds of such a limitation cannot be established within the context of the claim.
Claim 15 recites “facilitating order processing and inventory management”. It is unclear what step is particularly tied to the facilitation of the order processing and inventory management in claim 15. Furthermore, such language appears to be written almost colloquially, e.g., to elaborate on a pre-established concept; however, it is unclear whether this was the intention of the claim. Thus, it is unclear whether this is meant to be claimed as the “result” of the first part (i.e., either the device compatibility module or the coupling step), or whether this is a separate claim limitation. Applicant is recommended to include language such as “thereby” or “resulting in”, for example, to disambiguate the meaning of such language.
Claim Rejections - 35 USC § 103
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.
Claims 1-2, 4, 16, 19, and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Hoang et al. (“Hoang”) (US 2023/0222536 A1), in view of Keiser (“Keiser”) (US 6,385,543 B1), in further view of Jacobs et al. (“Jacobs”) (US 10,757,154 B1).
Regarding claim 1: Hoang teaches A computerized method for real-time data integration, analysis, and notification in a mobile application system, the method comprising:
(a) providing a data layer configured to store structured and unstructured data using a distributed database framework, wherein the data layer continuously retrieves data from Enterprise Resource Planning (ERP) systems and Customer Relationship Management (CRM) systems (Hoang, [0116], where the storage system 112 may store one or more data lakes storing raw data, the data lake being populated with data obtained by the data acquisition system 120 and may be in structured, unstructured, or semi-structured form. The data lake may be, e.g., a Hadoop data lake, an Apache Spark data lake, or a Mongo data lake (i.e., Hadoop, Apache Spark, and Mongo being examples of a “distributed database framework”). See Hoang, [0095] and [0124-0125], where the data acquisition system 120 acquires data from different data sources 132, e.g., by crawling the data sources, and organizes such data into one or more data structures, where data sources may include, e.g., client relationship management (CRM) systems, proprietary third-party sources 146, and/or other suitable data sources.
Although Hoang does not appear to explicitly state that one of the types of systems include ERP systems as claimed, Hoang discloses that proprietary third-party sources or other suitable data sources may be implemented as well. Therefore, one of ordinary skill in the art would have been suggested to include ERP systems with the motivation of drawing business data involved in enterprise day-to-day operations, i.e., since such information may be useful for leveraging certain business/marketing insights);
(b) preprocessing the retrieved data by … employing machine learning techniques to extract data features, thereby generating preprocessed data (Hoang, [0146], where the machine learning system 702 selects the types of attributes used to train a prediction model, e.g., by implementing Principal Component Analysis (PCA) to extract features in the training data that correlate the outcomes in the training data, or some other alternative feature engineering technique to select the relevant attributes for a particular training task (i.e., “preprocessing the retrieved data”));
(c) transmitting the preprocessed data to an Advanced Analytics and Machine Learning (AAML) engine (see cited portions of Hoang below);
(d) generating, by the AAML engine, an analytical output, the analytical output comprising one or more insights produced using decision constructs based on the preprocessed data (Hoang, [0069], where the platform 100 trains machine-learned prediction models to predict an outcome (i.e., “analytical output”) given an input set of individual attributes, e.g., the prediction model is leveraged for tasks relating to the particular campaign and/or organization, using any suitable type of model such as a decision tree, neural network, Hidden Markov model, etc. (i.e., “decision constructs”). See Hoang, [0086], where the prediction model, after receiving a set of individual attributes of an individual and the campaign attributes of a campaign (i.e., “transmitting the preprocessed data to an AAML engine”), outputs a predicted propensity of the individual (i.e., “generating, by the AAML engine, an analytical output, the analytical output comprising one or more insights produced using decision constructs based on the preprocessed data”));
(e) receiving, at a Push Notification Service, the analytical output from the AAML engine (Hoang, [0089], where the predicted propensity of a lead that is to be a potential donor or target customer may be used to determine solicitation information, which may be used to auto-generate personalized content for a predicted donor or target customer. See Hoang, [0092], where the platform 100 interacts with a set of user devices 108 associated with supporters or commercial entities such as to identify and communicate with other potential supporters or leads. See Hoang, [0098], where the content generation system 126 generates personalized content that is sent to individuals and/or posted on content publishing platforms 110 (implying that the content generation system 126 received the analytical output, i.e., the “leads”, for generating the personalized content for such “leads”));
(f) operating the Push Notification Service … (Hoang, [0083] and [0092], where content for or about a campaign is published in a content publishing platform 110 via an API of the content publishing platform 110. The campaign platform facilitates publishing content corresponding to a campaign on a content publishing platform 110, which include social networking sites, blogs, news sites, etc., and the content publishing platforms 110 may include messaging clients, whereby the supporter or commercial entity can transmit a personalized message to a lead via a direct message or email) …; and
(g) delivering, by the Push Notification Service, notifications … ( Hoang, [0072], where the platform 100 leverages a donor prediction model on behalf of an organization to identify potential donors to solicit for contributions to a campaign of the organization by feeding an individual profile of the individual to the donor prediction model, determining a confidence score indicating whether the individual is likely to contribute to the campaign, and, if exceeding a threshold, initiating solicitation of a contribution from the individual by, e.g., generating machine-generated text using a natural language processor to include in an email or other suitable electronic communication (i.e., “notifications”), in which the machine-generated text may be automatically sent to the potential donor).
Although Hoang does not appear to explicitly state that the notifications includ[e] the insights generated by the AAML engine, one of ordinary skill in the art would have found it obvious to have modified Hoang to have explicitly included insights with the motivation of expanding the types of contexts that the disclosed system may be applied to, i.e., instead of utilizing Hoang to identifying likely campaign donors, it would have been obvious to have also expanded Hoang to other business applications such as, e.g., growth signals, investments, funding opportunities, mergers and acquisitions, i.e., other types of insights for other types of applications, which would make it useful to communicate such information within the notifications, as needed.
Hoang does not appear to explicitly teach [preprocessing the retrieved data] applying signal processing methods to remove noise; [operating the Push Notification Service] according to one of an event-driven architecture or a publish-subscribe system, wherein the Push Notification Service configured to: (i) monitors real-time data streams from a Real-Time Data Mesh (RTDM) module, the RTDM module utilizing at least one Change Data Capture (CDC) mechanism to detect updates from transactional systems; (ii) identifies data patterns or events within the RTDM module using a distributed data processing framework selected from a distributed stream processing platform or a batch processing platform; and (iii) triggers notifications based on the identified events using a publish-subscribe protocol that employs a broker to filter and distribute messages arranged into topics to subscribers.
Keiser teaches [preprocessing the retrieved data by] applying signal processing methods to remove noise (Keiser, [3:1-9] and [3:66-67]-[4:1-5], where a feature is removed from a signal by a combination of wavelet and Fourier transformation, where a frequency to be removed from the signal may include, e.g., pulse noise, where the frequency is removed from a time domain signal by reducing the samples in the signal by wavelet transformation, projecting the feature to be removed onto a wavelet basis using Fourier transformation and subtracting the projection of the feature from the projection of the original time domain signal).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Hoang and Keiser (hereinafter “Hoang as modified”) with the motivation of removing frequencies that may negatively impact the analysis and also in order to reduce the size of the dataset, i.e., faster analysis later on as less data needs to be sifted through.
Hoang as modified does not appear to explicitly teach [operating the Push Notification Service] according to one of an event-driven architecture or a publish-subscribe system, wherein the Push Notification Service configured to: (i) monitors real-time data streams from a Real-Time Data Mesh (RTDM) module, the RTDM module utilizing at least one Change Data Capture (CDC) mechanism to detect updates from transactional systems; (ii) identifies data patterns or events within the RTDM module using a distributed data processing framework selected from a distributed stream processing platform or a batch processing platform; and (iii) triggers notifications based on the identified events using a publish-subscribe protocol that employs a broker to filter and distribute messages arranged into topics to subscribers.
Jacobs teaches [operating the Push Notification Service] according to one of an event-driven architecture or a publish-subscribe system (Jacobs, [21:33-67]-[22:1-12], where a single event 301 may trigger generation of one or more custom payloads and transmission of one or more different custom payloads to a plurality of subscribers, all in substantially real-time in response to the notification system 150 receiving the event 301. See also Jacobs, [28:49-58], where a real time prescreen notification may be responsible for receiving event notification related to a prescreen of customers, e.g., events may be published to subscribers that would like to prescreen customers based on certain credit criteria, where the notification system may send event notifications to marketing services and/or external clients, who may utilize the published event notifications.
See also Jacobs, [5:27-39], where a publish and subscribe events-based architecture may be implemented to build a real time “pub/sub” protocol whereby transactions or business events from a producer system can be distributed to target end point systems (such as subscribers) simultaneously in real time, where in some embodiments, the notification system uses data streaming to distribute the events. The events-based architecture may complement Services Oriented Architecture principles, whereby each change of state in the producer system may be considered a unique event and wrapped as a “business service” to be delivered to target end points or systems), wherein the Push Notification Service configured to:
(i) monitors real-time data streams from a Real-Time Data Mesh (RTDM) module, the RTDM module utilizing at least one Change Data Capture (CDC) mechanism to detect updates from transactional systems (Jacobs, [6:41-51], [7:20-30], and [12:5-43], where the system receives an indication of a change in data from a producer system (see, e.g., Jacobs, [5:53-67]-[6:1-20], where the system implements an events-based architecture). This indication may be due to a listener configured to automatically perform an action upon listening to a certain event type (i.e., “utilizes at least one Change Data Capture (CDC) mechanism to detect updates from transactional systems”), which then automatically posts a resulting new event to the enterprise service bus (ESB) in real time. See also Jacobs, [FIG. 5], with respect to the real time updates being received by the notification system);
(ii) identifies data patterns or events within the RTDM module using a distributed data processing framework selected from a distributed stream processing platform or a batch processing platform (Jacobs, [9:47-63], where the notification system 150 identifies whether an incoming request or other occurrence satisfies criteria for broadcasting the occurrence as a broadcast event. See Jacobs, [10:15-29], where the notification system 150 determines one or more broadcast event types, where this event type information may be incorporated into an event object generated by the notification system 150. See also Jacobs, [FIG. 2B], item 236, where the system determines that change in the data meets broadcast event criteria based on an indication. See Jacobs, [FIG. 5], where the notification system provides a continuous batch of notifications, which may be delivered to users in batches; or alternatively, real time event notification); and
(iii) triggers notifications based on the identified events using a publish-subscribe protocol that employs a broker to filter and distribute messages arranged into topics to subscribers (Jacobs, [FIG. 2B], items 238-244, where a generated broadcast event object associated with the event is posted to an intermediary message broker, which identifies subscribers registered to receive subscriptions from the intermediary message broker, resulting in the broadcast event message being sent to subscribers. See also Jacobs, [18:43-67]-[19:1-7], where the notification system 150 includes a services registry 310 that is used to publish or post events to the intermediary message broker, where the services registry includes a catalog of events that group event types, and may publish to any subscribers interested in that event type (i.e., “messages arranged into topics to targeted subscribers”). See also Jacobs, [5:53-67]-[6:1-20], where events are delivered by posting the event to an enterprise service bus (ESB), in which events manifested from the publishing system are cataloged (implying that the event messages are “filtered” as claimed via the services registry 310 containing the catalog of events). See Jacobs, [14:52-67]-[15:1-6], where the enterprise service bus 155 identifies subscribers 105 registered to receive subscriptions from the intermediary message broker at block 212. Recall from Jacobs, [5:27-39], where a publish and subscribe events-based architecture may be implemented to build a real time “pub/sub” protocol whereby transactions or business events from a producer system can be distributed to target end point systems (such as subscribers) simultaneously in real time.
Although Jacobs appears to disclose that separate components are involved in filtering and distributing messages whereas the claimed invention utilizes a single component (“broker”) to perform these steps, one of ordinary skill in the art would have found it obvious to have modified Jacobs to consolidate the functions of these various components into a single component with the motivation of reducing the time spent on communicating between various components, i.e., potentially leading to improved efficiency, faster processing, etc.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Hoang as modified and Jacobs (hereinafter “Hoang as modified”) with the motivation of improving the efficiency of the dissemination of information to an individual in real-time (see, e.g., Jacobs, [23:8-19]).
Regarding claim 2: Hoang as modified teaches The method of claim 1, wherein the preprocessing employs the signal processing methods, including Fourier and wavelet transforms, to remove noise from the data, ensuring data quality for subsequent analysis within the system (Keiser, [3:1-9] and [3:66-67]-[4:1-5], where a feature is removed from a signal by a combination of wavelet and Fourier transformation, where a frequency to be removed from the signal may include, e.g., pulse noise, where the frequency is removed from a time domain signal by reducing the samples in the signal by wavelet transformation, projecting the feature to be removed onto a wavelet basis using Fourier transformation and subtracting the projection of the feature from the projection of the original time domain signal).
The Examiner notes that “ensuring data quality for subsequent analysis within the system” has been considered as an intended use/result, and is not afforded patentable weight.
The Examiner notes that “A claim containing a ‘recitation with respect to the manner in which a claimed apparatus is intended to be employed does not differentiate the claimed apparatus from a prior art apparatus’ if the prior art apparatus teaches all the structural limitations of the claim.” Ex parte Masham, 2 USPQ2d 1647 (Bd. Pat. App. & Inter. 1987); see also MPEP § 2114. The recited prior art has the capability to perform these intended use limitations, and therefore, the prior art meets the claimed limitations. See MPEP § 2111.02; See also In re Schreiber, 128 F.3d 1473, 1477, 44 USPQ2d 1429, 1431 (Fed.Cir. 1997).
Because Hoang as modified discloses, suggests, or otherwise renders obvious all the claimed features, the claimed invention does not distinguish over the prior art since Hoang as modified would confer the same intended use/result as claimed.
Regarding claim 4: Hoang as modified teaches The method of claim 1, wherein the AAML engine employs one or more algorithms, including decision trees and Bayesian networks, to derive recommended actions based on the analyzed data, enabling data-driven decision-making within the system (Hoang, [0069], where the platform 100 trains machine-learned prediction models to predict an outcome given an input set of individual attributes, e.g., the prediction model is leveraged for tasks relating to the particular campaign and/or organization, using any suitable type of model such as a decision tree, neural network, Hidden Markov model, etc. See Hoang, [0072], where the platform 100 leverages a donor prediction model on behalf of an organization to identify potential donors to solicit for contributions to a campaign of the organization by feeding an individual profile of the individual to the donor prediction model, determining a confidence score indicating whether the individual is likely to contribute to the campaign, and the user can utilize the information contained in the outputted individual profile information to message or call the potential donor, or have a machine-generated text to be sent out to the potential donor. Initiating solicitation may refer to recommendations that an affiliate of the organization can use in a message or a conversation with the potential donor (i.e., “derive recommended actions based on the analyzed data”)).
The Examiner notes that “enabling data-driven decision-making within the system” has been considered as an intended use/result, and is not afforded patentable weight.
The Examiner notes that “A claim containing a ‘recitation with respect to the manner in which a claimed apparatus is intended to be employed does not differentiate the claimed apparatus from a prior art apparatus’ if the prior art apparatus teaches all the structural limitations of the claim.” Ex parte Masham, 2 USPQ2d 1647 (Bd. Pat. App. & Inter. 1987); see also MPEP § 2114. The recited prior art has the capability to perform these intended use limitations, and therefore, the prior art meets the claimed limitations. See MPEP § 2111.02; See also In re Schreiber, 128 F.3d 1473, 1477, 44 USPQ2d 1429, 1431 (Fed.Cir. 1997).
Because Hoang as modified discloses, suggests, or otherwise renders obvious all the claimed features, the claimed invention does not distinguish over the prior art since Hoang as modified would confer the same intended use/result as claimed.
Regarding claim 16: Claim 16 recites substantially the same claim limitations as claim 1, and is rejected for the same reasons.
Note that Hoang teaches A non-transitory computer-readable storage medium having that, when executed by a processor, cause the processor to perform operations comprising [the claimed steps] (Hoang, [0240], where the disclosed system may be deployed through a machine executing computer software, program codes, and/or instructions on a processor that is embodied in a computer readable medium).
Regarding claim 19: Claim 19 recites substantially the same claim limitations as claim 3, and is rejected for the same reasons.
Regarding claim 21: Hoang as modified teaches The method of claim 1, wherein the at least one distributed data processing framework is selected from APACHE FLINK and APACHE SPARK (Jacobs, [10:41-67]-[11:1-3], where the notification module comprises data streaming configured to publish events to subscribers, where data streaming refers to any technology that processes events and includes the transfer of data. Examples of data streaming technology include FLINK and SPARK).
Claims 3 and 5 are rejected under 35 U.S.C. 103 as being unpatentable over Hoang et al. (“Hoang”) (US 2023/0222536 A1), in view of Keiser (“Keiser”) (US 6,385,543 B1), in further view of Jacobs et al. (“Jacobs”) (US 10,757,154 B1), in further view of Gutman et al. (“Gutman”) (US 2017/0134516 A1).
Regarding claim 3: Hoang as modified teaches The method of claim 1, but does not appear to explicitly teach wherein the AAML engine utilizes deep learning algorithms to process textual data, extracting semantic associations and patterns for enhanced analysis.
Gutman teaches wherein the AAML engine utilizes deep learning algorithms to process textual data, extracting semantic associations and patterns for enhanced analysis (Gutman, [0048] and [0102], where targeting criteria used to identify and target users may include implicit or inferred user interests or connections by analyzing, for example, user posts using analysis involving natural-language processing or keyword extraction, and may determine a user’s interests through semantic analysis, NLP, or a combination of described methods. See also Gutman, [0051], where natural language processing or semantic analysis may be utilized to determine user interests, e.g., by determining whether two terms are related enough to match via natural language processing or semantic analysis. See Gutman, [0035] and [0107], where a decision-tree model may be continuously updated to learn user interactions, and may be constructed using a machine-learning algorithm based on a set of training data (i.e., “learning algorithms”)).
Although Gutman does not appear to explicitly state that the type of learning algorithm is a “deep” learning algorithm as claimed, one of ordinary skill in the art would have found it obvious to have utilized such deep learning algorithms (which are a subset of machine-learning algorithms, which is disclosed by Gutman) with the motivation of improving artificial intelligence task performance.1
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Hoang as modified and Gutman (“Hoang as modified”) with the motivation of automating the process of analyzing information to identify and target users.
The Examiner notes that “for enhanced analysis” has been considered as an intended use/result, and is not afforded patentable weight.
The Examiner notes that “A claim containing a ‘recitation with respect to the manner in which a claimed apparatus is intended to be employed does not differentiate the claimed apparatus from a prior art apparatus’ if the prior art apparatus teaches all the structural limitations of the claim.” Ex parte Masham, 2 USPQ2d 1647 (Bd. Pat. App. & Inter. 1987); see also MPEP § 2114. The recited prior art has the capability to perform these intended use limitations, and therefore, the prior art meets the claimed limitations. See MPEP § 2111.02; See also In re Schreiber, 128 F.3d 1473, 1477, 44 USPQ2d 1429, 1431 (Fed.Cir. 1997).
Because Hoang as modified discloses, suggests, or otherwise renders obvious all the claimed features, the claimed invention does not distinguish over the prior art since Hoang as modified would confer the same intended use/result as claimed.
Regarding claim 5: Hoang as modified teaches The method of claim 1, but does not appear to explicitly teach wherein the Push Notification Service dynamically detects and addresses changing data patterns using AAML processes to deliver real-time notifications to one or more users.
Gutman teaches wherein the Push Notification Service dynamically detects and addresses changing data patterns using AAML processes to deliver real-time notifications to one or more users (Gutman, [0105], where social-graph affinity of various social-graph entities may be determined, where affinity may represent the strength of a relationship or level of interest between particular objects associated with the online social network, such as users, concepts, content, actions, advertisements, and other objects. The overall affinity may change based on continued monitoring of the actions or relationships associated with the social-graph entity (i.e., “dynamically detects and addresses changing data patterns”). Recall from Gutman, [0048], [0051], and [0102], in claim 2 above, where targeting criteria used to identify and target users may include implicit or inferred user interests or connections by analyzing, for example, user posts using analysis involving natural-language processing or keyword extraction, and may determine a user’s interests through semantic analysis, NLP, or a combination of described methods (i.e., “AAML processes”). See Gutman, [0069] and [0084], where the social networking system may identify matches between a user’s interests and tagged content received from one or more publishers, where upon identifying a match between tagged content and a user interest, the system may notify the user of the matched content via delivering notifications. See Gutman, [0158], where disclosed steps may be performed in real time (i.e., “deliver real-time notifications to one or more users”)).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Hoang as modified and Gutman with the motivation of (1) continually updating information in order to determine relevancy at a particular point in time (which may change over time), and thus continually provide relevant notifications to users; and (2) providing real-time notifications so that users are almost immediately notified of pertinent information.
Claims 6 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Hoang et al. (“Hoang”) (US 2023/0222536 A1), in view of Keiser (“Keiser”) (US 6,385,543 B1), in further view of Jacobs et al. (“Jacobs”) (US 10,757,154 B1), in further view of He et al. (“He”) (US 2012/0323933 A1).
Regarding claim 6: Hoang as modified teaches The method of claim 1, wherein the Push Notification Service delivers customized notifications to end-users based on one or more insights generated by the AAML engine (Hoang, [0072], where the platform 100 leverages a donor prediction model on behalf of an organization to identify potential donors to solicit for contributions to a campaign of the organization by feeding an individual profile of the individual to the donor prediction model, determining a confidence score indicating whether the individual is likely to contribute to the campaign, and, if exceeding a threshold (i.e., “leveraging insights generated by the AAML engine”), initiating solicitation of a contribution from the individual by, e.g., generating machine-generated text using a natural language processor to include in an email or other suitable electronic communication (i.e., “customized notifications”), in which the machine-generated text may be automatically sent to the potential donor) … .
Hoang as modified does not appear to explicitly teach [wherein the Push Notification Service] categorizes and prioritizes events based on their significance and targeted audience, facilitating communication within the system.
He teaches [wherein the Push Notification Service] categorizes and prioritizes events based on their significance and targeted audience, facilitating communication within the system (He, [0018], where user data items have an associated priority value 118 which represents the interest or importance of the user data item 116 to the user, where the priority values 118 may be assigned to one of a plurality of categories or types to which the user data items 116 are assigned. See He, [0031-0032], where a notification is ranked or otherwise compared relative to other notifications based on the calculated priority score relative to the priority scores of the other notifications, where a ranking occurs as a function of the calculated priority score).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Hoang as modified and He (hereinafter “Hoang as modified”) with the motivation of identifying notifications considered high priority by a user, as not all notifications are of the same importance to a user, and ensuring that more important items are more likely to be seen by the user (see, e.g., He, [0001]).
The Examiner notes that “facilitating communication within the system” has been considered as an intended use/result, and is not afforded patentable weight.
The Examiner notes that “A claim containing a ‘recitation with respect to the manner in which a claimed apparatus is intended to be employed does not differentiate the claimed apparatus from a prior art apparatus’ if the prior art apparatus teaches all the structural limitations of the claim.” Ex parte Masham, 2 USPQ2d 1647 (Bd. Pat. App. & Inter. 1987); see also MPEP § 2114. The recited prior art has the capability to perform these intended use limitations, and therefore, the prior art meets the claimed limitations. See MPEP § 2111.02; See also In re Schreiber, 128 F.3d 1473, 1477, 44 USPQ2d 1429, 1431 (Fed.Cir. 1997).
Because Hoang as modified discloses, suggests, or otherwise renders obvious all the claimed features, the claimed invention does not distinguish over the prior art since Hoang as modified would confer the same intended use/result as claimed.
Regarding claim 20: Claim 20 recites substantially the same claim limitations as claim 5, and is rejected for the same reasons.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Hoang et al. (“Hoang”) (US 2023/0222536 A1), in view of Keiser (“Keiser”) (US 6,385,543 B1), in further view of Jacobs et al. (“Jacobs”) (US 10,757,154 B1), in further view of Liu et al. (“Liu”) (US 2023/0367696 A1).
Regarding claim 7: Hoang as modified teaches The method of claim 1, further comprising performing an adaptive feedback process to optimize system operations, wherein the adaptive feedback process comprises implementing one or more reinforcement learning models … to enhance system responsiveness (Hoang, [0151], where training of a prediction model can continue once the model is in use based on feedback received by machine learning system 702, which is also referred to as “reinforcement learning”, where the machine learning system 702 ay receive a set of circumstances that led to a prediction, and an outcome related to the campaign, and may update the model according to the feedback).
Hoang as modified does not appear to explicitly teach that the reinforcement learning model compris[es] Proximal Policy Optimization.
Liu teaches the reinforcement learning model compris[es] Proximal Policy Optimization (Liu, [0058] and [0060], where different architectures can be used with a reinforcement-learning model, including a proximal policy optimization (PPO), where PPO uses policies to select an optimal action, where a policy is a mapping from action space to state space).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Hoang as modified and Liu (hereinafter “Hoang as modified”) with the motivation of training the reinforcement model to optimize the policy (Liu, [0060]).
The Examiner notes that “to optimize system operations” and “to enhance system responsiveness” has been considered as an intended use/result, and is not afforded patentable weight.
The Examiner notes that “A claim containing a ‘recitation with respect to the manner in which a claimed apparatus is intended to be employed does not differentiate the claimed apparatus from a prior art apparatus’ if the prior art apparatus teaches all the structural limitations of the claim.” Ex parte Masham, 2 USPQ2d 1647 (Bd. Pat. App. & Inter. 1987); see also MPEP § 2114. The recited prior art has the capability to perform these intended use limitations, and therefore, the prior art meets the claimed limitations. See MPEP § 2111.02; See also In re Schreiber, 128 F.3d 1473, 1477, 44 USPQ2d 1429, 1431 (Fed.Cir. 1997).
Because Hoang as modified discloses, suggests, or otherwise renders obvious all the claimed features, the claimed invention does not distinguish over the prior art since Hoang as modified would confer the same intended use/result as claimed.
Claims 8 and 10-13 are rejected under 35 U.S.C. 103 as being unpatentable over Pinheiro et al. (“Pinheiro”) (US 2022/0114509 A1), in view of Siebel et al. (“Siebel”) (US 2017/0006135 A1), in further view of Nihas et al. (“Nihas”) (US 2022/0067085 A1), in further view of Davidson et al. (“Davidson”) (US 2007/0033569 A1).
Regarding claim 8: Pinheiro teaches A mobile application system, comprising:
(b) a data layer operably connected to headless engines, the headless engines lacking a graphical user interface (GUI), the data layer comprising a global data repository with purposive datastores, the global data repository transforming and harmonizing captured data into a standardized format compatible with analysis across the system (Pinheiro, [0085], where the data architecture decentralizes the data assets into the various domains, and put domain data experts in charge, where in this way, the various domains host and serve their domain data assets on a distributed data lake, where the physical storage location where the datasets actually reside may be, e.g., object stores on the hybrid cloud (i.e., “a Global Data Lake comprising one or more Purposive Datastores”). See Pinheiro, [0088], where the disclosed data mesh-based model, a consumer directly pulls the desired data, served from an appropriate domain, and from a distributed, domain-oriented data lake, before consuming, where the data may be intentionally duplicated data in different “solution domains” as the data is transformed into a shape and format that is suitable for that particular domain’s consumption needs (i.e., “transform and harmonize the captured data into a standardized format compatible with analysis and integration processes”), and also implies that the architectural unit of change in the domain-oriented data architecture is a “solution domain”. See also Pinheiro, [0086-0087] and FIG. 5] with regards to the data mesh diagram/concept, which provides a data architecture and implementation strategy designed to support the development of data and analytics assets with speed and scale.
See Pinheiro, [0084], with regards to the “data mesh operably connected to the one or more headless engines”, where application assets support operational workflows such as customer service, payments, and point of sale interactions which are aligned to the “operational” capabilities of products and are referred to as “operational applications”; application assets that consume business data to provide planning, forecasting, and automated decision making are aligned to the “data and analytics” capabilities of products; data-oriented application assets are composed of modules that can be organized into broad groups including algorithms (heuristics, data science), decision support (reports, analytics), and automated decision making (ML features and models, AI algorithms). See Pinheiro, [0117], where data APIs play a key role in the Data Mesh architecture, in which the APIs support operational applications, and data sets should only be accessed via their published APIs. See also Pinheiro, [0139], where all source and consumer data sets are shared for cross-domain consumption via Data APIs.
Although Pinheiro does not appear to explicitly state that these applications are “headless” as claimed, i.e., “lacking a graphical user interface (GUI)” as claimed, Pinheiro suggests that data sets should only be accessed via their APIs. Therefore, one of ordinary skill in the art would have been suggested by Pinheiro’s disclosure to modify Pinheiro’s applications such that the applications are headless (e.g., only accessible via APIs), with the motivation of enabling systems to simply automate logic rather than having to be interactive, thereby saving resources, bandwidth, and avoiding placing a burden on developers to create graphical interfaces, i.e., easier development/configuration.
See Pinheiro, [0093], where source data may be derived from one or more external domains to provide data for operational and analytics purposes. Although Pinheiro does not appear to explicitly state that one of the types of systems include ERP systems as claimed, Pinheiro broadly discloses that external domains may provide information as source data sets. Therefore, one of ordinary skill in the art would have been suggested to include ERP systems with the motivation of drawing business data involved in enterprise day-to-day operations, i.e., since such information may be useful for leveraging certain business/marketing insights.
See Pinheiro, [0060], [0086-0087] and [FIG. 5], where the disclosed system provides a data architecture and implementation strategy designed to support the development of data and analytics assets with speed and scale. See also See Pinheiro, [0137], where real-time data aggregation and enrichment is provided for operational consumption such as for intelligence applications, which may use operational APIs without the need for creating new data assets within the distributed data lake (i.e., “real-time data lake”), and in such cases, analytics and reporting domain event streams become part of the data mesh architecture. Thus, although Pinheiro does not appear to explicitly state that the analysis and data are in “real-time” as claimed, it would have been obvious to one of ordinary skill in the art to have extended such concepts to receiving data in real-time as well as performing real-time analysis with the motivation providing data as immediately as possible, which may be essential for time-sensitive/critical business decisions);
… [and]
(d) an Advanced Analytics and Machine Learning (AAML) engine generating analytical outputs including insights derived from the harmonized data (Pinheiro, [0139] and [FIG. 10], where in an example, analytics applications may leverage data assets in order to disposition disputes, for example, based on historical customer, account, and merchant disputes. See also, e.g., Pinheiro, [0136-0137], where the data assets are used to support data and analytics needs. See, e.g., Pinheiro, [0084], where application assets include decision support (reports, analytics), and automated decision making (ML features and models, AI algorithms). See Pinheiro, [0005], where Pinheiro identifies a growth in the diversity of use cases consuming data from a central data lake and need for fast-time-to-value from such data, through data-driven capabilities such as analytics and artificial intelligence/machine-learning (AI/ML). Therefore, although Pinheiro does not appear to explicitly state that the data is consumed by an AAML engine as claimed, Pinheiro discloses an intended use of the disclosed data organization for purposes of AI/ML analytics. Therefore, one of ordinary skill in the art would have been suggested to modify Pinheiro to have explicitly applied the disclosed system to an AAML engine as claimed, with the motivation of providing the advantages of speed and scale in supporting the development of data and analytics assets/applications (see, e.g., Pinheiro, [0060]), improving decision-making processes, and increasing operational efficiency).
Pinheiro does not appear to explicitly teach (a) a user interface (UI) layer configured for user interaction on a user device, the layer providing a consistent user experience across devices; (c) a Real-Time Data Mesh (RTDM) module coupled to the data layer, the RTDM module utilizing at least one Change Data Capture (CDC) mechanism to detect updates from transactional systems and providing the updates to downstream analytics components; (e) a Push Notification Service operating according to one of an event-driven architecture or a publish-subscribe system to deliver notifications that include the insights generated by the AAML engine, the Push Notification Service employing a broker to distribute messages arranged into topics to targeted subscribers; (f) an image recognition and Stock Keeping Unit (SKU) mapping engine utilizing one or more artificial intelligence (Al) algorithms for scanning and mapping product images to their corresponding SKUs and dynamically creating new SKUs when products are first identified; and (g) an offline data cache module storing data locally on the user device, and synchronizing with backend servers when connectivity is restored.
Siebel teaches (a) a user interface (UI) layer configured for user interaction on a user device, the layer providing a consistent user experience across devices (Siebel, [0596], where the UI services module 3224 ensures that end users enjoy a consistent visual experience, and can interact with charts and reports delivering clear business insights);
(c) a Real-Time Data Mesh (RTDM) module coupled to the data layer, the RTDM module utilizing at least one Change Data Capture (CDC) mechanism to detect updates from transactional systems and providing the updates to downstream analytics components (Siebel, [0253], where continuous analytics processing allows for real-time or near real-time processing based on data abstracted by the type layer component, where the continuous data processing component 1004 is configured to detect changes, additions, or deletions of data in any of the data sources 208. The system may monitor data corresponding to analytics for which continuous analytics processing should be performed and initiates processing of a corresponding analytic when that data changes);
(e) a Push Notification Service operating according to one of an event-driven architecture or a publish-subscribe system to deliver notifications that include the insights generated by the AAML engine (Siebel, [0594], where the alerting module 3221 can transmit a notification or other informational content to users and/or systems or devices when predefined conditions are met. After analyses are completed by the stream analytics services module 3210, the analytic results (i.e., “insights”)2 can be delivered to the appropriate users or systems via SMS, email, instant message, or other communications system.
Although Siebel does not appear to explicitly state that an event-driven architecture is utilized in this context, Siebel discloses in [0400] the use of an event driven architecture, and in Siebel, [0379], the use of publish/subscribe messaging platform. Therefore, it would have been obvious to one of ordinary skill in the art to have modified Siebel to have explicitly utilized an event-driven architecture as claimed with the motivation of enabling the system to be continually notified of relevant events in the system as they occur (Siebel, [0400]), or a publish/subscribe messaging platform with the motivation of securely and reliability exchanging data from source systems (Siebel, [0379])), the Push Notification Service employing a broker to distribute messages arranged into topics to targeted subscribers (Siebel, [0210], where when acting as a message producer, the integration component 202 or data services component 204 (i.e., “broker”) may publish a message to a topic to ensure that it is delivered to all interested parties. The system, when acting as a message consumer, can act as a durable subscriber to one or more topics, pulling messages off the queue as they arrive.
Note that although Siebel does not appear to explicitly state that “all interested parties” are “subscribers”, one of ordinary skill in the art would have found it obvious to have substituted “parties” with “subscribers” with the motivation of ensuring that the system has a manner of tracking who are “all interested parties” in order to ensure delivery of relevant messages to them.
Furthermore, although Siebel discloses that this messaging is performed after data has been ingested (rather than messages that may contain, e.g., insights), one of ordinary skill in the art would have found it obvious to have modified Siebel to apply these steps within the context of, e.g., Siebel, [0594], with the motivation of grouping notifications/messages according to topic in order to filter, i.e., reduce the number of, messages that are delivered to interested users, and thus narrowing only those relevant messages to interested parties); [and]
(g) an offline data cache module storing data locally on the user device … (Siebel, [0267-0293], where cache in local storage is used as a backend for storing any serializable key-value pair into localStorage, where this may be used to cache several types of data records or asynchronous responses. Sometimes, entire file contents are cached).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Pinheiro and Siebel (hereinafter “Pinheiro as modified”) with the motivation of improving the efficiency of the dissemination of information to an individual in real-time, and for faster query processing by storing information on cache (see, e.g., Siebel, [0267-0293]).
Pinheiro as modified does not appear to explicitly teach (f) an image recognition and Stock Keeping Unit (SKU) mapping engine utilizing one or more artificial intelligence (Al) algorithms for scanning and mapping product images to their corresponding SKUs and dynamically creating new SKUs when products are first identified; and synchronizing [the data cache] with backend servers when connectivity is restored.
Nihas teaches (f) an image recognition and Stock Keeping Unit (SKU) mapping engine utilizing one or more artificial intelligence (Al) algorithms for scanning and mapping product images to their corresponding SKUs and dynamically creating new SKUs when products are first identified (Nihas, [0081-0093], where image data 420 captured by the image sensor 406, e.g., camera (Nihas, [0074]) may be stored in memory 404, where client device 400 obtains an image using the image sensor 406 and image analysis engine 412 identifies a physical item in the image, where image analysis may use feature detection and/or extraction, etc., and perform steps to identify whether the product is new or already exists in inventory via the inventory building application 410 (i.e., “image recognition and Stock keeping Unit (SKU) mapping engine”). The system may locate an existing item record, partial or variant matches (i.e., “scanning and mapping product images to their respective SKUs”). For existing item records, the inventory building application 410 does not create a new item record (Nihas, [0090]). New item records may be created if no matching item record is found (Nihas, [0089]). See Nihas, [0066], where products may be provided with product identifiers (e.g., stock keeping units (SKUs) to facilitate browsing and management. Note that because products are associated with SKUs (see, e.g., Nihas, [0085]), this implies that a new item record would have a new SKU provided for it where SKUs are unique (see Nihas, [0085], where SKU numbers and barcode numbers are unique codes), i.e., “create new SKUs dynamically when a product is identified for the first time, wherein the system automatically maps identified products to unique SKUs without relying on pre-existing SKUs”). See also Nihas, [0121], where the image analysis for data extraction and categorization may employ a machine learning engine).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Pinheiro as modified and Nihas (hereinafter “Pinheiro as modified”) with the motivation of reducing manual labor which can be time-consuming, cost-prohibitive and subject to human error (see, e.g., Nihas, [0003], where building the database of item records can be tedious, time-consuming, and as a result, error-prone).
Pinheiro as modified does not appear to explicitly teach synchronizing [the data cache] with backend servers when connectivity is restored.
Davidson teaches synchronizing [the data cache] with backend servers when connectivity is restored (Davidson, [0087], where local web engine 114 caches web applications 136 and/or web document code 140. In addition, executable code 138 can be stored to provide instructions on how to operate web application 136 and/or web document code 140 when client 104 is offline. Local web engine 114 also stores remote files 144 in engine cache 116. See also Davidson, [0027], where the network status module 132 detects the client’s offline or online status and adjusts the local web engine 114 accordingly to operate a web application offline, and a synchronizing module 134 synchronizes with remote files stored locally with remote files stored at server 102. See Davidson, [0090], where when the client 104 comes back online, the synchronizing module 134 synchronizes the locally cached remote files 144 with remote files 108 on the server).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Pinheiro as modified and Davidson (hereinafter “Pinheiro as modified”) with the motivation of enabling a user to operate a web application offline while continuing to have substantially all of the functionality of the web application (Davidson, [0006] and [0008-0009], where Davidson, [0006] notes the problem of local proxy servers unable to adequately function to provide a working web site when a client is offline), thereby allowing clients to not necessarily be reliant on a working network connection between the client and server (Davidson, [0006]).
Regarding claim 10: Pinheiro as modified teaches The mobile application system of claim 8, wherein the data layer is captures and processes the changed data using change data capture mechanisms, and the Global Data Lake is configured to transform and harmonize the captured data into a standardized format compatible with analysis and integration processes, ensuring data consistency and compatibility across the data mesh, including data retrieval from various enterprise systems (Pinheiro, [0085], where the data architecture decentralizes the data assets into the various domains, and put domain data experts in charge, where in this way, the various domains host and serve their domain data assets on a distributed data lake, where the physical storage location where the datasets actually reside may be, e.g., object stores on the hybrid cloud (i.e., “a Global Data Lake comprising one or more Purposive Datastores”). See Pinheiro, [0088], where the disclosed data mesh-based model, a consumer directly pulls the desired data, served from an appropriate domain, and from a distributed, domain-oriented data lake, before consuming, where the data may be intentionally duplicated data in different “solution domains” as the data is transformed into a shape and format that is suitable for that particular domain’s consumption needs (i.e., “transform and harmonize the captured data into a standardized format compatible with analysis and integration processes”), and also implies that the architectural unit of change in the domain-oriented data architecture is a “solution domain”. See also Pinheiro, [0086-0087] and FIG. 5] with regards to the data mesh diagram/concept, which provides a data architecture and implementation strategy designed to support the development of data and analytics assets with speed and scale.
See Pinheiro, [0093], where source data may be derived from one or more external domains to provide data for operational and analytics purposes. Although Pinheiro does not appear to explicitly state that one of the types of systems include ERP systems as claimed, Pinheiro broadly discloses that external domains may provide information as source data sets. Therefore, one of ordinary skill in the art would have been suggested to include ERP systems with the motivation of drawing business data involved in enterprise day-to-day operations, i.e., since such information may be useful for leveraging certain business/marketing insights.
See Pinheiro, [0060], [0086-0087] and [FIG. 5], where the disclosed system provides a data architecture and implementation strategy designed to support the development of data and analytics assets with speed and scale. See also See Pinheiro, [0137], where real-time data aggregation and enrichment is provided for operational consumption such as for intelligence applications, which may use operational APIs without the need for creating new data assets within the distributed data lake (i.e., “real-time data lake”), and in such cases, analytics and reporting domain event streams become part of the data mesh architecture. Thus, although Pinheiro does not appear to explicitly state that the analysis and data are in “real-time” as claimed, it would have been obvious to one of ordinary skill in the art to have extended such concepts to receiving data in real-time as well as performing real-time analysis with the motivation providing data as immediately as possible, which may be essential for time-sensitive/critical business decisions.
See Pinheiro, [0133], where domain data assets are pulled by the customer and kept up-to-date based on standards such as Change Data Capture (CDC) (i.e., “capture and process the changed data using change data capture mechanisms”)).
Regarding claim 11: Pinheiro as modified teaches The mobile application system of claim 8, wherein the push notification service operates based on an event-driven architecture to deliver real-time notifications based on distribution platform events, communicating information to users about distribution platform events (Siebel, [0400], where event handlers may be registered to perform asynchronous actions when events in the system 1900 occur, where, e.g., the system may need to access or update data in the system 1900. Such an event driven architecture enables the system to be continually notified of relevant events in the system 1900 as they occur. See Siebel, [0146], with respect to the different types of data sources including, e.g., operational data sources. See Siebel, [0352], where the system may send and receive messages in real-time with no interruptions).
Regarding claim 12: Pinheiro as modified teaches The mobile application system of claim 8, wherein the image recognition and SKU mapping engine integrates directly with a camera of the mobile device, utilizing the one or more AI algorithms to analyze product images, including color, shape, texture, and labels, to map them to their respective Stock Keeping Units (SKUs) (Nihas, [0081-0093], where image data 420 captured by the image sensor 406, e.g., camera (Nihas, [0074]) may be stored in memory 404, where client device 400 obtains an image using the image sensor 406 and image analysis engine 412 identifies a physical item in the image, where image analysis may use feature detection and/or extraction, etc., and perform steps to identify whether the product is new or already exists in inventory via the inventory building application 410 (i.e., “one or more AI algorithms for product recognition”). The identification of the physical item may be identified by the detection of certain features, including shapes, sizes, labels, colour (see Nihas, [0098]), etc.).
Although Nihas does not appear to explicitly state that “texture” is also analyzed, Nihas discloses that other item identifying data may be extracted from the image for performing recognition (Nihas, [0100]). Therefore, one of ordinary skill in the art would have found it obvious to have also included the claimed “texture” with the motivation of capturing various characteristics/attributes for image analysis, which includes texture3, and which may help with distinguishing items from one another, e.g., from a background, from other items in the image that do not share the same pattern (similar to how humans visually distinguish items from one another partially based on texture)).
Regarding claim 13: Pinheiro as modified teaches The mobile application system of claim 8, wherein the offline data cache module stores critical data locally on a user device, including order status, product details, and user preferences, ensuring uninterrupted functionality, and synchronizes with backend servers when connectivity is restored, optimizing user experience and maintaining data consistency (Davidson, [0087], where local web engine 114 caches web applications 136 and/or web document code 140. In addition, executable code 138 can be stored to provide instructions on how to operate web application 136 and/or web document code 140 when client 104 is offline. Local web engine 114 also stores remote files 144 in engine cache 116. See also Davidson, [0027], where the network status module 132 detects the client’s offline or online status and adjusts the local web engine 114 accordingly to operate a web application offline, and a synchronizing module 134 synchronizes with remote files stored locally with remote files stored at server 102. See Davidson, [0090], where when the client 104 comes back online, the synchronizing module 134 synchronizes the locally cached remote files 144 with remote files 108 on the server. Note that “synchronization” results in the same copies being found in both the local and remote data file copies, i.e., the claimed “maintaining data consistency”).
Although Davidson does not appear to explicitly state that the type of information being stored pertain to order status, product details, and user preferences, the claimed invention does not distinguish over the prior art because the differences in the claim limitations and the prior art’s disclosure are only found in the nonfunctional descriptive material and are not functionally involved in the steps recited. The storage, retrieval, and synchronization of the data would have been performed the same regardless of the specific data involved (i.e., the claimed type of data, Davidson’s files, or some other data). Thus, this descriptive material will not distinguish the claimed invention from the prior art in terms of patentability. See In re Gulack, 703 F.2d 1381, 1385, 217 USPQ2d 401, 404 (Fed. Cir. 1983); In re Lowry, 32 F.3d 1579, 32 USPQ2d 1031 (Fed. Cir. 1994).
Therefore, it would have been obvious to a person of ordinary skill in the art to have referred to Davidson’s teachings in making the claimed invention, because such data does not functionally relate to the steps in the method claimed and because the subjective interpretation of the data does not patentably distinguish the claimed invention over the prior art.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Pinheiro as modified and Davidson with the motivation of identifying and authorizing an incoming web application (Davidson, [0069]) and to protect/prevent unrestrained access to local files (Davidson, [0082-0083]).
The Examiner notes that “ensuring uninterrupted functionality” and “optimizing user experience and maintaining data consistency” have been considered as an intended use/result, and is not afforded patentable weight.
The Examiner notes that “A claim containing a ‘recitation with respect to the manner in which a claimed apparatus is intended to be employed does not differentiate the claimed apparatus from a prior art apparatus’ if the prior art apparatus teaches all the structural limitations of the claim.” Ex parte Masham, 2 USPQ2d 1647 (Bd. Pat. App. & Inter. 1987); see also MPEP § 2114. The recited prior art has the capability to perform these intended use limitations, and therefore, the prior art meets the claimed limitations. See MPEP § 2111.02; See also In re Schreiber, 128 F.3d 1473, 1477, 44 USPQ2d 1429, 1431 (Fed.Cir. 1997).
Because Pinheiro as modified discloses, suggests, or otherwise renders obvious all the claimed features, the claimed invention does not distinguish over the prior art since Pinheiro as modified would confer the same intended use/result as claimed.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Pinheiro et al. (“Pinheiro”) (US 2022/0114509 A1), in view of Siebel et al. (“Siebel”) (US 2017/0006135 A1), in further view of Nihas et al. (“Nihas”) (US 2022/0067085 A1), in further view of Davidson et al. (“Davidson”) (US 2007/0033569 A1), in further view of Wong et al. (“Wong”) (US 2003/0070061 A1).
Regarding claim 9: Pinheiro as modified teaches The mobile application system of claim 8, but does not appear to explicitly teach wherein the UI layer optimizes screen real estate, employs responsive design elements, and facilitates user engagement by prioritizing a perspective of a user, including the arrangement of menus, buttons, and navigation bars, ensuring a consistent and user-friendly experience across various devices and platforms.
Wong teaches wherein the UI layer optimizes screen real estate, employs responsive design elements, and facilitates user engagement by prioritizing a perspective of a user, including the arrangement of menus, buttons, and navigation bars (Wong, [0178], where the system selects the best suitable transformation rule by first prioritizing rules according to their types, including, e.g., based on space reduction parameters, etc. See also, e.g., Wong, [0157-0162], where layout customization may involve modifications to optimize the size of the page to fit the display screen of a target heterogeneous device platform, e.g., by dynamically rearranging the platform independent widgets within the page using a flow layout manager (i.e., “responsive design elements”). Transformation rules may be applied to achieve suitable size modification of the platform specific widgets in the page(s) to fit the display screen of the target heterogeneous device platform. See Wong, [0048], where the components, called GUI components, include graphical buttons, menus, and/or other features capable of display on a display screen; see also Wong, [0095], where a navigation bar/menu may be created within a presentation to move between pages. See also, e.g., Wong, [0110], where the dynamic layout module 60 dynamically configures an intermediate representation (IR) tree to represent a device platform dependent presentation, where dynamic configuration involves placing the scalable graphic user interface (SGUI) components represented by the IR tree in a page(s) of a presentation, e.g., according to the layout structure and other constraints specified by the application GUI), ensuring a consistent and user-friendly experience across various devices and platforms (Wong, [0070], where the SGUI components are graphical user interface components that are device independent and supported by different heterogeneous device platforms operable with the SGUI system, including generating a presentation for a display screen of one of the heterogeneous device platforms, where the different heterogeneous device platforms may be any device that includes a display screen and the capability to run a scalable application (Wong, [0041-0042]). See Wong, [0114], where the style guide parameters may standardize the visual appearance of the SGUI components to provide a consistent appearance within a presentation).
The Examiner notes that “optimizes [screen real estate]”, “facilitates user engagement”, and “ensuring a consistent and user-friendly experience across various devices and platforms” have been considered as an intended use/result, and is not afforded patentable weight.
The Examiner notes that “A claim containing a ‘recitation with respect to the manner in which a claimed apparatus is intended to be employed does not differentiate the claimed apparatus from a prior art apparatus’ if the prior art apparatus teaches all the structural limitations of the claim.” Ex parte Masham, 2 USPQ2d 1647 (Bd. Pat. App. & Inter. 1987); see also MPEP § 2114. The recited prior art has the capability to perform these intended use limitations, and therefore, the prior art meets the claimed limitations. See MPEP § 2111.02; See also In re Schreiber, 128 F.3d 1473, 1477, 44 USPQ2d 1429, 1431 (Fed.Cir. 1997).
Because Pinheiro as modified discloses, suggests, or otherwise renders obvious all the claimed features, the claimed invention does not distinguish over the prior art since Pinheiro as modified would confer the same intended use/result as claimed.
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Pinheiro et al. (“Pinheiro”) (US 2022/0114509 A1), in view of Siebel et al. (“Siebel”) (US 2017/0006135 A1), in further view of Nihas et al. (“Nihas”) (US 2022/0067085 A1), in further view of Davidson et al. (“Davidson”) (US 2007/0033569 A1), in further view of McFall et al. (“McFall”) (US 2020/0327252 A1).
Regarding claim 14: Pinheiro as modified teaches The mobile application system of claim 8, further comprising a security and authentication layer that performs encryption and decryption on data , [and] enforces authentication protocols to verify user identities (Davidson, [0069-0075], where security codes can be implemented at various steps along the process for executing a web application on a client 104, e.g., security codes can be implemented to allow web application 106 or 136, executable code 138, and/or web document code 140 to access local web engine 114. Security codes may be used to identify and authorize an incoming web application (i.e., “in transit”), upon which then the authorized incoming web application, executable code, and/or web document containing the security code is allowed access to local web engine 114 and may be cached in engine cache 116 and/or browser cache 112. The source security code includes one or more authentication codes 161 for performing one or more authentication techniques (i.e., “data encryption to safeguard sensitive information”). See also Davidson, [0082], where during offline scenarios, user security code 163 and security module 130 can operate to maintain secure access to information stored in engine cache 116 (i.e., “at rest”) similar to how a server 102 would maintain access to remote files 108, e.g., the client 104 and server 102 going through an encryption and/or decryption process (i.e., “performs encryption and decryption on data”) at both ends in order to ensure that the user is legitimate, and similarly when the user is offline) … .
Pinheiro as modified does not appear to explicitly teach [ensuring] data integrity and user privacy, wherein the security and authentication layer comprises data lineage and audit trail mechanisms.
McFall teaches [ensuring] data integrity and user privacy, wherein the security and authentication layer comprises data lineage and audit trail mechanisms (McFall, [0308-0309], where data lineage metadata is supported, which allows files that have been derived in some way from other files to be connected, recording their origin. The metadata is exposed for the benefit of external applications that are interested in locating safe copies in preference to the sensitive originals. The link may also be used to read the original metadata and applied to the derived copy. See McFall, [0022], where an audit trail of all classification and anonymization activity may be inspected).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Pinheiro as modified and McFall (hereinafter “Pinheiro as modified”) with the motivation of locating safe copies and hiding sensitive originals (see, e.g., McFall, [0309]).
The Examiner notes that “ensures data integrity and user privacy” has been considered as an intended use/result, and is not afforded patentable weight.
The Examiner notes that “A claim containing a ‘recitation with respect to the manner in which a claimed apparatus is intended to be employed does not differentiate the claimed apparatus from a prior art apparatus’ if the prior art apparatus teaches all the structural limitations of the claim.” Ex parte Masham, 2 USPQ2d 1647 (Bd. Pat. App. & Inter. 1987); see also MPEP § 2114. The recited prior art has the capability to perform these intended use limitations, and therefore, the prior art meets the claimed limitations. See MPEP § 2111.02; See also In re Schreiber, 128 F.3d 1473, 1477, 44 USPQ2d 1429, 1431 (Fed.Cir. 1997).
Because Pinheiro as modified discloses, suggests, or otherwise renders obvious all the claimed features, the claimed invention does not distinguish over the prior art since Pinheiro as modified would confer the same intended use/result as claimed.
Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over Pinheiro et al. (“Pinheiro”) (US 2022/0114509 A1), in view of Siebel et al. (“Siebel”) (US 2017/0006135 A1), in further view of Nihas et al. (“Nihas”) (US 2022/0067085 A1), in further view of Davidson et al. (“Davidson”) (US 2007/0033569 A1), in further view of Shukla (“Shukla”) (US 2014/0052840 A1).
Regarding claim 15: Pinheiro as modified teaches The mobile application system of claim 8, further comprising … coupling imaging components of the mobile device to the one or more AI algorithms for product recognition, facilitating order processing and inventory management (Nihas, [0081-0093], where image data 420 captured by the image sensor 406, e.g., camera (Nihas, [0074]) may be stored in memory 404, where client device 400 obtains an image using the image sensor 406 and image analysis engine 412 identifies a physical item in the image, where image analysis may use feature detection and/or extraction, etc., and perform steps to identify whether the product is new or already exists in inventory via the inventory building application 410 (i.e., “one or more AI algorithms for product recognition”)).
The Examiner notes that “facilitating order processing and inventory management” have been considered as an intended use/result, and is not afforded patentable weight.
The Examiner notes that “A claim containing a ‘recitation with respect to the manner in which a claimed apparatus is intended to be employed does not differentiate the claimed apparatus from a prior art apparatus’ if the prior art apparatus teaches all the structural limitations of the claim.” Ex parte Masham, 2 USPQ2d 1647 (Bd. Pat. App. & Inter. 1987); see also MPEP § 2114. The recited prior art has the capability to perform these intended use limitations, and therefore, the prior art meets the claimed limitations. See MPEP § 2111.02; See also In re Schreiber, 128 F.3d 1473, 1477, 44 USPQ2d 1429, 1431 (Fed.Cir. 1997).
Because Pinheiro as modified discloses, suggests, or otherwise renders obvious all the claimed features, the claimed invention does not distinguish over the prior art since Pinheiro as modified would confer the same intended use/result as claimed.
Pinheiro as modified does not appear to explicitly teach a device compatibility module that ensures the mobile application is accessible and functional across a wide range of devices, including smartphones and tablets, irrespective of their operating systems.
Shukla teaches a device compatibility module that ensures the mobile application is accessible and functional across a wide range of devices, including smartphones and tablets, irrespective of their operating systems (Shukla, [0033], where a versatile configuration of the application may promote the portability of the application and an equivalent execution and presentation in any contextual rendering of the computing environment. See Shukla, [0040], where the device examines the source code or script to examine the application for incompatible/problematic code. See Shukla, [0030], where a web-browser-based application may be more readily implemented in a platform-independent manner than an application to be natively executed, which may depend more closely on a set of application programming interfaces exposed by a particular operating system, implying that the disclosed application may be utilized with different operating systems and that a web-browser-based application is more accessible/functional across a wide range of devices. See Shukla, [0055], where example computing devices include, but are not limited to, personal computers, mobile devices such as mobile phones, consumer electronics, etc. Thus, although Shukla does not appear to explicitly state “smartphones” and “tablets” as claimed, one of ordinary skill in the art would have recognized that “smartphones” and “tablets” fall under mobile phones and consumer electronics, as disclosed by Shukla, and therefore does not distinguish over the prior art).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Pinheiro as modified and Shukla with the motivation of enabling a diverse set of devices and platforms to execute the application (see, e.g., Shukla, [0002]).
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Hoang et al. (“Hoang”) (US 2023/0222536 A1), in view of Keiser (“Keiser”) (US 6,385,543 B1), in further view of Jacobs et al. (“Jacobs”) (US 10,757,154 B1), in further view of Haase et al. (“Haase”) (US 2020/0320095 A1).
Regarding claim 17: Hoang as modified teaches The computer-readable medium of claim 16, but does not appear to explicitly teach further comprising instructions for implementing change data capture using one or more trigger-based, machine-learning or polling-based change data capture (CDC) algorithms.
Haase teaches instructions for implementing change data capture using one or more trigger-based, machine-learning or polling-based CDC algorithms (Haase, [0019-0021], where the disclosed system implements change data capture (CDC) through the use of database triggers 204 that may capture operations of records in the source database tables 202).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Hoang as modified and Haase with the motivation of avoiding creating additional database triggers for a source database, in addition to not locking tables when changes occurs, since database triggers handle each operation separately (see, e.g., Haase, [0021]).
Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over Hoang et al. (“Hoang”) (US 2023/0222536 A1), in view of Keiser (“Keiser”) (US 6,385,543 B1), in further view of Jacobs et al. (“Jacobs”) (US 10,757,154 B1), in further view of Pinheiro et al. (“Pinheiro”) (US 2022/0114509 A1).
Regarding claim 18: Hoang as modified teaches The computer-readable medium of claim 16, but does not appear to explicitly teach wherein the data layer comprises Purposive Datastores (PDSes) for retrieval and storage of specific types of data.
Pinheiro teaches wherein the data layer comprises Purposive Datastores (PDSes) for retrieval and storage of specific types of data (Pinheiro, [0085], where the data architecture decentralizes the data assets into the various domains, and put domain data experts in charge, in which data is transformed into a shape and format suitable for that particular domain’s consumption needs. See Pinheiro, [0072], where the disclosed system provides a data architecture and implementation strategy designed to support the development of data and analytics assets with speed and scale in an automated, efficient, scalable, and reliable manner).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Hoang as modified and Pinheiro with the motivation of having various domains hosting and serving their domain data assets in a fast and easily consumable way on a distributed data lake (see Pinheiro, [0085]), since, e.g., the data is in a format that may be specific to the needs of the domain, and domain experts may be best at managing their specialized domains.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to IRENE BAKER whose telephone number is (408)918-7601. The examiner can normally be reached M-F 8-5PM PT.
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, NEVEEN ABEL-JALIL can be reached at (571)270-0474. 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.
/IRENE BAKER/Primary Examiner, Art Unit 2152
14 February 2026
1 See, e.g., Wiebe et al. US 2017/0364796 A1 at [0003].
2 See Siebel, [0595], where the UI services modules provides visualization of analytical results so that end users may receive “insights” that are clear and actionable. This indicates that Siebel’s use of “analytic(al)” results comprises “insights” as claimed.
3 See, e.g., Gokturk et al. US 2008/0082426 A1 at [0059], where features extracted from an image may be class-specific descriptors that apply to the image object as a whole, such as primary color, patterns, shape, and texture.