DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
This action is in reply to the application and amended claims filed on 1/15/2025, wherein:
Claims 1-20 remain as original;
Claims 21-30 have been cancelled;
Claims 1-20 are currently pending and have been examined.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claims recite a device and method for payment management which is considered a judicial exception because it falls under Certain Methods of Organizing Human Activity such as commercial or legal interactions, including agreements in the form of contracts; and marketing, or sales activities, or behaviors. This judicial exception is not integrated into a practical application as discussed below and the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception as discussed below.
This rejection follows the 2019 Revised Patent Subject Matter Eligibility Guidance, 84 Fed Reg 4, January 7, 2019, pp. 50-57 (“2019 PEG”)(MPEP 2106).
Analysis
Step 1 (Statutory Categories) – 2019 PEG pg. 53 (See MPEP 2106.03)
Claims 1-20 are directed to the statutory category of a process, machine, or manufacture.
Step 2A, Prong 1 (Do the claims recite an abstract idea?) – 2019 PEG pg. 54 (See MPEP 2106.04(a)-(c))
For independent claims 1 and 11, the claims recite an abstract idea of: payment management. The steps of independent claim 1 recite the abstract idea (in bold below) of: A method comprising: at a device comprising one or more processors: providing, via a payment portal interface, access for a partner device to an on-boarding integration platform; receiving partner data from the partner device via the payment portal interface, wherein the partner data comprises at least one of a platform offer or a payment product corresponding to a partner associated with the partner device; in response to receiving the partner data, determining, based on a payment management platform algorithm, at least one payment management interface tool associated with the partner, wherein the at least one payment management interface tool comprises user integration instructions; receiving an integration request from the partner device via the payment portal interface, wherein the integration request comprises integration data entered via the partner device and based on a defined workflow integration environment corresponding to the user integration instructions; and providing, based on the integration data, the partner data for display at a user device via the payment portal interface. Independent claim 11 recites similar steps that recite the abstract idea. Independent claims 1 and 11, as drafted, are a process that, under the broadest reasonable interpretation, covers Certain Methods of Organizing Human Activity, since they recite fundamental economic principles or practices including mitigating risk. If the claim limitations, under the broadest reasonable interpretation, covers methods of organizing human activity but for the recitation of additional elements including generic computer components, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. Other than reciting the abstract idea, the independent claims recite additional elements including generic computer components such as “a device comprising one or more processors; a payment portal interface; a partner device; an on-boarding integration platform; a payment management platform algorithm; a payment management interface tool; a user device; and a device comprising: a non-transitory computer-readable storage medium comprising program instructions executed by one or more processors”, and nothing in the claims precludes the steps from being performed as a method of organizing human activity. Accordingly, the independent claims recite an abstract idea.
Dependent claims 2-10, and 12-20 recite similar limitations as claims 1 and 11; and when analyzed as a whole are held to be patent ineligible under 35 U.S.C 101 because the additional recited limitations only refine the abstract idea further. Other than reciting the abstract idea, the dependent claims recite similar additional elements including generic computer components as the independent claims, such as “the payment management interface tool; the payment portal interface; an application program interface (API); a certification engine portal; the partner device; a user device; a link; the on-boarding integration platform; a front-end application program interface (API), the device; and the one or more processors”. If a claim limitation, under its broadest reasonable interpretation, covers commercial or legal interactions, but for the recitation of generic computer components, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas.
Step 2A, Prong 2 (Does the claim recite additional elements that integrate the judicial exception into a practical application?) – 2019 PEG pg. 54 (See MPEP 2106.04(d)-(c))
This judicial exception is not integrated into a practical application. In particular, independent claims 1 and 11 only recite the additional elements of “a device comprising one or more processors; a payment portal interface; a partner device; an on-boarding integration platform; a payment management platform algorithm; a payment management interface tool; a user device; and a device comprising: a non-transitory computer-readable storage medium comprising program instructions executed by one or more processors”. A plain reading of the Figures and associated descriptions in the specification reveals that generic processors may be used to execute the claimed steps. The additional elements are recited at a high level of generality (i.e., as a generic processor 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)) and limits the judicial exception to a particular environment (See MPEP 2106.05(h)). Mere instructions to apply an exception using a generic computer component and limiting the judicial exception to a particular environment doesn’t integrate the abstract idea into a practical application in Step 2A. Accordingly, these additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Hence, independent claims 1 and 11 are directed to an abstract idea.
Dependent claims 2-10, and 12-20, recite similar additional elements as the independent claims including generic computer components, such as “the payment management interface tool; the payment portal interface; an application program interface (API); a certification engine portal; the partner device; a user device; a link; the on-boarding integration platform; a front-end application program interface (API), the device; and the one or more processors”. The judicial exception is not integrated into a practical application because the additional elements in the dependent claims are also recited at a high-level of generality such that it amounts to more no more than mere instructions to apply the exception using generic computer components. Therefore, the additional elements do not integrate the abstract idea into a practical application because they also do not impose any meaningful limits on practicing the abstract idea. Also, the claims do not affect an improvement to another technology or technical field; the claims do not amount to an improvement of the functioning of a computer system itself; the claims do not effect a transformation or reduction of a particular article to a different state or thing; and the claims do not move beyond a general link of the use of an abstract idea to a particular technological environment.
Step 2B (Does the claim recite additional elements that amount to significantly more than the judicial exception?) – 2019 PEG pg. 56 (See MPEP 2106.05)
Independent claims 1 and 11 do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the recited additional elements amount to no more than mere instructions to apply the exception using a generic computer component (See MPEP 2106.05(f)) and limits the judicial exception to the particular environment of computers (See MPEP 2106.05(h)). The additional elements of the instant underlying process, when taken in combination, together do not offer substantially more than the sum of the function of the elements when each is taken alone. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept in Step 2B.
In addition, the dependent claims 2-10, and 12-20 do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of the dependent claims to perform the claimed limitations, amounts to no more than mere instructions to apply the exception using a generic computer component (See MPEP 2106.05(f)). Similar to the independent claims, mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. Also, for the same reasoning as the independent claims, the additional elements of the limitations of the dependent claims, when considered individually and as an ordered combination, together do not offer significantly more than the sum of the functions of the elements when each is taken alone and the dependent claims as a whole, do not amount to significantly more than the abstract idea itself. For these reasons, the dependent claims also are not patent eligible.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-5, 7-9, 11-15, and 17-19 are rejected under 35 U.S.C. 103 as being unpatentable over US 12,450,530 to Cruikshank et al. (hereinafter referred to as Cruikshank), in view of US 2025/0209396 to Thakur et al. (hereinafter referred to as Thakur).
In regards to claim 1, Cruikshank discloses a method (method and systems for facilitating automated onboarding of client systems based on validated system parameter inputs, col. 1, lines 8-12) comprising: at a device (computing device configured to implement an execution of a method for facilitating automated system onboarding includes a processor, col. 2, lines 57-60) comprising one or more processors (computer system 102 includes processor 104, col. 5, lines 48-67; method for automated onboarding may be implemented by an Automated System Onboarding Management (ASOM) device 202 which may be the same or similar to computer system 102): providing, via a payment portal interface (computing device including a processor configured to receive via a graphical user interface at least one onboarding request from a user, col. 2, lines 57-67), access for a partner device (ASOM device 202 coupled to plurality client devices 208(1)-208(n) via network 210, col. 8, lines 47-67; client devices 208(1)-208(n) may be any type of computer device, col. 10, lines 4-27) to an on-boarding integration platform (ASOM device 202 includes automated system onboarding management module 302 for facilitating automated onboarding of client systems based on validated system parameter inputs, col. 10, line 64 – col. 11, line 4, fig. 3); receiving partner data from the partner device via the payment portal interface (onboarding requests may be received from a user at step S402 via a graphical user interface for integration of the user system with a plurality of services in an enterprise network environment, col. 11, lines 35-59), wherein the partner data comprises at least one of a platform offer or a payment product corresponding to a partner associated with the partner device (onboarding request may include system parameters that correspond to the client system, col. 11, lines 50-59); in response to receiving the partner data (a first user input may be received via the graphical user interface including information that relates to the user system, col. 12, lines 1-10), determining (whether supplemental user system data are required from the user may be automatically determined based on the first user input and predetermined guideline, col. 12, lines 1-10), at least one payment management interface tool associated with the partner (a graphical user element may be generated based on a result of the determining, col. 12, lines 1-17), wherein the at least one payment management interface tool comprises user integration instructions (graphical elements may be displayed via the graphical user interface and include instructions for the user and an input field to receive a second user input, col. 12, lines 1-26); receiving an integration request from the partner device via the payment portal interface (onboarding requests received via a graphical user interface may include system parameter that correspond to the client system, col. 11, lines 50-67), wherein the integration request comprises integration data entered via the partner device (dynamically variable input fields may be used to receive the onboarding requests via the graphical user interface with a smart field adjusted in real time to provide and/or request information from the user based on the user inputs, col. 11, lines 50-67) and based on a defined workflow integration environment corresponding to the user integration instructions (whether supplemental user system data is required from the user may be automatically determined based on the first user input and a predetermined guideline that includes a technical guideline for onboarding, a business guide for onboarding, and a regulatory guideline for onboarding the user, col. 12, lines 1-17); and providing, based on the integration data (at step S404, the onboarding requests and the system parameter may be automatically validated with system parameters parsed to extract data for comparison with predetermined technical requirements to ensure compatibility between the user system and the enterprise network environment, col. 13, lines 1-20). However, Cruikshank fails to disclose determining based on a payment management platform algorithm; and providing the partner data for display at a user device via the payment portal interface.
Thakur, in the related field of onboarding digital data and services for merchants with an online merchant marketplace platform, teaches determining (service provider may utilize the conversational AI system to provide a personalized onboarding experience to the merchant, para. 0016) based on a payment management platform algorithm (recommendation data 138 may include merchant-specific recommendations to personalize merchant experience and/or chat assistance through conversational AI engine 132. Thereafter, MO platform 130 may process a merchant onboarding for a merchant request, which may include creating and/or processing accounts and account data, providing SDKs and API endpoints for system integrations, determining and awarding badges, rewards, or the like for performance and tasks completed during onboarding, and/or otherwise recommending actions based on a merchant intent with the onboarding processing and request, para. 0035); and providing the partner data for display at a user device via the payment portal interface (after merchant onboarding, the merchant application 112 may be accessible over the Internet and provide and/or process items for sale with merchant device 110 and a user interacting with the merchant device using the website, mobile application, or another merchant marketplace platform over network 140, para. 0024). It would have been obvious to one having ordinary skill in the art at the time the invention was filed to provide the method of Cruikshank with the ability to use an algorithm to onboard a merchant to an online marketplace for selling products for consumers as taught by the method of Thakur. The motivation for doing so would have been to provide a more streamlined, faster, and more secure process to onboard digital data and services for merchants with an online merchant marketplace platform (Thakur, para. 0002).
In regards to claim 2, modified Cruikshank discloses the method of claim 1, and further discloses wherein determining the at least one payment management interface tool associated with the partner comprises performing a verification analysis of the partner data (at step S404, the onboarding requests and the system parameter may be automatically validated with system parameters parsed to extract data for comparison with predetermined technical requirements to ensure compatibility between the user system and the enterprise network environment, col. 13, lines 1-20), and in response to verifying the partner data, the method further comprises providing a verification notification via the payment portal interface (a validation notification may be provided to an associated user based on a result of the validation, col. 13, lines 1-31).
In regards to claim 3, modified Cruikshank discloses the method of claim 1, and further discloses wherein the defined workflow integration environment comprises an application program interface (API) (to generate the communication interface, an application programming interface (API) may be automatically configured based on the system parameters to facilitate interactions between multiple software applications by defining parameters such as, for example, the kind of calls and/or requests that can be made, how the calls and/or requests are made, the data formats that should be used, and the conventions that must be followed, col. 13, lines 48-67) test invitation via a certification engine portal (At step S408, the communication interface may be automatically tested, col. 14, lines 27-39).
In regards to claim 4, modified Cruikshank discloses the method of claim 3, and further discloses wherein the certification engine portal is configured to determine whether a user API solution comprises a passing mark or a failing mark for a certification test (automated onboarding process may include automatically detecting errors that correspond to the communication interface, col. 14, lines 56-67) based on the integration data entered via the partner device (processor may be further configured to automatically detect at least one error that corresponds to the at least one communication interface based on a result of the automatic testing; automatically identify at least one resolution action for each of the at least one error; and automatically initiate the at least one resolution action based on a predetermined setting, col. 3, lines 1-17).
In regards to claim 5, modified Cruikshank discloses the method of claim 4, and further discloses wherein in response to the user API solution comprising a failing mark, the method further comprises providing failed solution feedback (at step S412 a log may be generated for the automated onboarding process including information related to the automatic testing, col. 14, lines 56-64) for display at a user device via the payment portal interface (resolution action for each error may include generating a service ticket in an issue tracking platform, and an action to notify at least one responsible party, col. 15, lines 1-17).
In regards to claim 7, modified Cruikshank discloses the method of claim 1, further comprising: receiving, at the payment portal interface, a configuration verification request from the user to verify a business solution entered by the user (validation notification may be provided to an associated user based on a result of the validation. The validation notification may include information such as, for example, validation status information and validation error information, col. 13, lines 20-31); and determining whether the business solution entered by the user (at step S408, the communication interface may be automatically tested in a development environment that facilitates simulations of a live system, col. 14, lines 27-55) is publishable on the on-boarding integration platform (at step S410 the communication interface may be implemented based on the result of the testing by transitioning the interface to a production environment corresponding to a live operating environments where the communication interface is put into operation according to an intended use, col. 14, lines 27-55).
In regards to claim 8, modified Cruikshank discloses the method of claim 7, and further discloses wherein determining whether the business solution entered by the user is publishable on the on-boarding integration platform (at step S410 the communication interface may be implemented based on the result of the testing by transitioning the interface to a production environment corresponding to a live operating environments where the communication interface is put into operation according to an intended use, col. 14, lines 27-55) is based on an analysis performed in a configuration test environment (the development environment may correspond to a closed operating environment that is usable to test and further refine the communication interface by simulations of a live system without the risks associated with communication interface testing on a live system, col. 14, lines 27-55).
In regards to claim 9, modified Cruikshank discloses the method of claim 1, and further discloses wherein the payment portal interface comprises a front-end application program interface (API) (various front-end services may facilitate interactions between the user and the disclosed system and the backend server may receive API requests from the front-end SPA and send back responses from existing services and data storage devices, col. 16, lines 1-25, figs. 7 and 8).
In regards to claim 11, Cruikshank discloses a device (method and systems for facilitating automated onboarding of client systems based on validated system parameter inputs, col. 1, lines 8-12) comprising: a non-transitory computer-readable storage medium (non-transitory computer readable medium, col. 16, lines 42-67); and one or more processors coupled to the non-transitory computer-readable storage medium (computer-readable medium carrying a set of instructions for execution by a processor, col. 16, lines 42-67), wherein the non-transitory computer-readable storage medium (non-transitory computer readable medium, col. 16, lines 42-67) comprises program instructions that, when executed by the one or more processors (computer-readable medium carrying a set of instructions for execution by a processor, col. 16, lines 42-67), cause the one or more processors (computer system 102 includes processor 104, col. 5, lines 48-67; method for automated onboarding may be implemented by an Automated System Onboarding Management (ASOM) device 202 which may be the same or similar to computer system 102) to: provide, via a payment portal interface (computing device including a processor configured to receive via a graphical user interface at least one onboarding request from a user, col. 2, lines 57-67), access for a partner device (ASOM device 202 coupled to plurality client devices 208(1)-208(n) via network 210, col. 8, lines 47-67; client devices 208(1)-208(n) may be any type of computer device, col. 10, lines 4-27) to an on-boarding integration platform (ASOM device 202 includes automated system onboarding management module 302 for facilitating automated onboarding of client systems based on validated system parameter inputs, col. 10, line 64 – col. 11, line 4, fig. 3); receive partner data from the partner device via the payment portal interface (onboarding requests may be received from a user at step S402 via a graphical user interface for integration of the user system with a plurality of services in an enterprise network environment, col. 11, lines 35-59), wherein the partner data comprises at least one of a platform offer or a payment product corresponding to a partner associated with the partner device (onboarding request may include system parameters that correspond to the client system, col. 11, lines 50-59); in response to receiving the partner data (a first user input may be received via the graphical user interface including information that relates to the user system, col. 12, lines 1-10), determining (whether supplemental user system data are required from the user may be automatically determined based on the first user input and predetermined guideline, col. 12, lines 1-10), at least one payment management interface tool associated with the partner (a graphical user element may be generated based on a result of the determining, col. 12, lines 1-17), wherein the at least one payment management interface tool comprises user integration instructions (graphical elements may be displayed via the graphical user interface and include instructions for the user and an input field to receive a second user input, col. 12, lines 1-26); receive an integration request from the partner device via the payment portal interface (onboarding requests received via a graphical user interface may include system parameter that correspond to the client system, col. 11, lines 50-67), wherein the integration request comprises integration data entered via the partner device (dynamically variable input fields may be used to receive the onboarding requests via the graphical user interface with a smart field adjusted in real time to provide and/or request information from the user based on the user inputs, col. 11, lines 50-67) and based on a defined workflow integration environment corresponding to the user integration instructions (whether supplemental user system data is required from the user may be automatically determined based on the first user input and a predetermined guideline that includes a technical guideline for onboarding, a business guide for onboarding, and a regulatory guideline for onboarding the user, col. 12, lines 1-17); and provide, based on the integration data (at step S404, the onboarding requests and the system parameter may be automatically validated with system parameters parsed to extract data for comparison with predetermined technical requirements to ensure compatibility between the user system and the enterprise network environment, col. 13, lines 1-20). However, Cruikshank fails to disclose determining based on a payment management platform algorithm; and providing the partner data for display at a user device via the payment portal interface.
Thakur, in the related field of onboarding digital data and services for merchants with an online merchant marketplace platform, teaches determining (service provider may utilize the conversational AI system to provide a personalized onboarding experience to the merchant, para. 0016) based on a payment management platform algorithm (recommendation data 138 may include merchant-specific recommendations to personalize merchant experience and/or chat assistance through conversational AI engine 132. Thereafter, MO platform 130 may process a merchant onboarding for a merchant request, which may include creating and/or processing accounts and account data, providing SDKs and API endpoints for system integrations, determining and awarding badges, rewards, or the like for performance and tasks completed during onboarding, and/or otherwise recommending actions based on a merchant intent with the onboarding processing and request, para. 0035); and providing the partner data for display at a user device via the payment portal interface (after merchant onboarding, the merchant application 112 may be accessible over the Internet and provide and/or process items for sale with merchant device 110 and a user interacting with the merchant device using the website, mobile application, or another merchant marketplace platform over network 140, para. 0024). It would have been obvious to one having ordinary skill in the art at the time the invention was filed to provide the method of Cruikshank with the ability to use an algorithm to onboard a merchant to an online marketplace for selling products for consumers as taught by the method of Thakur. The motivation for doing so would have been to provide a more streamlined, faster, and more secure process to onboard digital data and services for merchants with an online merchant marketplace platform (Thakur, para. 0002).
In regards to claim 12, modified Cruikshank discloses the device of claim 11, and further discloses wherein determining the at least one payment management interface tool associated with the partner comprises performing a verification analysis of the partner data (at step S404, the onboarding requests and the system parameter may be automatically validated with system parameters parsed to extract data for comparison with predetermined technical requirements to ensure compatibility between the user system and the enterprise network environment, col. 13, lines 1-20), and in response to verifying the partner data, the program instructions, when executed by the one or more processors, further cause the one or more processors to: provide a verification notification via the payment portal interface (a validation notification may be provided to an associated user based on a result of the validation, col. 13, lines 1-31).
In regards to claim 13, modified Cruikshank discloses the device of claim 11, and further discloses wherein the defined workflow integration environment comprises an application program interface (API) (to generate the communication interface, an application programming interface (API) may be automatically configured based on the system parameters to facilitate interactions between multiple software applications by defining parameters such as, for example, the kind of calls and/or requests that can be made, how the calls and/or requests are made, the data formats that should be used, and the conventions that must be followed, col. 13, lines 48-67) test invitation via a certification engine portal (At step S408, the communication interface may be automatically tested, col. 14, lines 27-39).
In regards to claim 14, modified Cruikshank discloses the device of claim 13, and further discloses wherein the certification engine portal is configured to determine whether a user API solution comprises a passing mark or a failing mark for a certification test (automated onboarding process may include automatically detecting errors that correspond to the communication interface, col. 14, lines 56-67) based on the integration data entered via the partner device (processor may be further configured to automatically detect at least one error that corresponds to the at least one communication interface based on a result of the automatic testing; automatically identify at least one resolution action for each of the at least one error; and automatically initiate the at least one resolution action based on a predetermined setting, col. 3, lines 1-17).
In regards to claim 15, modified Cruikshank discloses the device of claim 14, wherein in response to the user API solution comprising a failing mark, the program instructions, when executed by the one or more processors, further cause the one or more processors to: provide failed solution feedback (at step S412 a log may be generated for the automated onboarding process including information related to the automatic testing, col. 14, lines 56-64) for display at a user device via the payment portal interface (resolution action for each error may include generating a service ticket in an issue tracking platform, and an action to notify at least one responsible party, col. 15, lines 1-17).
In regards to claim 17, modified Cruikshank discloses the device of claim 11, and further discloses wherein the program instructions, when executed by the one or more processors, further cause the one or more processors to: receive, at the payment portal interface, a configuration verification request from the user to verify a business solution entered by the user (validation notification may be provided to an associated user based on a result of the validation. The validation notification may include information such as, for example, validation status information and validation error information, col. 13, lines 20-31); and determine whether the business solution entered by the user (at step S408, the communication interface may be automatically tested in a development environment that facilitates simulations of a live system, col. 14, lines 27-55) is publishable on the on-boarding integration platform (at step S410 the communication interface may be implemented based on the result of the testing by transitioning the interface to a production environment corresponding to a live operating environments where the communication interface is put into operation according to an intended use, col. 14, lines 27-55).
In regards to claim 18, modified Cruikshank discloses the device of claim 17, and further discloses wherein determining whether the business solution entered by the user is publishable on the on-boarding integration platform (at step S410 the communication interface may be implemented based on the result of the testing by transitioning the interface to a production environment corresponding to a live operating environments where the communication interface is put into operation according to an intended use, col. 14, lines 27-55) is based on an analysis performed in a configuration test environment (the development environment may correspond to a closed operating environment that is usable to test and further refine the communication interface by simulations of a live system without the risks associated with communication interface testing on a live system, col. 14, lines 27-55).
In regards to claim 19, modified Cruikshank discloses the device of claim 11, and further discloses wherein the payment portal interface comprises a front-end application program interface (API) (various front-end services may facilitate interactions between the user and the disclosed system and the backend server may receive API requests from the front-end SPA and send back responses from existing services and data storage devices, col. 16, lines 1-25, figs. 7 and 8).
Claims 6 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Cruikshank, in view of Thakur, and further in view of US 20030018585 to Butler et al. (hereinafter referred to as Butler).
In regards to claim 6, modified Cruikshank discloses the method of claim 4, and further discloses wherein in response to the user API solution comprising a passing mark (At step S410, the communication interface may be implemented based on a result of the testing. Implementation of the communication interface may correspond to a transition of the communication interface from a development environment to a production environment, col. 14, lines 40-55), the method further comprises providing passing solution feedback for display at a user device via the payment portal interface (validation notification may be provided to an associated user based on a result of the validation. The validation notification may include information such as, for example, validation status information and validation error information, col. 13, lines 20-31), but fails to disclose wherein the passing solution feedback comprises a link to download a certification document.
Butler, in the related field of the communication of assured reputation information within an electronic marketplace, teaches wherein the passing solution feedback comprises a link to download a certification document (display an icon on their Web site providing a hyperlink to a record on the VeriBiz server certifying the said business as a verified member, para. 0005). It would have been obvious to one having ordinary skill in the art at the time the invention was filed to provide the method of Cruikshank with the ability to provide certification for an online marketplace as taught by the method of Butler. The motivation for doing so would have been for when a provider would advertise a product via the auction system hosted by the authority, and the catalogue entry provided would publish a link to the seller's reputation information on the authority (Butler, para. 0152).
In regards to claim 16, modified Cruikshank discloses the device of claim 14, wherein in response to the user API solution comprising a passing mark (At step S410, the communication interface may be implemented based on a result of the testing. Implementation of the communication interface may correspond to a transition of the communication interface from a development environment to a production environment, col. 14, lines 40-55), the program instructions, when executed by the one or more processors, further cause the one or more processors to: provide passing solution feedback for display at a user device via the payment portal interface (validation notification may be provided to an associated user based on a result of the validation. The validation notification may include information such as, for example, validation status information and validation error information, col. 13, lines 20-31), but fails to disclose wherein the passing solution feedback comprises a link to download a certification document.
Butler, in the related field of the communication of assured reputation information within an electronic marketplace, teaches wherein the passing solution feedback comprises a link to download a certification document (display an icon on their Web site providing a hyperlink to a record on the VeriBiz server certifying the said business as a verified member, para. 0005). It would have been obvious to one having ordinary skill in the art at the time the invention was filed to provide the method of Cruikshank with the ability to provide certification for an online marketplace as taught by the method of Butler. The motivation for doing so would have been for when a provider would advertise a product via the auction system hosted by the authority, and the catalogue entry provided would publish a link to the seller's reputation information on the authority (Butler, para. 0152).
Claims 10 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Cruikshank, in view of Thakur, and further in view of US 8745641 to Coker (hereinafter referred to as Coker).
In regards to claim 10, modified Cruikshank discloses the method of claim 9, but fails to disclose wherein the API is based on a representational state transfer protocol.
Coker, in the related field of API development and testing, teaches wherein the API is based on a representational state transfer protocol (an API may conform to a Representational State Transfer (REST) model or style of software architecture, col. 1, lines 28-50). It would have been obvious to one having ordinary skill in the art at the time the invention was filed to provide the method of Cruikshank with the ability to use a REST API as taught by the method of Coker. The motivation for doing so would have been because the domain specific language enables the REST operations to be expressed via the one or more commands, independently of the syntax or the request payload (Coker, col. 13, lines 23-34).
In regards to claim 20, modified Cruikshank discloses the device of claim 19, but fails to disclose wherein the API is based on a representational state transfer protocol.
Coker, in the related field of API development and testing, teaches wherein the API is based on a representational state transfer protocol (an API may conform to a Representational State Transfer (REST) model or style of software architecture, col. 1, lines 28-50). It would have been obvious to one having ordinary skill in the art at the time the invention was filed to provide the method of Cruikshank with the ability to use a REST API as taught by the method of Coker. The motivation for doing so would have been because the domain specific language enables the REST operations to be expressed via the one or more commands, independently of the syntax or the request payload (Coker, col. 13, lines 23-34).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Jain (US 20210209682) teaches an AI onboarding system for performing trading partner onboarding.
Majusiak (US 20220327587) teaches multi-channel cognitive resource application integration for digital onboard landing across platforms.
Le Marier et al. (US 20250245634) teaches a method for implementing a marketplace management process for a payment management system
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Paul Schwarzenberg whose telephone number is (313) 446-6611. The examiner can normally be reached on Monday-Thursday (7: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, Christine Behncke, can be reached on (571) 272-8103. 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.
/PAUL S SCHWARZENBERG/Primary Examiner, Art Unit 3695 1/29/2024