DETAILED ACTION
This is an office action on the merits in response to the communication filed on 4/17/2026.
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 19-23 are new claims. Claims 6, 10, and 15 are cancelled. Claims 1 and 11 are amended. Claims 1-5, 7-9, 11-14, and 16-23 are pending and are considered in this office action.
Response to Arguments/Comments
101 Rejection
Applicant argues that the amended claims are not directed to a merely results-oriented commercial preference. They are directed to a specific computer-implemented interoperability technique within a CRM environment. Examiner respectfully disagrees. Under the broadest reasonable interpretation, the amended claims still recite an abstract idea of both 1) managing commercial transaction; 2) Fundamental economic practice. The predefined tag comprising a unique combination of characters, tag triggering the use of an existing CRM API; API automatically initiate a predefined workflow to a third-party existing CRM API; and etc are standard protocols that the banking industry uses to facilitate the financial transactions. The claims fail to add any additional elements that would result in an improvement to technology, financial transaction including using API of a CRM system, or an improvement to a device. Rather the claims recite a business process of verifying information before facilitating a transaction, and “it is important to keep in mind that an improvement in the abstract idea itself (e.g. a recited fundamental economic concept) is not an improvement in technology. For example, in Trading Technologies Int'l V.IBG, 921 F.3d 1084, 1093-94, 2019 USPQ2d 138290 (Fed. Cir. 2019), the court determined that the claimed user interface simply provided a trader with more information to facilitate market trades, which improved the business process of market trading but did not improve computers or technology." MPEP 2106.05(a) (II).
103 Rejection
Applicant’s argument is moot in light of new arts and new grounds of rejection due to amended claims.
Claim Rejections - 35 USC § 112
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 19 and 20 recite the respective limitations of: 1) “wherein the designated field comprises a notes section associated with a customer record of the CRM system“; 2) “wherein the designated field comprises a notes section associated with a transaction record of the CRM system.” There are insufficient antecedent basis for the underlined limitation in the claims. Clarifications are required.
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-5, 7-9, 11-14, and 16-23 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, Claim 1 is are drawn to a system claim; claims 2-5, 7-9, 11-14, and 16-23 are drawn to method claims, which are all within the four statutory categories (i.e., a process).
Independent claim 1 recites: (claims 2 and 11 being similar in scope):
Claim 1:
one or more processors; a communications interface operatively coupled to the one or more processors; and a database storing customer records and transaction records of the CRM system, wherein at least one of the customer records or transaction records includes a designated field comprising a notes section, wherein the one or more processors are configured to:
monitor the designated field for a predefined tag associated with third-party payment processing, the predefined tag comprising a unique combination of characters;
in response to detecting the predefined tag in the designated field, automatically initiate a predefined workflow by using an existing application programming interface (API) of the CRM system, via the communications interface, to send a request to a third-party payment processor specified by the predefined tag, the request including transaction details comprising an amount, a currency, and customer payment information associated with the customer record or transaction record; and
update the customer record or transaction record in the database to reflect a status of a billing event initiated with the third-party payment processor.
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 1) managing commercial transaction; 2) Fundamental economic practice under the Certain methods of organizing human activity, but for the recitation of generic computer components. The abstract idea, recited above, includes: monitor the designated field for a predefined tag associated with third-party payment processing, the predefined tag comprising a unique combination of characters;
update the customer record or transaction record in the database to reflect a status of a billing event initiated with the third-party payment processor.. If a claim limitation, under its broadest reasonable interpretation, covers performance of 1) managing commercial transaction; 2) Fundamental economic practice, but for the recitation of generic computer components, it falls within the Certain Methods of Organizing Human Activity 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: processor; a communication interface; and a database; claim 2: 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: “in response to detecting the predefined tag in the designated field, automatically initiate a predefined workflow by using an existing application programming interface (API) of the CRM system, via the communications interface, to send a request to a third-party payment processor specified by the predefined tag, the request including transaction details comprising an amount, a currency, and customer payment information associated with the customer record or transaction record” 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 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 1-3, 5, 7, 9, 11-12, 14, 16, and 18 are rejected under 35 U.S.C 103 as being obvious over Richter et al. (US20230196308A1) in view of Hogan et al. (US20020035548A1).
With respect to claim 1
Richter teaches:
one or more processors; a communications interface operatively coupled to the one or more processors; and a database storing customer records and transaction records of the CRM system ([0056 and 0072] and fig.1)
the predefined tag comprising a unique combination of characters ([0131], A token may be a randomly generated number, a pseudorandom number, encrypted information, or other character sequences.);
the request including transaction details comprising an amount, a currency, and customer payment information associated with the customer record or transaction record ([0137], In one embodiment, customer payment 907 may have a many-to-many relationship with transaction customer payment 903. In one example embodiment, customer payment 907 may include unique ID (GUID), customer ID (GUID), date added (date/time), amount information, currency (ISO code), settlement Account (GUID), and payment message data, e.g., a blob of actual data from the payment message for future investigation, etc.); update the customer record or transaction record in the database to reflect a status of a billing event initiated with the third-party payment processor ([0161], The authorized third-party service providers may process the aggregated amount (step 2319) and then initiate payment execution for the plurality of transactions (step 2321). The transmitted payments are recorded (step 2323) and then reported to the customer and the merchants (step 2325); [0167], In one embodiment, the aggregated transactions may include transaction ID, merchant ID, customer ID, amount, currency (ISO code), transaction date, transaction status, payment reference, etc. Transaction processing system 109 may transmit the aggregated transactions to the transactional API of the third-party service provider for further processing (step 2507). Transaction processing system 109 may save the received aggregated transactions in database 111 (step 2509).)
Richter doesn’t explicitly disclose, but Hogan teaches:
wherein at least one of the customer records or transaction records includes a designated field comprising a notes section ([0085], When a message about a transaction must be transmitted back to the acquirer or merchant from an issuer, the message is processed by the issuer as it normally would process any transaction message. Since the transaction as known to the issuer includes the “pseudo” acquirer BIN, the “pseudo” acquirer BIN will cause the transaction message to be routed to a service provider facility. At this facility the “real” account number is replaced by the pseudo account number, and the pseudo Acquirer Reference Data is replaced with the original Acquirer Reference Data. The transaction message is then routed to the acquirer, which processes it like any other such transaction message; see also [0033], The pseudo account number has as its BIN a special BIN reserved for pseudo account numbers. The remainder of the pseudo account number is a value that can be translated by the service provider via a table look-up process to the “real” account number.), wherein the one or more processors are configured to:
monitor the designated field for a predefined tag associated with third-party payment processing ([0010], (i) the first payment account number has a BIN code associated with the service provider; see also [0070], When the service provider receives the request, it determines from the issuer BIN whether the account number is really a pseudo account number and, if so, sends the transaction to a special system for processing. This system translates the pseudo account number to the “real” account number using a table-lookup procedure; see also [0067].),
in response to detecting the predefined tag in the designated field, automatically initiate a predefined workflow by using an existing application programming interface (API) of the CRM system, via the communications interface, to send a request to a third-party payment processor specified by the predefined tag ([0067] When an acquirer 18 receives an authorization request message from an Internet merchant 16, it looks up the issuer BIN in its BIN table. In the case of a pseudo account number transaction, the “issuer” will correspond to a service provider-authorized processing facility 10, which will receive the request.; see also [0084], A clearing message is processed essentially in the same manner as an authorization request message. As previously described, the acquirer 18 (because of entries in its BIN table) automatically routes a clearing message using a pseudo account number preferably to the service provider 10 or payment processor.)
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 Richter with the teaching of Hogan as they relate to system of managing payment transaction. One of ordinary skill in the art before effective filing date of the claimed invention was made would have modified the payment transaction system in Richter to include a method of using a predefined tag for third-party payment processing as taught by Hogan for the predicated result of increased and improved customizability across the multi-service business platform.
With respect to claim 2
The combination of Hogan and Richter teaches the limitation of claim 1. Richter further teaches:
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 (The steps in claim 2 are already claimed in claim 1 and the only difference between claim 1 and claim 2 are the additional modules that performed the steps of claim 1, these modules can be found from [0067-0072] of Richter.)
With respect to claim 11
Richter teaches:
the predefined tag comprising a unique combination of characters that specifies a third-party payment processor ([0131], A token may be a randomly generated number, a pseudorandom number, encrypted information, or other character sequences.); and …..that sends transaction details comprising an amount, a currency, and customer payment information associated with the customer record or transaction record to the third-party payment processor ([0137], In one embodiment, customer payment 907 may have a many-to-many relationship with transaction customer payment 903. In one example embodiment, customer payment 907 may include unique ID (GUID), customer ID (GUID), date added (date/time), amount information, currency (ISO code), settlement Account (GUID), and payment message data, e.g., a blob of actual data from the payment message for future investigation, etc.); to initiate a billing event outside a default payment processing system integrated into the CRM system ([0161], The authorized third-party service providers may process the aggregated amount (step 2319) and then initiate payment execution for the plurality of transactions (step 2321). The transmitted payments are recorded (step 2323) and then reported to the customer and the merchants (step 2325); [0167], In one embodiment, the aggregated transactions may include transaction ID, merchant ID, customer ID, amount, currency (ISO code), transaction date, transaction status, payment reference, etc. Transaction processing system 109 may transmit the aggregated transactions to the transactional API of the third-party service provider for further processing (step 2507). Transaction processing system 109 may save the received aggregated transactions in database 111 (step 2509).)
Richter doesn’t explicitly disclose, but Hogan teaches:
identifying, in a designated field comprising a notes section associated with a customer record or transaction record of the CRM system, a predefined tag associated with third-party payment processing ([0085], When a message about a transaction must be transmitted back to the acquirer or merchant from an issuer, the message is processed by the issuer as it normally would process any transaction message. Since the transaction as known to the issuer includes the “pseudo” acquirer BIN, the “pseudo” acquirer BIN will cause the transaction message to be routed to a service provider facility. At this facility the “real” account number is replaced by the pseudo account number, and the pseudo Acquirer Reference Data is replaced with the original Acquirer Reference Data. The transaction message is then routed to the acquirer, which processes it like any other such transaction message; see also [0033], The pseudo account number has as its BIN a special BIN reserved for pseudo account numbers. The remainder of the pseudo account number is a value that can be translated by the service provider via a table look-up process to the “real” account number.), communicating, by using an existing application programming interface (API) of the CRM system, with the third-party payment processor specified by the predefined tag ([0010], (i) the first payment account number has a BIN code associated with the service provider; see also [0070], When the service provider receives the request, it determines from the issuer BIN whether the account number is really a pseudo account number and, if so, sends the transaction to a special system for processing. This system translates the pseudo account number to the “real” account number using a table-lookup procedure; see also [0067].); automatically initiating, in response to identifying the predefined tag and via the existing API, a predefined workflow ([0067] When an acquirer 18 receives an authorization request message from an Internet merchant 16, it looks up the issuer BIN in its BIN table. In the case of a pseudo account number transaction, the “issuer” will correspond to a service provider-authorized processing facility 10, which will receive the request.; see also [0084], A clearing message is processed essentially in the same manner as an authorization request message. As previously described, the acquirer 18 (because of entries in its BIN table) automatically routes a clearing message using a pseudo account number preferably to the service provider 10 or payment processor.)
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 Richter with the teaching of Hogan as they relate to system of managing payment transaction. One of ordinary skill in the art before effective filing date of the claimed invention was made would have modified the payment transaction system in Richter to include a method of using a predefined tag for third-party payment processing as taught by Hogan for the predicated result of increased and improved customizability across the multi-service business platform.
With respect to claim 3 and 12
The combination of Richter and Hogan teaches the limitation of claim 2 and 11 respectively. Hogan 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 ([0161], The authorized third-party service providers may process the aggregated amount (step 2319) and then initiate payment execution for the plurality of transactions (step 2321). The transmitted payments are recorded (step 2323) and then reported to the customer and the merchants (step 2325); [0167], In one embodiment, the aggregated transactions may include transaction ID, merchant ID, customer ID, amount, currency (ISO code), transaction date, transaction status, payment reference, etc. Transaction processing system 109 may transmit the aggregated transactions to the transactional API of the third-party service provider for further processing (step 2507). Transaction processing system 109 may save the received aggregated transactions in database 111 (step 2509).)
With respect to claim 5 and 14
The combination of Richter and Hogan teaches the limitation of claim 2 and 11 respectively. Richter 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 (see [0164])
With respect to claim 7 and 16
The combination of Richter and Hogan teaches the limitation of claim 2 and 11 respectively. Richter further teaches: logging, by a logging module, all communication and billing events with the third-party payment processor for auditing and tracking purposes (see [0095].)
With respect to claim 9 and 18
The combination of Richter and Hogan teaches the limitation of claim 2 and 11 respectively. Richter 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 ([0164] describes a list of events interacting with the third-party service provider)
Claims 4, 8, 13, and 17 are rejected under 35 U.S.C 103 as being obvious over Richter et al. (US20230196308A1) in view of Hogan et al. (US20020035548A1) in view of Gomes et al. (US20200097963A1).
With respect to claim 4 and 13
The combination of Richter and Hogan teaches the limitation of claim 2 and 11 respectively. The combination 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 Richter/Hogan as they relate to system of managing payment transaction. One of ordinary skill in the art before effective filing date of the claimed invention was made would have modified the combined systems of Richter/Hogan, for example the payment transaction system in Richter, 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
The combination of Richter and Hogan teaches the limitation of claim 2 and 11 respectively. The combination 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 Richter/Hogan as they relate to system of managing payment transaction. One of ordinary skill in the art before effective filing date of the claimed invention was made would have modified combined systems of Richter/Hogan, for example the payment transaction system in Richter, 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 19-21 are rejected under 35 U.S.C 103 as being obvious over Richter et al. (US20230196308A1) in view of Hogan et al. (US20020035548A1) in view of Colabella et al. (US20170300642A1).
With respect to claim 19
The combination of Richter and Hogan teaches the limitation of claim 1. The combination doesn’t explicitly disclose, but Colabella teaches: wherein the designated field comprises a notes section associated with a customer record of the CRM system (see [0059].)
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 Colabella with the teaching of Richter/Hogan as they relate to system of managing payment transaction. One of ordinary skill in the art before effective filing date of the claimed invention was made would have modified combined systems of Richter/Hogan, for example the payment transaction system in Richter, to include a method of including a notes section associated with a customer record as taught by Colabella for the predicated result of increased and improved customizability across the multi-service business platform.
With respect to claim 20
The combination of Richter and Hogan teaches the limitation of claim 1. The combination doesn’t explicitly disclose, but Colabella teaches: wherein the designated field comprises a notes section associated with a transaction record of the CRM system (see [0059].)
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 Colabella with the teaching of Richter/Hogan as they relate to system of managing payment transaction. One of ordinary skill in the art before effective filing date of the claimed invention was made would have modified combined systems of Richter/Hogan, for example the payment transaction system in Richter, to include a method of including a notes section associated with a transaction record as taught by Colabella for the predicated result of increased and improved customizability across the multi-service business platform.
With respect to claim 21 and 22
The combination of Richter and Hogan teaches the limitation of claim 1 and 11 respectively. The combination doesn’t explicitly disclose, but Colabella teaches: wherein the customer payment information is securely stored and managed in compliance with payment card industry data security standards (see [0038].)
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 Colabella with the teaching of Richter/Hogan as they relate to system of managing payment transaction. One of ordinary skill in the art before effective filing date of the claimed invention was made would have modified combined systems of Richter/Hogan, for example the payment transaction system in Richter, to include a system of making sure that customer payment information complies with the industry standard a notes section as taught by Colabella for the predicated result of increased and improved customizability across the multi-service business platform.
Claim 23 is rejected under 35 U.S.C 103 as being obvious over Richter et al. (US20230196308A1) in view of Hogan et al. (US20020035548A1) in view of Schnitt et al. (US20220292465A1).
With respect to claim 23
The combination of Richter and Hogan teaches the limitation of claim 11. The combination doesn’t explicitly disclose, but Schnitt teaches: wherein the predefined workflow is performed using inherent capabilities of the CRM system to interact with external applications and services via the existing application programming interface without modifying core functionalities of the CRM system ([0328], The multi-service business platform 510 may also communicate with integrator device(s) 576. Integrator devices 576 may refer to user devices used by third-party integrator users that may create and may define a series of custom objects that may be integrated with other objects in the multi-service business platform 510 and may be offered to users (e.g., clients) of the multi-service business platform 510. The multi-service business platform 510 may include APIs (as described in the disclosure) that a user may use to define custom objects and integrate those custom objects into the CRM (e.g., CRM system 502) and thereby into the multi-service business platform 510. These same APIs may be available to integrator users to do the same thing. The integrator users may define a series of custom objects, then the integrator users may define object definitions. When a client installs that integration, the multi-service business platform 510 may enable the client (e.g., users of the client) to then start creating instances of custom objects defined by the integrator user(s).)
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 Schnitt with the teaching of Richter/Hogan as they relate to system of managing payment transaction. One of ordinary skill in the art before effective filing date of the claimed invention was made would have modified combined systems of Richter/Hogan, for example the payment transaction system in Richter, to include a method of interacting with external applications and services via the existing API as taught by Schnitt for the predicated result of increased and improved customizability across the multi-service business platform.
Conclusion
THIS ACTION IS MADE FINAL, necessitated by amendment. 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 7/27/2026
/NILESH B KHATRI/Primary Examiner, Art Unit 3699
Prosecution Insights