DETAILED ACTION
This is an office action on the merits in response to the communication filed on 6/3/2024.
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 .
Claims’ Status
Claims 1-13 are pending and are considered in this office action.
Objection
1. The numbering of claims is not in accordance with 37 CFR 1.126 which requires the original numbering of the claims to be preserved throughout the prosecution. When claims are canceled, the remaining claims must not be renumbered. When new claims are presented, they must be numbered consecutively beginning with the number next following the highest numbered claims previously presented (whether entered or not). In this case, between claim 5 and claim 6, there appears another set of claims embedded therebetween, like “1. The method of claim 2, wherein the API interface module employs secure communication protocols, such as HTTPS and OAuth, to ensure secure data transmission between the CRM system and the third-party payment processor; etc.” It is advised that applicant submit a new claim set in the next response to correct the mislabeling. For the purpose of examination, Examiner assumes the intended claim labeling as:
1. A system for enabling third-party payment processing in customer relationship management (CRM) systems, comprising:
an electronic database configured to store transactional data and customer information, including a designated field for tags;
a tag detection module configured to monitor the designated field within the database for the presence of a predefined tag associated with third-party payment processing;
an API interface module configured to establish communication between the CRM system and third-party payment processors upon detection of the predefined tag; and
a transaction initiation module configured to initiate a billing event with the third-party payment processor based on the transactional data and customer information associated with the detected tag.
2. A method for integrating third-party payment processors using the customer relationship management (CRM) system of claim 1 using tag-based triggers, the method comprising the steps of:
monitoring, by a tag detection module, a designated field within a database of the CRM system for the presence of a predefined tag associated with third-party payment processing;
detecting, by the tag detection module, the predefined tag within the designated field;
establishing, by an API interface module, communication between the CRM system and a third-party payment processor upon detection of the predefined tag; and
initiating, by a transaction initiation module, a billing event with the third-party payment processor using transactional data and customer information related to the detected tag.
3. The method of claim 2, further comprising the step of:
updating, by the CRM system, the customer information in the database to reflect the status of the billing event initiated with the third-party payment processor.
4. The method of claim 2, wherein the predefined tag is a unique identifier assigned to specific payment processing actions, enabling the tag detection module to differentiate between multiple third-party payment processors.
5. The method of claim 2, further comprising the step of:
notifying, by a notification module, the customer of the billing event via email or SMS after the billing event is initiated with the third-party payment processor.
6. The method of claim 2, wherein the API interface module employs secure communication protocols, such as HTTPS and OAuth, to ensure secure data transmission between the CRM system and the third-party payment processor.
7. The method of claim 2, further comprising the step of: logging, by a logging module, all communication and billing events with the third-party payment processor for auditing and tracking purposes.
8. The method of claim 2, wherein the transaction initiation module includes error handling mechanisms to retry the billing event initiation in case of a failure in communication with the third-party payment processor.
9. The method of claim 2, further comprising the step of:
generating, by a report generation module, summary reports of all billing events initiated with third-party payment processors, categorized by the predefined tags.
10. A customer relationship management (CRM) system comprising:
an electronic database for storing transactional data and customer information, including a designated field for tags indicating third-party payment processing;
a tag detection module for detecting a predefined tag within the designated field associated with third-party payment processing;
an API communication module for establishing communication with third-party payment processors via an API interface upon detection of the predefined tag; and
a billing event handler module for initiating billing events with the third-party payment processor based on the associated transactional data and customer information.
11. A method for triggering billing events with third-party payment processors using the customer relationship management (CRM) system of claim 10, the method comprising:
identifying, in a transactional record within a CRM system, a predefined tag stored in a designated field, where the tag indicates a preference or requirement for third-party payment processing;
communicating, via an API interface module, with a selected third-party payment processor upon identification of the predefined tag; and
initiating, based on the transactional record associated with the identified tag, a billing event with the third-party payment processor, thereby enabling the processing of transactions outside the default payment processing system integrated into the CRM system.
12. The method of claim 11, further comprising the step of:
updating, by the CRM system, the transactional record to reflect the status of the billing event initiated with the third-party payment processor.
13. The method of claim 11, wherein the predefined tag is a unique identifier that specifies the particular third-party payment processor to be used, allowing the CRM system to communicate with multiple third-party payment processors based on different tags.
14. The method of claim 11, further comprising the step of:
notifying, by a notification module, the customer via email or SMS upon successful initiation of the billing event with the third-party payment processor.
15. The method of claim 11, wherein the API interface module utilizes secure communication protocols, such as HTTPS and OAuth, to ensure the secure transmission of data between the CRM system and the third-party payment processor.
16. The method of claim 11, further comprising the step of:
logging, by a logging module, all communication and billing events with the third-party payment processor for auditing and tracking purposes.
17. The method of claim 11, wherein the step of initiating a billing event includes error handling mechanisms to retry the billing event initiation in case of a communication failure with the third-party payment processor.
18. The method of claim 11, further comprising the step of:
generating, by a report generation module, detailed reports of all billing events initiated with third-party payment processors, categorized by the predefined tags for administrative review and reconciliation.
2. The subject matter of this application admits of illustration by a drawing to facilitate understanding of the invention. Applicant is required to furnish a drawing under 37 CFR 1.81(c). No new matter may be introduced in the required drawing. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). The present invention claims elements “an electronic database”; “a tag detection module”; “an API interface/communication module”; and “a transaction initiation module”; and “a billing event handler module”, however these elements cannot be found in any of the drawings.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-18 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
Step 1 (The Statutory Categories): Is the claim to a process, machine, manufacture or composition of matter? MPEP 2106.03
Per Step 1, Claims 1 and 10 are drawn to system claims; claim 2-9 and 11-18 are drawn to method claims, which are all within the four statutory categories (i.e., a process).
Independent claim 1 recites: (claims 2, 10 and 11 being similar in scope):
Claim 1:
an electronic database configured to store transactional data and customer information, including a designated field for tags;
a tag detection module configured to monitor the designated field within the database for the presence of a predefined tag associated with third-party payment processing;
an API interface module configured to establish communication between the CRM system and third-party payment processors upon detection of the predefined tag; and
a transaction initiation module configured to initiate a billing event with the third-party payment processor based on the transactional data and customer information associated with the detected tag.
Step 2A Prong 1: Does the claim recite an abstract idea, law of nature, or natural phenomenon? MPEP 2106.04
The limitations, as drafted, constitute a process that, under its broadest reasonable interpretation, covers managing commercial transaction under the Certain methods of organizing human activity, but for the recitation of generic computer components. The abstract idea, recited above, includes: a tag detection module configured to monitor the designated field within the database for the presence of a predefined tag associated with third-party payment processing; a transaction initiation module configured to initiate a billing event with the third-party payment processor based on the transactional data and customer information associated with the detected tag. If a claim limitation, under its broadest reasonable interpretation, covers performance of limitations commercial interactions, but for the recitation of generic computer components, it falls within the Certain Methods of Organizing Human Activity – commercial interactions in the form of contracts, grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Step 2A Prong 2: Does the claim recite additional elements that integrate the judicial exception into a practical application? MPEP 2106.04.
The recited computing elements (claim 1: an electronic database; a tag detection module’ an API interface module; a transaction initiation module; claim 5: a notification module; claim 7: a logging module; claim 10: a billing event handler module; claim 18: a report generation module) are recited at a high-level of generality, i.e. as generic computing element performing generic computer functions such that it amounts to no more than mere instructions to apply the exception using generic computer components (see MPEP 2106.05(f)). Simply adding a general purpose computer or computer components after the fact to an abstract idea does not integrate a judicial exception into a practical application or provide significantly more, since it amounts to no more than a recitation of the words "apply it" (or an equivalent) to implement an abstract idea or other exception on a computer, as set forth in MPEP 2106.05(f).
The other additional positive elements: “an electronic database configured to store transactional data and customer information, including a designated field for tags; an API interface module configured to establish communication between the CRM system and third-party payment processors upon detection of the predefined tag” in claim 1, which amounts to linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.05(h) or simply “applying it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f)
Accordingly, these additional claim elements, alone and in combination do not integrate the abstract idea into a practical application, because (1) they do not effect improvements to the functioning of a computer, or to any other technology or technical field (see MPEP 2106.05(a)); (2) they do not apply or use the abstract idea to effect a particular treatment or prophylaxis for a disease or a medical condition (see the Vanda memo); (3) they do not apply the abstract idea with, or by use of, a particular machine (see MPEP 2106.05(b)); (4) they do not effect a transformation or reduction of a particular article to a different state or thing (see MPEP 2106.05(c)); (5) they do not apply or use the abstract idea in some other meaningful way beyond generally linking the use of the identified abstract idea to a particular technological environment, such that the claim as a whole is more than a drafting effort designated to monopolize the exception (see MPEP 2106.05(e) and the Vanda memo). Therefore, per Step 2A, Prong Two, the claim is directed to an abstract idea not integrated into a practical application.
Step 2B (The Inventive Concept): Does the claim recite additional elements that amount to significantly more than the judicial exception? MPEP 2106.05.
Step 2B of the eligibility analysis concludes that the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. Examiner carries over the analysis from Step 2A related to the generic computing elements being no more than a recitation of the words "apply it" (or an equivalent) to implement an abstract idea or other exception on a computer (MPEP 2106.05(f)). The additional claim elements are simply linking the use of the judicial exception to a particular technological environment or field of use” are mere instructions to implement an abstract idea on a computer, are carried over for further analysis in Step 2B.
When the independent claims are considered as a whole, as a combination, the claim elements noted above do not amount to any more than they amount to individually. The operations appear to merely apply the abstract concept to a technical environment in a very general sense, i.e. modules. The most significant elements of the claims, that is the elements that really outline the inventive elements of the claims, are set forth in the elements identified as an abstract idea. Therefore, it is concluded that the elements of the independent claims are directed to one or more abstract ideas and do not amount to significantly more. (MPEP 2106.05)
Further, Step 2B of the analysis takes into consideration all dependent claims as well, both individually and as a whole, as a combination:
Claims 3-9 are further directed to additional abstract ideas because the steps performed are simply narrowing the scope of the abstract idea of claim 1 since their individual and combined significance is still not significantly more than the abstract concept at the core of the claimed invention. For example, claim 3 further describes updating the customer information in the database; claim 4 describes differentiating between multiple third-party payment processors; claim 5 describes notifying the customer of the billing event; claim 6 on ensuring secure data transmission between the CRM and the third-party payment processor; claim 7 on logging billing events; claim 8 on retrying the billing event initiation in case of a failure ; claim 9 on generating summary report on billing events;, which all of the limitation are narrowing the steps performed in claim 1.
Moreover, the claims in the instant application do not constitute significantly more also because the claims or claim elements only serve to implement the abstract idea using computer components to perform computing functions (Enfish, see MPEP 2106.05(a)). The other dependent claims, claim 12-18, are similar in scope to the claim 3-9 are also rejected for the same reasons provided above.
The most significant elements of the claims, that is the elements that really outline the inventive elements of the claims, are set forth in the elements identified in the independent claims as an abstract idea. The fact that the associated computing devices are facilitating the abstract concept is not enough to confer statutory subject matter eligibility. In sum, the additional elements do not serve to confer subject matter eligibility to the invention since their individual and combined significance is still not heavier than the abstract concepts at the core of the claimed invention. Therefore, it is concluded that the dependent claims of the instant application do not amount to significantly more either. (see MPEP 2106.05)
In sum, claims 1-18 are rejected under 35 USC 101 as being directed to non-statutory subject matter.
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.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “an electronic database”; “a tag detection module”; “an API interface module”; and “a transaction initiation module” configured to…. in claim 1; “an electronic database”; “a tag detection module”; “an API communication module”; and “a billing event handler module” configured to…. in claim 10.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend 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 avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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 1 and 10 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. These elements as described above, “an electronic database”; “a tag detection module”; “an API interface module”; “a transaction initiation module” and “a billing event handler module“ in the independent claims invoke 112f. The disclosure does not provide adequate structure to perform the claimed functions of “store transactional data and customer information…..”; “monitor the designated field within the database……”; “establish communication between the CRM system and third-party payment processors…..”; “initiate a billing event with the third-party payment processor…..” The specification does not demonstrate that applicant has not made an invention that achieves the claimed function because the invention is not described, the structure of the claimed generic placeholder, with sufficient detail such that one of ordinary skill in the art can reasonably conclude that the inventor had possession of the claimed invention.
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 1 and 10 are rejected as failing to define the invention and failing to particularly point out and distinctly claim the subject matter in the manner required by 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Claim limitation of generic placeholder such as “an electronic database”; “a tag detection module”; “an API interface module”; “a transaction initiation module”; and “a billing event handler module “ invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. The specification fails to adequately provide structure to perform the claimed function. There is no disclosure of any particular structure, either explicitly or inherently, to perform the functional steps described in claim 1 or 10. As would be recognized by those ordinary skill in the art, the terms “an electronic database”; “a tag detection module”; “an API interface module”; “a transaction initiation module”; and “a billing event handler module“ can be performed in any number of ways in hardware, software or a combination of the two because the specification does not describe particular structure, which is not defined what it is, to perform the function(s). That is, the specification does not provide sufficient details such that one of ordinary skill in the art would understand which the receiving and estimating structure perform the claimed functions. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
Furthermore, regarding claim 6 and 15, the phrase " such as HTTPS and OAuth " renders the claim indefinite because it is unclear whether the limitations following the phrase are part of the claimed invention. See MPEP § 2173.05(d). Corrections are required.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-3, 5, 7, 9, 10-12, 14, 16, and 18 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Schnitt et al. (US20220292465A1)
With respect to claim 1, 2, and 10
Schnitt teaches:
an electronic database configured to store transactional data and customer information, including a designated field for tags ([0005], The multi-service business platform may include a storage system that stores a checkout database. The checkout database may store sets of checkout parameters relating to respective offerings provided by a set of different clients. The multi-service business platform may also include a link generation service that is executed by a set of processors and is configured to receive a set of configuration parameters corresponding to an offering from a client user device associated with a client. The configuration parameters may at least define one or more items offered by the client and a payment amount for the one or more items. A checkout link corresponding to the offering may be generated. The checkout link may include a uniform resource identifier (URI). The set of checkout parameters may be stored in the checkout database. The stored set of checkout parameters may be indexed using a portion of the URI.);
a tag detection module configured to monitor the designated field within the database for the presence of a predefined tag associated with third-party payment processing ([0417], Referring back to FIG. 45, in example embodiments, the multi-service business platform 510 may include an event system 522 that may be configured to monitor for and record the occurrence of events. In example embodiments, the multi-service business platform 510 may include a payment system 524 that processes payments on behalf of clients of the multi-service business platform 510. In example embodiments, the multi-service business platform 510 may include a reporting system 526 that may allow users to create different types of reports using various data sources associated with a client's business (e.g., including data sources corresponding to custom objects defined with respect to the client's business and/or any core objects that are maintained with respect to the client's business).);
an API interface module configured to establish communication between the CRM system and third-party payment processors upon detection of the predefined tag ([0389], The multi-service business platform 510 may support a custom application architecture of a user that may integrate with a payment processing service (e.g., payment system 524) and may connect with the CRM system 502/CMS 508 such that a payment processing service may feed payment data to the CRM system 502 and the CMS 508 of the multi-service business platform 510 in real-time. In example embodiments, the payment system 524 is configured to establish payment sessions for customers with third-party payment processors on behalf of clients of the multi-service business platform 510; see also [0474], In example embodiments, the payment execution service 6424 may initiate payment sessions with a third-party payment processor 6410 on behalf of the client's customers. In example embodiments, the payment execution service 6424 may request a payment session from the third party payment processor 6410. The payment execution service 6424 may request the payment session in response to the selection of the checkout link (e.g., in response to the request provided by the customer device)).; and
a transaction initiation module/billing event handler module configured to initiate a billing event with the third-party payment processor based on the transactional data and customer information associated with the detected tag ([0460], In example embodiments, a checkout page may be a digital medium that is configured using a set of checkout parameters provided by the client and allows a user to initiate a payment for the respective offering that may be defined in the checkout parameters corresponding to the checkout link……. An offering may refer to one or more items (e.g., services, products, warranties, leases, or any combination thereof) that may be offered by the client in exchange for a set payment price.)
With respect to claim 11
Schnitt teaches:
identifying, in a transactional record within a CRM system, a predefined tag stored in a designated field, where the tag indicates a preference or requirement for third-party payment processing ([0005], The multi-service business platform may include a storage system that stores a checkout database. The checkout database may store sets of checkout parameters relating to respective offerings provided by a set of different clients. The multi-service business platform may also include a link generation service that is executed by a set of processors and is configured to receive a set of configuration parameters corresponding to an offering from a client user device associated with a client. The configuration parameters may at least define one or more items offered by the client and a payment amount for the one or more items. A checkout link corresponding to the offering may be generated. The checkout link may include a uniform resource identifier (URI). The set of checkout parameters may be stored in the checkout database. The stored set of checkout parameters may be indexed using a portion of the URI; see also [0417], Referring back to FIG. 45, in example embodiments, the multi-service business platform 510 may include an event system 522 that may be configured to monitor for and record the occurrence of events. In example embodiments, the multi-service business platform 510 may include a payment system 524 that processes payments on behalf of clients of the multi-service business platform 510. In example embodiments, the multi-service business platform 510 may include a reporting system 526 that may allow users to create different types of reports using various data sources associated with a client's business (e.g., including data sources corresponding to custom objects defined with respect to the client's business and/or any core objects that are maintained with respect to the client's business).);
communicating, via an API interface module, with a selected third-party payment processor upon identification of the predefined tag ([0389], The multi-service business platform 510 may support a custom application architecture of a user that may integrate with a payment processing service (e.g., payment system 524) and may connect with the CRM system 502/CMS 508 such that a payment processing service may feed payment data to the CRM system 502 and the CMS 508 of the multi-service business platform 510 in real-time. In example embodiments, the payment system 524 is configured to establish payment sessions for customers with third-party payment processors on behalf of clients of the multi-service business platform 510; see also [0474], In example embodiments, the payment execution service 6424 may initiate payment sessions with a third-party payment processor 6410 on behalf of the client's customers. In example embodiments, the payment execution service 6424 may request a payment session from the third party payment processor 6410. The payment execution service 6424 may request the payment session in response to the selection of the checkout link (e.g., in response to the request provided by the customer device)); and
initiating, based on the transactional record associated with the identified tag, a billing event with the third-party payment processor, thereby enabling the processing of transactions outside the default payment processing system integrated into the CRM system ([0460], In example embodiments, a checkout page may be a digital medium that is configured using a set of checkout parameters provided by the client and allows a user to initiate a payment for the respective offering that may be defined in the checkout parameters corresponding to the checkout link……. An offering may refer to one or more items (e.g., services, products, warranties, leases, or any combination thereof) that may be offered by the client in exchange for a set payment price.).
Examiner’s Note (Intended Use): The portion of the limitation which recites “thereby enabling the processing of transactions outside the default payment processing system integrated into the CRM system” is merely a recited intended use of initiating a billing event step. This portion is given little to no patentable weight because the limitation, or portion thereof, does not claim the function(s) as being positively recited actions or functions, and/or it does not add any meaning or purpose to the associated manipulative step(s). See MPEP 2103 C and 2111.04. Simply because the limitation recites something as being “for…. [performing a specific functionality]”, etc. does not mean that the functions are required to be performed, or are actually performed.
With respect to claim 3 and 12
Schnitt teaches the limitation of claim 2 and 11 respectively. Schnitt further teaches: updating, by the CRM system, the customer information in the database to reflect the status of the billing event initiated with the third-party payment processor ([0014], A payment session may be initiated, by the set of processors, with a third-party payment processor on behalf of the client. Session information may be provided, by the set of processors, for the customer user device associated with the customer. A transaction notification indicating whether the payment was successful or unsuccessful may be received by the set of processors. A payments database may be updated, by the set of processors, based on the transaction notification.)
With respect to claim 5 and 14
Schnitt teaches the limitation of claim 2 and 11 respectively. Schnitt further teaches: notifying, by a notification module, the customer of the billing event via email or SMS after the billing event is initiated with the third-party payment processor ([0005], A payment processing service that is executed by the set of processors may be configured to initiate a payment session with a third-party payment processor on behalf of the client. Session information may be provided for the customer user device associated with the customer. A transaction notification may be received indicating whether the payment was successful or unsuccessful. A post-payment service that is executed by the set of processors may be configured to update a payments database based on the transaction notification. An event notification indicating an outcome indicated by the transaction notification may be generated. A post-transaction workflow corresponding to the outcome may be initiated; see also [0007], In example embodiments, the payment processing service may be further configured to expose a webhook to the third-party payment processor. The third-party payment processor may provide the transaction notification to the multi-service business platform via the webhook.)
With respect to claim 7 and 16
Schnitt teaches the limitation of claim 2 and 11 respectively. Schnitt further teaches: logging, by a logging module, all communication and billing events with the third-party payment processor for auditing and tracking purposes ([0125], In general, a wide range of analytics may be aggregated by topic cluster (such as a core topic and related topics linked to the core topic in the cluster), rather than by web page, so that activities involved in generating the content in the cluster can be attributed with the revenue and other benefits that are generated as a result. Among these are elements tracked in a CRM system 158, such as contact events, customers (such as prospective customers, leads, actual customers, and the like), deals, revenue, profit, and tasks.)
With respect to claim 9 and 18
Schnitt teaches the limitation of claim 2 and 11 respectively. Schnitt further teaches: generating, by a report generation module, summary reports of all billing events initiated with third-party payment processors, categorized by the predefined tags (see [0427-0428].)
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 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 4 , 8, 13, and `7 are rejected under 35 U.S.C 103 as being obvious over Schnitt et al. (US20220292465A1) in view of Gomes et al. (US20200097963A1).
With respect to claim 4 and 13
Schnitt teaches the limitation of claim 2 and 11 respectively. Schnitt doesn’t explicitly disclose, but Gomes teaches: wherein the predefined tag is a unique identifier assigned to specific payment processing actions, enabling the tag detection module to differentiate between multiple third-party payment processors ([0026], The transaction management system 130 may receive the token request. In certain embodiments, the transaction management system 130 includes a rules engine. The rules engine may include regulatory rules, user preferences, merchant rules, business rules, and/or other pre-set rules used to select and/or determine parameters of a token provided to the user device 102, the merchant 108, and/or a device associated with merchant 108. In certain embodiments, the token request may not identify a specific token issuer or payment provider associated with the token. The transaction management system 130 may, from the token request, determine one or more parameters of the token to be generated. Furthermore, the transaction management system 130 may select the specific token issuer or payment provider associated with the token for the generated token.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Gomes with the teaching of Schnitt as they relate to system of managing payment transaction based on selecting a specific payment provider. One of ordinary skill in the art before effective filing date of the claimed invention was made would have modified the CRM system of customizing payments across multi-service business platform in Schnitt to include a method of selecting a specific payment provider as taught by Gomes for the predicated result of increased and improved customizability across the multi-service business platform.
With respect to claim 8 and 17
Schnitt teaches the limitation of claim 2 and 11 respectively. Schnitt doesn’t explicitly disclose, but Gomes teaches: wherein the transaction initiation module includes error handling mechanisms to retry the billing event initiation in case of a failure in communication with the third-party payment processor ([0062], n certain such embodiments, there may be a primary (preferred) routing path and a secondary (fallback) routing path. The secondary routing path may be used if the primary routing path is unresponsive (e.g., a payment attempted through the primary routing path may have failed or data may indicate that the primary routing path is offline) or unacceptably slow (e.g., the predicted payment processing time may be greater than a threshold timeframe).)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Gomes with the teaching of Schnitt as they relate to system of managing payment transaction based on selecting a specific payment provider. One of ordinary skill in the art before effective filing date of the claimed invention was made would have modified the CRM system of customizing payments across multi-service business platform in Schnitt to include a method of retrying another billing event in case of a failure as taught by Gomes for the predicated result of increased and improved customizability across the multi-service business platform.
Claims 6 and 15 are rejected under 35 U.S.C 103 as being obvious over Schnitt et al. (US20220292465A1) in view of Edwards et al. (US20190197533A1).
With respect to claim 6 and 15
Schnitt teaches the limitation of claim 2 and 11 respectively. Schnitt doesn’t explicitly disclose, but Edwards teaches: wherein the API interface module employs secure communication protocols, such as HTTPS and OAuth, to ensure secure data transmission between the CRM system and the third-party payment processor ([0032], In addition, the web service API (discussed below) may implement a client authorization framework—such as OAuth 2.0—for identifying a test transaction request to a particular user or account, granting access to the payment network 21 for processing of the authorized transaction request, and/or tracking a number of test transaction requests processed for a particular user or account. The web service API preferably utilizes enterprise-standard encryption to secure communications.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Edwards with the teaching of Schnitt as they relate to system of managing payment transaction based on selecting a specific payment provider. One of ordinary skill in the art before effective filing date of the claimed invention was made would have modified the CRM system of customizing payments across multi-service business platform in Schnitt to include a system of ensuring secure communication protocols between networks as taught by Edwards for the predicated result of increased and improved customizability across the multi-service business platform.
Conclusion
THIS ACTION IS MADE Non-FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to YIN Y CHOI whose telephone number is (571)272-1094 or yin.choi@uspto.gov. The examiner can normally be reached on M-F 7:30 - 5:30pm EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Neha Patel can be reached on 571-270-1492. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/YIN Y CHOI/Examiner, Art Unit 3699 1/17/2026