DETAILED ACTION
Status of Claims
The present application, filed on or after 3/16/2013, is being examined under the first inventor to file provisions of the AIA .
This action is in reply to the Remarks and Amendments filed 10/30/2025.
Claims 1-10, 13, 15, 17, 24, 27, 29, 31 are canceled.
Claims 11, 12, 14, 18-23, 25-26, 28, 32-36 have been amended.
Claims 11, 12, 14, 16, 18-23, 25-26, 28, 30, 32-36 have been examined and are pending.
(AIA ) Examiner Note
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned at the time any inventions covered therein were effectively filed absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned at the time a later invention was effectively filed in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention
Claim Rejections - 35 USC § 112
The following is a quotation 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 35 U.S.C. 112 (pre-AIA ), first paragraph:
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 11, 12, 14, 16, 18-23, 25-26, 28, 30, 32-36 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 written description requirement. The claims contain subject matter which is not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor(s), at the time the application was filed, had possession of the claimed invention.
Independent claims 11 and 25 recite limitations directed towards the following:
generating by the trained AI model, one or more outputs identifying (i) the first candidate third-party service provider, and (ii) a level of confidence that the first service of the first candidate third-party service provider is suitable for the client organization.”
The Specification is devoid of any description of a specific AI model and is devoid of any specific training of AI models of any kind. The Specification only makes generic assertions that a model may exist and it may be trained with input data such as historical data which is nothing more than a disclosure at the highest levels of generality. This deficiency indicates that the Specification describes only "a mere wish or plan for" generating the desired output via a trained AI model. See Eli Lilly, 119 F .3d at 1566 (citation omitted). As such, the broadly recited limitation "merely recite[s] a description of the problem to be solved," and leaves to future inventors to "complete an unfinished invention." See Ariad, 598 F.3d at 1353. In this case, without the Specification describing any particular algorithm to achieve the claimed function of generating by the trained AI model, one or more outputs identifying (i) the first candidate third-party service provider, and (ii) a level of confidence that the first service of the first candidate third-party service provider is suitable for the client organization, one of ordinary skill in the art would not have reasonably concluded that the inventors invented the claimed invention or that they possessed the claimed subject matter at the time of filing of the application. See Vasudevan, 782 F.3d at 683; see also Regents, 119 F.3d at 1566; § 112 Guidance at 61.
To satisfy the written description requirement of 35 U.S.C. § 112, first paragraph, the Specification must reasonably convey to an artisan of ordinary skill that Appellant had possession of the claimed invention at the time the application was filed. Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 682 (Fed. Cir. 2015) (citing Ariad Pharm., Inc. v. Eli Lilly & Co., 598 F.3d 1336, 1351 (Fed. Cir. 2010) (en banc)). Functional claim language that merely describes an intended result and fails to support the scope of the claimed invention is insufficient to show possession, even when the claim recitations are found word-for-word in the Specification. Vasudevan, 782 F.3d at 682 ("[t]he written description requirement is not met if the specification merely describes a 'desired result"') (citing Ariad, 598 F.3d at 1349); Enzo Biochem, Inc. v. Gen-Probe, Inc., 323 F.3d 956, 968 (Fed. Cir. 2002) ("[t]he appearance of mere indistinct words in a specification or a claim, even an original claim, does not necessarily satisfy" the written description requirement). The Specification must explain, for example, how Appellant intended to achieve the claimed function to satisfy the written description requirement. Vasudevan, 782 F.3d at 683. While "[t]here is no rigid requirement that the disclosure contain 'either examples or an actual reduction to practice,"' due to the written description requirement, the Specification must set forth "an adequate description that 'in a definite way identifies the claimed invention' in sufficient detail such that a person of ordinary skill would understand that the inventor had made the invention at the time of filing." Allergan, Inc. v. Sandoz Inc., 796 F.3d 1293, 1308 (Fed. Cir. 2015) (citing Ariad, 598 F.3d at 1352); see also Examining Computer-Implemented Functional Claim Limitations for Compliance with 35 US.C. 112, 84 F.R. 57, 61- 62 (January 7, 2019) ("112 Guidance").
Here, the Specification does not sufficiently support the recited functions and or their use to achieve the recited result in the aforementioned limitations; i.e. Applicant has not demonstrated he possessed a “trained AI model” capable of generating the outputs as claimed from the recited inputs as claimed.
The specification does not provide a single technique nor method nor algorithm regarding what a “trained AI model” must encompass such that the "generating", as claimed, may be accomplished because no particular “trained AI model” is provided in the entire original disclosure. This is akin to claiming a computer performs the claimed functionality without reciting the necessary steps the computer must take to achieve the results and without reciting necessary algorithms which the computer must perform to achieve the claimed results.
Instead, the Specification at best describes generic types of AI models which might be used, e.g. per Specification at [0075]-[0077] noting merely: “…In some embodiments, an artificial intelligence (Al) model (e.g., also referred to as an "machine learning model" herein) can include a discriminative AI model (also referred to as "discriminative machine learning model" herein), a generative AI model (also referred to as "generative machine learning model" herein), and/or other AI model…" However, general acknowledgement of entire classes or fields of AI models is not evidence that applicant is in possession of a particular “trained AI model” which is capable of generating the “output” now claimed from the “input” which is claimed to be provided to the generically recited “trained AI model”.
Under these circumstances, the Examiner has determined the Specification merely states a wish for the functions and desired result recited in the aforementioned limitations, and does not demonstrate how the Applicant actually intended to achieve the claimed functions and result. Further, the Specification does not describe the claimed invention in sufficient detail such that an ordinarily skilled artisan would understand that the inventor had made the invention at the time of filing. Thus, the Examiner rejects claims 11 and 25 under 35 U.S.C. § 112(a) for a lack of written description support.
Dependent claims 12, 14, 16, 18-23, 26, 28, 30, 32-36 inherit the deficiencies of their parent claim and are also rejected under 35 U.S.C. 112(a) as failing to comply with the written description requirement.
The following is a quotation of 35 U.S.C. 112(b):
(B) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 11, 12, 14, 16, 18-23, 25-26, 28, 30, 32-36 are rejected under 35 U.S.C. 112(b) or (for pre-AIA ) 35 U.S.C. 112, second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor, a joint inventor, or (for pre-AIA ) the applicant regards as the invention.
Independent claims 11 and 25 have been amended to recite in part the following: “…wherein the client data indicates, for each of the plurality of employees, demographic data that identifies… ii) a forecasted family status of each of a family of the respective employee indicating a forecasted number of family members of the family that will consumer services facilitated by the SaaS management platform” – underline added by Examiner for emphasis.
Respectfully, Examiner notes the intended meaning of the aforementioned clause is not clear. The underlined portions highlight major issues to a person of ordinary skill in the art who necessarily must attempt to decipher the scope of subject matter claimed. Respectfully, it is not clear what is meant by “family members of the family that will consumer services” – this seems to be nonsensical. Similarly, it is not clear what “each of a family of the respective employee” means – e.g. does this mean a person has multiple families? If so, is this must be an artifact of different definitions; e.g. a family as defined legally by a state entity, or a family as defined by a different set of rules, as opposed to a family as genetically related, etc…
For the purpose of compact prosecution, the Examiner interprets the features in question commensurate with the state of the prior art teaching regarding collection and receipt of demographic data of clients. Nonetheless, correction or clarification is required.
Additionally, claim 23 has been amended to recite the following: “…The method of claim 11, wherein the external factor data comprises one or more of economic data related to one or more economic indicators, or world event data related to one or more events external to the first candidate third-party service provider and the client organization.”
However, respectfully, independent claim 11, from which claim 23 depends, has already been amended to recite a limitation regarding what the “external factor data” comprises – i.e. claim 11 recites: “…wherein the external factor data identifies sector data that describes characteristics of an industry of the first candidate third-party service provider”. Therefore, it is now not clear whether this “external factor data” as recited in dependent claim 23 comprises different data than as already claimed per the parent claim 11, or whether the description provided in parent claim 11 is somehow intended to be merely a generality of the now recited “one or more of economic data related to one or more economic indicators, or world event data related to one or more events external to the first candidate third-party service provider and the client organization.”, or, whether claim 23 is intended to be additional data which is also considered “external factor data”, or something else entirely.
Therefore, because the scope of the claim is unclear, claim 23 is considered indefinite.
Dependent claims 12-16, 18-23, 26-30, and 32-36 inherit the deficiencies of their parent claim and are also rejected under 35 U.S.C. 112(b) or (for pre-AIA ) 35 U.S.C. 112, second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor, a joint inventor, or (for pre-AIA ) the applicant regards as the invention.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 11, 12, 14, 16, 18-23, 25-26, 28, 30, 32-36 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea (i.e. a judicial exception) without significantly more.
Per step 1 of the 2019 Revised Patent Subject Matter Eligibility Guidance, 84 Fed. Reg. 50 (Jan. 7, 2019) (“Guidance”), further enumerated in MPEP 2106, the claims are directed towards a process, machine, or manufacture.
Per step 2A Prong One, the claims recite specific limitations which fall within at least one of the groupings of abstract ideas enumerated in MPEP 2106, as follows:
Per Independent claims 11 and 25:
“generating…, one or more outputs identifying (i) the first candidate third-party service provider, and (ii) a level of confidence that the first service of the first candidate third-party service provider is suitable for the client organization.”
responsive to determining that the level of confidence satisfies a threshold level of confidence that the first service of the first candidate third-party service provider is suitable for the client organization,
generating information indicating a comparison between the client preference data of the client organization and one or more characteristics of the first service provided by the first candidate third-party service provider, and
generating a notification comprising (i) a first indication identifying the first candidate third-party service provider, and (ii) a second indication identifying the information indicating the comparison between the client preference data and the one or more characteristics of the first service provided by the first candidate third-party service provider
As noted supra, these limitations fall within at least one of the groupings of abstract ideas enumerated in MPEP 2106. Specifically, these limitations fall within a combination of the groups Mathematical Concepts (e.g. mathematical relationships; mathematical formulas or equations; mathematical calculations) and Certain Methods Of Organizing Human Activity (e.g. fundamental economic principles or practices (including hedging, insurance, mitigating risk); commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations); managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions).
That is, this generating steps as drafted, are business decisions to apply business criteria in matching or otherwise identifying a third-party service provider deemed suitable to provide a service which the business believes is a match for a client organization and then notifying a customer and/or suitable service providers of the identified match and applicable criteria comparing the client’s preferences with attributes/characteristics of the matched service provider(s) (which is a marketing/sales activity and type of business relationship activity) and thus these feature falls within the grouping of Certain Methods of Organizing Human Activity. Furthermore, the feature directed towards determining that the level of confidence satisfies a threshold level of confidence is also either a business decision or a just a simple mathematical concept – i.e. comparison to arbitrary threshold value. Note, that there is no particular technique employed, nor recited, by which to discern which third-party service provider is a match for a client organization; instead, an undisclosed “AI model” is referenced as performing this function. However, reciting that an existing but generically disclosed trained AI model performs the step, does not constitute a specific nor a particular technique and at this high level of generality is akin to stating a machine performs the function. Furthermore, the mere nominal recitation of generic computer/hardware implementing some generic “trained AI model(s)” does not take the claim limitation out of the enumerated grouping; i.e. the decision to “use” an undisclosed (perhaps proprietary) “trained AI model” executing on generic hardware for the purpose of determining this business decision is nothing more than the abstract idea of automating this business decision but without any particular technical solution for doing so. Contrary to Applicant’s assertions (e.g. Spec at [0041]-[0044]), there is no technical solution contemplated nor recited in the present claims nor is there a technical problem being solved. Thus, the claims recite an abstract idea.
Per step 2A Prong 2, the Examiner finds that the judicial exception is not integrated into a practical application. Although there are additional elements, other than those noted supra, recited in the claims, none of these additional element(s) or a combination of elements as recited in the claims apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that it is more than a drafting effort designed to monopolize the exception. As drafted, the claims as a whole merely describe how to generally “apply” the aforementioned concepts and link them to a field of use (i.e. in this case market segmentation for the purpose of providing software as a service to appropriate/interested customers) or serve as insignificant extra-solution activity (e.g. transfer of data to/from an undisclosed “AI model”). The claimed computer components are recited at a high level of generality and are merely invoked as tools to implement the idea but are not technical in nature. Simply implementing the abstract idea on or with generic computer components is not a practical application of the abstract idea.
These additional limitations, exemplified in the limitations of claim 11 merely amount to a description that the generic AI model is fed three different “inputs” and a description of the input. However, no further explanation is recited (nor contemplated in the original disclosure) of the inner-working of the supposedly “trained AI model”. These additional limitations, exemplified in limitations of claim 11 are as follows:
PNG
media_image1.png
644
506
media_image1.png
Greyscale
However, these elements do not present a technical solution to a technical problem; i.e. Applicant’s invention is not a technique nor technical solution for “receiving” client data and requests regardless of the intended meaning of the data, nor is it a technique of “providing” (i.e. transferring data) to a “trained AI model” regardless of what the description of such input data is intended to represent and regardless of the number of times data is being provided to such a model. Furthermore, the use of an “account” and descriptions of associations between entities and devices is not technical in nature (at least not at this very high-level of generality) and does not appear to be applicant’s invention. Instead, associations between data, as may be stored in or in association with a generic account, are taken as insignificant pre-solution or extra-solution activity (e.g. data-storage and gathering) as regards the identified abstract idea. The additional elements do not recite a specific manner of performing any of the steps core to the already identified abstract idea. No insight is provided regarding the “AI model”. Instead, a “trained AI model” is recited as a wish for accomplishing the claimed “output”; such wishes are abstract. These features merely serve to generally “apply” the aforementioned concepts within the framework of an already pre-existing and undisclosed “AI model” and/or link them to a field of use (i.e. market segmentation for the purpose of providing software as a service to appropriate/interested customers) or are insignificant extra-solution activity (e.g. data transfer as “inputs”, etc…) to the already identified abstract idea and do not integrate the abstract idea into a practical application thereof.
Per Step 2B, the Examiner does not find that the claims provide an inventive concept, i.e., the claims do not recite additional element(s) or a combination of elements that amount to significantly more than the judicial exception recited in the claim. As discussed with respect to Step 2A Prong Two, the additional elements in the independent claims were considered as merely serving to generally “apply” the aforementioned concepts via generically described computer components (e.g. a memory; and one or more processing devices coupled to the memory, the one or more processing devices configured to perform operations) and “link” them to a field of use (i.e. market segmentation for the purpose of providing software as a service to appropriate/interested customers), or as insignificant extra-solution activity. For the same reason these elements are not sufficient to provide an inventive concept; i.e. the same analysis applies here in 2B. Mere instructions to apply an exception using a generic computer component and conventional data gathering cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. So, upon revaluating here in step 2B, these elements are determined to amount to no more than mere instructions to apply the exception using generic computer components (i.e. a server) and/or gather and transmit data which is well-understood, routine, conventional activity in the field; i.e. note the Symantec, TLI, and OIP Techs Court decisions cited in MPEP 2106.05(d)(ll) indicate that mere receipt or transmission of data over a network is a well-understood, routine, and conventional function when it is claimed in a merely generic manner (as it is here).
Accordingly, alone and in combination, these elements do not integrate the abstract idea into a practical application, as found supra, nor provide an inventive concept, and thus the claims are not patent eligible.
As for the dependent claims, the dependent claims do recite a combination of additional elements. However, these claims as a whole, considered either independently or in combination with the parent claims, do not integrate the identified abstract idea into a practical application thereof nor do they provide an inventive concept.
For example, dependent claims 12 and 26 recite the following: “providing the notification identifying the first candidate third-party service provider and the information indicating the comparison between the client preference data of the client organization and the one or more characteristics of the first service provided by the first candidate third-party service provider.” However, providing information such as a notification is nothing more than insignificant extra-solution activity (data transfer and presentation) and is not significantly more than the already identified abstract idea. This is similar to a marketing manager informing his/her sales director of their research and findings and this cannot be considered significantly more than the already identified abstract idea.
Therefore, the Examiner does not find that these additional claim limitations integrate the abstract idea into a practical application nor provide an inventive concept. Instead, these limitations, as a whole and in combination with the already recited claim elements of the parent claims, are not significantly more than the already identified abstract idea. A similar finding is found for the remaining dependent claims.
For these reasons, the claims are not found to include additional elements that are sufficient to amount to significantly more than the judicial exception and are therefore patent ineligible.
Please see the MPEP 2106 and 2019 Revised Patent Subject Matter Eligibility Guidance published in the Federal Register (84 FR 50) on January 7, 2019 (found at http://www.uspto.gov/patent/laws-and-regulations/examination-policy/examination-guidance-and-training-materials).
Claim Rejections - 35 USC § 103 (AIA )
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or non-obviousness.
Claims 11-16, 18-23, 25-30, and 32-36 are rejected under 35 U.S.C. 103 as obvious over Kumar et al. (US 10,600,105 B1; hereinafter, "Kumar") in view of Gainor (U.S. 2023/0334457 A1; hereinafter, "Gainor") and Harmon (US 8,725,603 B1; hereinafter, “Harmon”).
Claims 11 and 25 (Currently amended)
Pertaining to claims 11 and 25 exemplified in the limitations of method claim 11, Kumar as shown teaches the following:
A method comprising:
receiving, by a software-as-a-service (SaaS) management platform and from one or more client devices associated with a client organization, a request for one or more services facilitated by the SaaS management platform and provided by one or more third party service providers (Kumar, see at least Figs. 1, 4A [a request form filled out by a client], [12:26-29]: “…a customer can enter a request for a specific service on the service provider matching system 102 (for example, in the example user interface depicted in FIG. 4A)…”; and [27:15-26], e.g.: “…In entry area 402, a customer can enter [i.e. from one or more client devices] the type of service to request… Services can include any type of service that service providers using the platform choose to offer...”; Per [39:19-43:52] services managed by the platform include SaaS, as follows: “…there is provided a service provider referral service [SaaS management platform] for any kind of service industry [services facilitated by the SaaS management platform]… the service provider referral services may be targeted to one or more specific subsets or types of services… other services may include:… management of companies and enterprise services… computer software services [SaaS]…”; i.e. Kumar’s customer [client organization] is associated with Kumar’s platform and Kumar’s platform is a platform which manages enterprise services including computer software services also known as ‘software as a service’ [SaaS]; note also [8:22-35] and [18:44-55], teaching: “customer system(s) 140 can include one or more computers, cell phones, tablets, a combination of devices…”
PNG
media_image2.png
520
698
media_image2.png
Greyscale
), wherein the request identifies client preference data pertaining to the one or more services (Kumar, see citations noted supra, e.g. per at least Fig. 4a #414, client request can identify a preference for a service provider to have a particular certification, a preference for the service to be provided by ‘July 8, 2019’, etc…), wherein the client organization is associated with an account of the SaaS management platform (Kumar, see citations noted supra, including again Fig. 4a and also at least [13:15-30] and [14:45-65], e.g.: “b. User Provider Data and Preferences: …the user data and preferences 118 can include data related to customers [client organizations] or users, such as one or more of the following: account login information [an account of the SaaS management platform]… the user data and preferences 118 can include preferences related to customers or users, such as one or more of the following: preferred gender of service providers (this can be limited to select services, for example), preferred financing options, contract and contract terms preferences…”), and
[…];
providing to a trained AI model a first input, the first input comprising information identifying client data related to the client organization (Kumar, see at least Fig. 1 and related disclosures regarding “Service Provider Matching Engine 101” and see at least [5:48-6:47] and [15:44-56], and [16:16-58], teaching e.g.: “…the machine learning component 120 can implement machine learning algorithms or AI to generate matching models that are executed by the service provider matching engine 101. The machine learning models can be used to identify service providers [first third-party service provider] and/or customers [client organizations] and match the customers [client organizations] with service providers [service providers] based on… user [client organization] data [first input] and preferences 118,… service provider data and preferences 116 [second input], … user search criteria 122, or other relevant information [third input]…”), […];
providing to the trained AI model a second input, the second input comprising information identifying service provider data related to a first candidate third-party service provider that is a first candidate to provide a first service to the client organization (Kumar, see citations noted supra, e.g. at least Fig. 1 and related disclosures regarding “Service Provider Matching Engine 101” and see at least [5:48-6:47] and [15:44-56], and [16:16-58], teaching e.g.: “…the machine learning component 120 can implement machine learning algorithms or AI to generate matching models that are executed by the service provider matching engine 101. The machine learning models can be used to identify service providers [first candidate third-party service provider] and/or customers [client organizations] and match the customers [client organizations] with service providers [service providers] based on… user [client organization] data [first input] and preferences 118,… service provider data and preferences 116 [second input], … user search criteria 122, or other relevant information [e.g. other input, such as third input]…”)
providing to the trained AI model a third input, the third input comprising external factor data identifying one or more factors external to and that affect the client organization and the first third-party service provider (Kumar, see citations noted supra, e.g at least Fig. 1 and related disclosures regarding “Service Provider Matching Engine 101” and see at least [5:48-6:47] and [15:44-56], and [16:16-58], teaching e.g.: “…the machine learning component 120 can implement machine learning algorithms or AI to generate matching models that are executed by the service provider matching engine 101. The machine learning models can be used to identify service providers [first third-party service provider] and/or customers [client organizations] and match the customers [client organizations] with service providers [service providers] based on… other relevant information [third input]…” Note that because the service provider and the client are matched based on this “other relevant information” such info affects both the client and the service provider.), wherein the external factor data identifies sector data that describes characteristics of an industry of the first candidate third-party service provider (Kumar may not explicitly teach, in a single embodiment, that his “other relevant information” [external factor data] is his client’s requested “type of service” [data which identifies sector data that describes characteristics of an industry of a candidate service provider], e.g. as depicted per Fig. 4a and [14:45-65], or his service provider’s specified “type of service offered” [also data which identifies sector data that describes characteristics of an industry of a candidate service provider], e.g. as noted per [14:4-30].
However, because Kumar teaches, e.g. per at least Fig. 4a, [12:8-35], and [16:16-60] a client can enter a request for a service associated with a particular industry, i.e. his requested “Type of Service” [sector data that describes characteristics of an industry of the candidate service provider], such as “plumbing”, and information contained in the client’s request is analyzed by machine learning component 120, including AI algorithms, which is used to match the client request with applicable service provider attributes including specified “types of services offered” [sector data that describes characteristics of an industry of the candidate service provider], which is used to calculate a matching score for the client with a service provider, the Examiner finds there is motivation to include in Kumar’s “other relevant information” [third input], Kumar’s client’s specified “type of service” requested and/or Kumar’s service provider’s specified “type of services offered” because this type of data is readily understood as being useful to match client requests with the abilities of services providers.
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have modified Kumar’s system/method to input into his machine learning component 120, which uses AI algorithms, his client’s requested “Type of Service” and/or service provider specified “types of services offered” as a type of Kumar’s “other relevant information” [third input], by which Kumar teaches his match of his customers [client organizations] with service providers [service providers] may be made because per MPEP 2143(I) (G) Some teaching, suggestion, or motivation in the prior art that would have led one of ordinary skill to modify the prior art reference teachings to arrive at the claimed invention is obvious. The motivation may be implicit and may be found in the knowledge of one of ordinary skill in the art, or, in some cases, from the nature of the problem to be solved. Id. at 1366, 80 USPQ2d at 1649.); and
generating by the trained AI model, one or more outputs identifying (i) the first candidate third-party service provider, and (ii) a level of confidence that the first service of the first candidate third-party service provider is suitable for the client organization (Kumar, again see citations noted supra, e.g. at least [15:44-56], e.g.: “…The machine learning models can be used to identify [generate outputs identifying] service providers [ (i) the first cadidate third-party service provider] and/or customers [clients] and match [a level of confidence of suitability] the customers [client organizations] with service providers [the first candidate third-party service provider]…”; see again [4:15-50] and [6:20-25], e.g.: “…calculate a matching score [level of confidence that the first service of the first candidate third-party service provider is suitable for the client organization] for each service provider [third-party service provider] in the set of service providers…” and “…the set of recommended service providers determined based at least in part on the calculated matching scores; causing display, via the user interface, of an interactive result set based at least in part on the set of recommended service providers, the interactive result set being determined and sorted based at least in part on the calculated matching scores…”).
responsive to determining that the level of confidence satisfies a threshold level of confidence that the first service of the first candidate third-party service provider is suitable for the client organization (Kumar, see citations noted supra, including also at least [16:16-60]: “…Based on a threshold value, the service providers with a matching score above the threshold can be presented to a customer for selection. In some embodiments, the matching scores can be based on various base scores calculated based on a comparison between individual attributes associated with a customer request and corresponding attributes associated with a service provider,…”),
generating information indicating a comparison between the client preference data of the client organization and one or more characteristics of the first service provided by the first candidate third-party service provider (Kumar, see citations noted supra, e.g. again per [16:16-60]: “…scores can be based on various base scores calculated based on a comparison between individual attributes associated with a customer request and corresponding attributes associated with a service provider, which may then be normalized and/or otherwise adjusted, such as to assign respective weights to individual data fields based on likely importance to the customer. For example, a service provider matching system can compare a requested service (for example, beginner guitar lessons) with a service offered by a particular service provider (for example, advanced guitar lessons) to calculate a base score for that comparison…”), and
generating a notification comprising (i) a first indication identifying the first candidate third-party service provider, and (ii) a second indication identifying the information indicating the comparison between the client preference data and the one or more characteristics of the first service provided by the first candidate third-party service provider (Kumar, see citations noted supra, including again at least Fig. 4b and [28:35-60], e.g.: “…Turning now to FIG. 4B, FIG. 4B illustrates a listing 440 of matched service providers based on the service request 400 submitted in FIG. 4A. The listing 440 can include service providers that match the customer's request within a certain threshold determined by the service provider matching system. FIG. 4 shows three matches 442A, 442B, 442C. The matches 442A, 442B, 442C include relevant information about the corresponding matched service providers…”
PNG
media_image3.png
584
724
media_image3.png
Greyscale
Although Kumar teaches the above limitations including associating a customer [client] with a “customer system 140” which may can comprise multiple systems [one or more client devices], and Kumar teaches, per e.g. [14:45-65] that his customer [client] may provide data relating to “…contact information of people [employees] that may be overseeing any work done (if any)…”, he may not explicitly teach associating these people [employees] with the customer’s “customer system 140” [client device(s)]. However, regarding this nuance, Kumar in view of Gainor teach the following:
wherein each of the one or more client devices is associated with at least one of a plurality of employees of the client organization (Gainor, see at least [0039], teaching, e.g.: “…The service request processor 218 may process one or more service requests that can be received from the POS 250 or user devices [client devices] that are associated with the subscriber's employees [employees of the client organization]. One functionality of the service request processor 218 may be to verify the source of the service request. For example, the service request processor 218 may parse the parameters of the received service request and use the parsed parameters, such as an identification of the user device 260, to verify whether the device identification is associated with a particular subscription…”)
Therefore, the Examiner understands that the limitation in question is merely applying a known technique of Gainor (directed towards techniques where “user devices… are associated with the subscriber's employees”; i.e. each client device of a subscriber [client organization] may be associated with one or more employees of the subscriber [client organization]) is applicable to a known base device/method of Kumar (already directed towards known system/methods of matching service providers to subscribers customers [client organizations]) to yield predictable results. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply the techniques of Gainor to the device/method of Kumar such that Kumar’s “customer system 140” [client device(s)] are also associated with one or more of the “people [employees] that may be overseeing any work done” for his customer with motivation as provided by Gainor – i.e. for the purpose of verifying the source, i.e. which subscriber/subscription, is associated with a service request, and because Gainor is pertinent to the subscription services of Kumar and because according to MPEP 2143(I) (C) and/or (D), the use of known technique to improve a known device, methods, or products in the same way (or which is ready for improvement) is obvious.
Although Kumar teaches the above limitations upon which these features depend, including collection of various customer [client] data (e.g. Kumar Abstract, etc…), Kumar may not explicitly teach collection of the specific demographic data as recited below. However, regarding this feature, Kumar in view of Harman teaches the following:
wherein the client data indicates, for each of the plurality of employees, demographic data that identifies i) an age of each of a respective employee, and ii) a forecasted family status of a family of the respective employee indicating a forecasted number of family members of the family that will consumer services facilitated by the SaaS management platform (See 112(b) rejection guiding claim interpretation. Harmon, see at least [4:50-65], teaching, e.g.: “…databases 116 may store different collections of data for an employee, depending on the degree to which the employee is able to manage her paycheck via tool 102. More specifically, a provider of tool 102 (e.g., the employee's employer, an online service provider) may limit the employee's ability to manage or optimize her paycheck to some subset of the deductions or disbursements taken from her paycheck.…information that may be stored by facilitator 110 and/or used by tool 102 includes, but is not limited to, …demographic (e.g., marital status [a family status], age [employee age], address, family size [another family status demographic]); payroll (e.g., gross pay, deductions); family income (e.g., total household income); childcare/education (e.g., expenses for childcare and/or education); contributions (e.g., charitable contributions); employer stock participation (e.g., employee stock participation plan); bank accounts (e.g., direct deposit details, bank account numbers); housing (e.g., rent, mortgage); retirement (e.g., 401K, Individual Retirement Account); health benefits (e.g., plans for which she is eligible, the plan she is currently subscribed to); insurance other than health (e.g., car insurance, life insurance); investments (e.g., stocks, bonds, annuities); etc….”)
Therefore, the Examiner understands that the limitation in question is merely applying a known technique of Harmon (directed towards collection of particular pieces of demographic data of employees which is useful to service providers providing services to employees of a client of the service provider) which is applicable to a known base device/method of Kumar (already directed towards device/method which collects both customer [client] data as well as service provider data, e.g. as noted per at least the Abstract) to yield predictable results. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply the techniques of Harmon to the device/method of Kumar in order to perform the specific limitation in question because Kumar and Harmon are analogous art in the same field of endeavor (at least G06Q 30/02 and/or G06Q 40/02) and because according to MPEP 2143(I) (C) and/or (D), the use of known technique to improve a known device, methods, or products in the same way (or which is ready for improvement) is obvious.
Claims 12 and 26 (Currently amended)
Kumar/Gainor/Harmon teaches the limitations upon which these claims depend. Furthermore, as shown, Kumar teaches the following:
…providing the notification identifying the first candidate third-party service provider and the information indicating the comparison between the client preference data of the client organization and the one or more characteristics of the first service provided by the first candidate third-party service provider (Kumar, see citations noted supra, e.g. again at least Fig. 4b and also at least [4:29-42] teaching: “…the set of recommended service providers determined based at least in part on the calculated matching scores; causing display [a notification], via the user interface, of an interactive result set based at least in part on the set of recommended service providers, the interactive result set being determined and sorted based at least in part on the calculated matching scores…”; see also at least [32:1-30], teaching e.g.: “…Notification Module In some embodiments, an alert and/or notification can automatically be transmitted to a user device based on interactions with the service provider matching system (for example, service provider matching system 102)… the application may be automatically activated when the user device is online such that the alert and/or notification is displayed…”).
Claims 14 and 28 (Currently amended)
Kumar/Gainor/Harmon teaches the limitations upon which these claims depend. Furthermore, as shown, Kumar teaches the following:
…providing to the trained AI model a fourth input, the fourth input comprising information identifying third-party service provider data related to a second candidate third-party service provider that is a second candidate to provide a second service to the client organization; and wherein the one or more outputs identifying (iii) the second candidate third-party service provider, and (iv) a level of confidence that the second service of the second candidate third-party service provider is suitable for the client organization (Kumar, see citations noted supra, including again at least Fig. 4b – depicting second candidate third party service providers who are deemed suitable per match score exceeding a threshold as already noted supra. Note again also at least [16:16-60], input regarding preferences, etc… of multiple service providers [including second and third service providers] are input to Kumar’s machine learning AI model hosted by his platform [SaaS management platform] each service provider provides services to customers [client organizations] associated with Kumar’s platform and the platform outputs a list identifying services providers [including a second service providers] and a match score [a level of confidence] for each individual service provider [second service providers]; e.g. note again per [6:20-25], e.g.: “…calculate a matching score [level of confidence that the first third-party service provider is a match for the client organization] for each service provider [service provider] in the set of service providers…” and as noted per [167:16-58]: “…Based on a threshold value, the service providers with a matching score above the threshold can be presented [providing the notification identifying first and second service providers… responsive to match exceeding threshold] to a customer for selection…”).
Claims 16 and 30 (previously presented)
Kumar/Gainor/Harmon teaches the limitations upon which these claims depend. Furthermore, as shown, Kumar teaches the following:
…wherein the client organization data comprises organization data reflecting information that describes the client organization (Kumar, see citations noted supra including exemplary customer information provided via Fig. 4A as well as [14:45-15:23] detailing exemplary customer data including data describing the customer.)
Claims 18 and 32 (Currently amended)
Kumar/Gainor/Harmon teaches the limitations upon which these claims depend. Furthermore, as shown, Kumar teaches the following:
…wherein the client organization data comprises benefits usage data reflecting a historical usage of the one or more services facilitated by the SaaS management platform by the client organization and provided by a previous third third-party service provider (Kumar, see citations noted supra, in view of at least [10:9-54] discussing third party insurance for a previously contracted service can be offered and accepted by a customer. Also, referrals of customers are known and fees may be paid to third parties based on third party referrals, etc…; Applicant’s “benefits usage data” which is “reflecting” a historical usage of the service by a customer/client organization and provided by a third party/third-party service provider is not defined in the specification and is therefore open to the full breadth of plain language interpretation and reads on the aforementioned teachings of Kumar.)
Claims 19 and 33 (Currently amended)
Kumar/Gainor/Harmon teaches the limitations upon which these claims depend. Furthermore, as shown, Kumar teaches the following:
…wherein the client organization data comprises the client preference data, wherein the client preference data reflects one or more preferences of the client organization pertaining to the one or more services facilitated by the SaaS management platform (Kumar, see citations noted supra including exemplary customer information provided via Fig. 4A as well as [14:45-15:23] detailing exemplary customer data including e.g.: “…the user data and
preferences 118 can include preferences related to customers or users, such as one or more of the following: preferred gender of service providers (this can be limited to select services, for example), preferred financing options, contract and contract terms preferences, preferred geographic area to select service providers based on (so that the service provider does not need to travel a far distance and risk delaying a booked service, for example), preferred times for services to be performed (this can be set by location as well, for example), or the like…”)
Claims 20 and 34 (Currently amended)
Kumar/Gainor/Harmon teaches the limitations upon which these claims depend. Furthermore, as shown, Kumar teaches the following:
…wherein the third-party service provider data comprises benefits data reflecting information pertaining to the first service provided by the first candidate third-party service provider (Kumar, see citations noted supra including exemplary service provider information provided via Fig. 4B as well as [14:6-44] teaching: “…the service provider matching engine 101 includes service provider data and preferences 116. In some embodiments, the service provider data and preferences 116 can include data related to service providers, such as one or more of the following: types of services offered, …what services each employee can perform,… insurance information,… financing options…”; each element may be considered a benefit by a customer/client organization); furthermore, see also [30:30-50] teaching: “… The contractor [service provider/third-party service provider] information may include services offered, licenses, insurance, contractor location, credit history, or the like. In some embodiments, the contractor may further offer to provide either hourly rate based services, or fixed rate services and can offer a discount schedule [specific type of monetary benefit pertaining to the service provided] based on time or location. The contractor information is cataloged at step 502…”)
Claims 21 and 35 (Currently amended)
Kumar/Gainor/Harmon teaches the limitations upon which these claims depend. Furthermore, as shown, Kumar teaches the following:
…wherein the third-party service provider data comprises trend data reflecting information pertaining to cost trends for the first service provided by the first candidate third-party service provider (Kumar, see citations noted supra including [11:50-58], e.g.: “…bids can include just a cost estimate. In some embodiments, bids can include itemized listing of costs and/or an example invoice for the requested service. A customer can then either accept or reject the bid. In some embodiments, information associated with the request for a service and bids can be stored in the data store 114…”).
Claims 22 and 36 (Currently amended)
Kumar/Gainor/Harmon teaches the limitations upon which these claims depend. Furthermore, as shown, Kumar teaches the following:
…wherein the third-party service provider data comprises relationship data reflecting information pertaining to a relationship between the first candidate third-party service provider and the SaaS management platform (Kumar, see citations noted supra, including also at least [12:47-58], e.g.: “…the crime monitoring data can be used to limit or block access to the service provider matching system 102 by the customer system(s) 140 and/or service provider system(s) 130 depending on the crime monitoring data. For example, if an employee of a service provider is found guilty of robbery or another serious crime, access to the platform can be limited for the service provider until it is shown that the employee is no longer employed by the service provider. In some embodiments, if a service provider has been found involved, directly or indirectly, in any criminal activity then the service provider can be blocked from accessing or using the service provider matching system…”)
Claim 23 (Currently amended)
Kumar/Gainor/Harmon teaches the limitations upon which these claims depend. Furthermore, as shown, Kumar teaches the following:
The method of claim 11, wherein the external factor data comprises one or more of economic data related to one or more economic indicators, or world event data related to one or more events external to the first candidate third-party service provider and the client organization (Note 112(b) rejection guiding claim interpretation. Kumar, see citations noted supra including at least [12:36-13:14], e.g.: “…5. Crime Monitoring Engine: In some embodiments, the service provider matching system 102 includes a crime monitoring engine 112. The crime monitoring engine 112 can be configured to receive or retrieve relevant crime data [external factor data related to one or more economic indicators] related to particular addresses, customers, or service providers…”)
Response to Arguments
Applicant canceled Claims 1-10, 13, 15, 17, 24, 27, 29, 31 and amended Claims 111, 12, 14, 18-23, 25-26, 28, 32-36 on 10/30/2025. Applicant's arguments (hereinafter “Remarks”) also filed 10/30/2025, have been fully considered but are moot in view of the new grounds of rejection necessitated by applicant’s amendments. Note the new 35 USC 101, 112, and 103 rejections in view of Kumar in view of Gainor and Harmon.
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).
The following prior art is made of record although not relied upon as it is considered pertinent to applicant's disclosure:
US Publication 2023/0191263 A1 to Cella et al. discusses a “smart contract system programmed with smart contract services” which includes “an intelligent matching system” disclosed as being able to recommend services including AI models and teaches: per [3094]: “The methods and systems described herein may be adapted for use with any kind of private, community, or hybrid cloud computing network or cloud computing environment, including those which involve features of software as a service (SaaS), platform as a service (PaaS), and/or infrastructure as a service (IaaS).”
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL J SITTNER whose telephone number is (571)270-3984. The examiner can normally be reached M-F; ~9:30-6:30. 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, Waseem Ashraf can be reached on (571) 270-3948. 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.
/Michael J Sittner/
Primary Examiner, Art Unit 3621