DETAILED ACTION
Status of Claims
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
This action is in reply to the remarks/arguments for Application 18/878,860 filed on 24 December 2024.
Claims 19-23 have been canceled.
Claims 24-25 have been added.
Claims 1-18 and 24-25 are currently pending and have been examined.
Information Disclosure Statement
The Information Disclosure Statement filed 24 December 2024 has been considered. An initialed copy of the Form 1449 is enclosed herewith.
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 and 24-25 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
In the instant case, representative method claim 1 is directed towards selection of a payment application program in order to facilitate a remote payment associated with e-commerce related activity in an automated manner. Claim 1 is directed to the abstract idea of utilizing rules and/or instructions for performing the existing commercial practice (e.g., e-commerce) and/or concept of facilitating payment method selection comprising the steps of transmitting data/information associated with a financial activity, which is grouped under the certain methods of organizing human activity – fundamental economic principles, practices or concepts; sales activity; following set of instructions; commercial interactions; managing interactions between people (including social activities, teachings, following rules or instructions) grouping, in step 2A prong one. Accordingly, for these reasons, the claim recites an abstract idea.
Claim 1 recites:
“when the e-commerce application program triggers a multi-party payment entrance, calling the first SDK to send a list request message to a remote payment platform, wherein the list request message includes list requirement information, wherein the list requirement information includes an e-commerce application identifier and a user identifier;
calling the first SDK to obtain a first payment application list from the remote payment platform, wherein the first payment application list represents a plurality of payment application programs supported by the remote payment platform and ranked in a descending order of priority, wherein the priority is obtained by the remote payment platform based on associated data corresponding to the list requirement information;
calling the first SDK to obtain a second payment application list, wherein the second payment application list represents payment application programs owned by the user terminal;
calling up, by the first SDK, a first target payment application program, wherein the first target payment application program is a payment application program with a highest priority in an intersection of the first payment application list and the second payment application list;
interacting, through a second SDK called by the first target payment application program, with the remote payment platform to complete a payment”.
Based on the underlined elements above, abstract ideas and/or concepts are identified. Accordingly, the claim recites an abstract idea.
This judicial exception is not integrated into a practical application because, when analyzed under step 2A prong two, the additional elements of the claim such as a “software development kit”, “remote payment platform”, represent the use of a computer-related devices as a tool (intermediary) to perform an abstract idea and/or does no more than generally apply the abstract idea to a particular field of use. Therefore, the additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to (i.e. automate) implement the acts of utilizing rules and/or instructions for performing the existing commercial practice (e.g., e-commerce) and/or concept of facilitating a payment method selection comprising the steps of transmitting data/information associated with a financial activity.
When analyzed under step 2B, the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception itself. Viewed as a whole, the combination of elements recited in the claims merely describe the concept of utilizing rules and/or instructions for performing the existing commercial practice (e.g., e-commerce) and/or concept of facilitating a payment method selection comprising the steps of transmitting data/information associated with a financial activity using computer computer-related technology and/or devices that merely perform as designed to function. Therefore, the use of these additional elements does no more than employ a computer as a tool to automate and/or implement the abstract idea, which cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)). Hence, claim 1 is not patent eligible.
Independent claim 10 recites substantially the same limitations as claim 1 above and is ineligible for the same reasons. The subject matter of claim 10 corresponds to the subject matter of claim 1 in terms of a method (e.g., process). Therefore the reasoning provided for claim 1 applies to claim 10 accordingly.
Independent claim 18 recites substantially the same limitations as claim 1 above and is ineligible for the same reasons. The subject matter of claim 18 corresponds to the subject matter of claim 1 in terms of a system (e.g., machine). Therefore the reasoning provided for claim 1 applies to claim 18 accordingly.
Dependent claims 2-9, 11-17 and 24-25 add further details and contain limitations that narrow the scope of the invention. However, these details do not result in significantly more than the abstract idea itself. As explained in the December 16, 2014 Interim Eligibility Guidance from the USPTO (in reference to the BuySAFE, Inc. v. Google, Inc. decision), further narrowing the details of an abstract idea does not change the § 101 analysis since a more narrow abstract idea does not make it any less abstract.
The step(s) recited are a further refinement of methods of organizing human activity – fundamental economic principles, practices or concepts; sales activity; following set of instructions; commercial or legal interactions (agreements in the form of contracts; business relations); managing interactions between people (including social activities, teachings, following rules or instructions), because it merely describes intermediate steps and/or rules/instructions of the process.
Viewed individually and in combination, these additional elements do not provide meaningful limitations to transform the abstract idea such that the claims amount to significantly more than the abstraction itself.
Accordingly, the present pending claims are not patent eligible and are rejected under 35 U.S.C. 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 may not be obtained though the invention is not identically disclosed or described as set forth in section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the manner in which the invention was made.
Claims 1-18 and 24-25 are rejected under 35 U.S.C. 103 as being unpatentable over Sarjaz et al., US 2020/0242590 A1 (“Sarjaz”), in view of Collicoat, US 2025/0045765 A1 (“Collicoat”), in view of Bodalia et al., US 2022/0076236 A1 (“Bodalia”).
Re Claim 1: (Original) A smart routing-based remote payment method, applied to a user terminal, wherein the user terminal includes an e-commerce application program, a first software development kit (SDK) integrated in the e-commerce application program, a payment application program, and a second SDK integrated in the payment application program, wherein the e-commerce application program belongs to a first entity, the payment application program belongs to a second entity, the first SDK and the second SDK belong to a third entity, and the method comprising:
when the e-commerce application program triggers a multi-party payment entrance, calling the first SDK to send a list request message to a remote payment platform, wherein the list request message includes list requirement information, wherein the list requirement information includes an e-commerce application identifier and a user identifier; ([0007] “In embodiments, the data provider may be one of a merchant and a customer of a merchant. The data controller may be one of an e-commerce platform and a merchant.”; [0023] “FIG. 1 depicts an embodiment of an e-commerce platform.”; [0046] “… in embodiments the e-commerce platform 100 may be configured with a commerce management engine 136 for content management, task automation and data management to enable support and services to the plurality of online stores 138 ( e.g., related to products, inventory, customers, orders, collaboration, suppliers, reports, financials, risk and fraud, and the like), but be extensible through applications 142A-B that enable greater flexibility and custom processes required for accommodating an ever-growing variety of merchant online stores, POS devices, products, and services, where applications 142A may be provided internal to the e-commerce platform 100 or applications 142B from outside the e-commerce platform 100. In embodiments, an application 142A may be provided by the same party providing the platform 100 or by a different party. In embodiments, an application 142B may be provided by the same party providing the platform 100 or by a different party. The commerce management engine 136 may be configured for flexibility and scalability through portioning ( e.g., sharding) of functions and data, such as by customer identifier, order identifier, online store identifier, and the like.”)
calling the first SDK to obtain a first payment application list from the remote payment platform, wherein the first payment application list represents a plurality of payment application programs supported by the remote payment platform and ranked in a descending order of priority, wherein the priority is obtained by the remote payment platform based on associated data corresponding to the list requirement information; ([0051] “In embodiments, applications 142A-B may deliver functionality to a merchant through the interface 140A-B, such as where an application 142A-B is able to surface transaction data to a merchant ( e.g., App: "Engine, surface my app data in mobile and web admin using the embedded app SDK"), and/or where the commerce management engine 136 is able to ask the application to perform work on demand …”; [0057] “… Integration applications may include applications that provide useful integrations that participate in the running of a business, such as … payment gateways.”)
calling the first SDK to obtain a second payment application list, wherein the second payment application list represents payment application programs owned by the user terminal; ([0057] “… Integration applications may include applications that provide useful integrations that participate in the running of a business, such as … payment gateways.”)
Regarding the limitation comprising:
calling up, by the first SDK, a first target payment application program, wherein the first target payment application program is a payment application program with a highest priority in an intersection of the first payment application list and the second payment application list;
Collicoat makes these teachings in a related endeavor ([0005] “One embodiment provides a method for executing an electronic transaction by a parallel transaction system, comprising: receiving, by a parallel transaction system, an electronic transaction request of a payment vehicle; determining,
by the parallel transaction system, a type of the payment vehicle, the type of the payment vehicle being at least one of an open loop type, a closed loop type, or a parallel type; executing, by the parallel transaction system, an open-loop transaction, a closed-loop transaction, and/or a parallel transaction, based on the determined type of the payment vehicle; and completing, by the parallel transaction system, the electronic transaction request”; [0039] “The systems 100 and 200 may utilizes a software development kit (SDK) server (not shown) that may provide various SDK functions (or SDK) that the merchant system 120 may utilize to configure the POS terminal 110 and the browser 115 to facilitate communication with the processing system 130. Further, the systems 100 and 200 may utilize an application programming interface (API) server (not shown) that may provide various APIs that the merchant system 120 may to configure the POS terminal 110 and the browser 115 to facilitate communication with the processing system 130.”). It would have been obvious to one of ordinary skill in the art at the time of the invention to incorporate the teachings of Collicoat to the invention of Sarjaz as described above for the motivation of providing an entity with flexibility in the processing of remote payments.
Regarding the limitation comprising:
interacting, through a second SDK called by the first target payment application program, with the remote payment platform to complete a payment.
Bodalia makes these teachings in a related endeavor ([0029] “… In at least one example, the P2P payment platform can transfer funds from an account of the customer, maintained by the P2P payment platform, to an account of the merchant, maintained by the payment processing platform thereby facilitating a contactless (P2P) payment for the transaction. That is, based at least in part on receiving an indication of which payment method a user ( e.g., customer or merchant) intends to use for a transaction, techniques described herein utilize an integration between a P2P payment platform and payment processing platform (which can be a first- or third-party integration)”; [0282] “In some examples, a component may include one or more application programming interfaces (APIs) to perform some or all of its functionality ( e.g., operations). In at least one example, a software developer kit (SDK) can be provided by the service provider to allow third-party developers to include service provider functionality and/or avail service provider services in association with their own third-party applications. Additionally or alternatively, in some examples, the service provider can utilize a SDK to integrate third-party service provider functionality into its applications. That is, API(s) and/or SDK(s) can enable third-party developers to customize how their respective third-party applications interact with the service provider or vice versa.”). It would have been obvious to one of ordinary skill in the art at the time of the invention to incorporate the teachings of Bodalia to the invention of Sarjaz as described above for the motivation of facilitating remote payments in a secure manner.
Re Claim 2: (Original) Sarjaz in view of Collicoat in view of Bodalia discloses the method according to claim 1. Sarjaz further discloses:
wherein the list requirement information further includes one or more of the following: a version of a user terminal operating system, a version of the first SDK, and a version of the second SDK. ([0036] “elements of the e-commerce platform 100 may be implemented to operate on various platforms and operating systems, such as iOS, Android, on the web, and the like.”)
Re Claim 3: (Original) Sarjaz in view of Collicoat in view of Bodalia discloses the method according to claim 1. Regarding the limitation comprising:
wherein the associated data includes one or more of the following: a payment frequency of a payment application program, a payment success rate of a payment application program, a payment resource amount of a payment application program, a payment time of a payment application program, a payment credit limit of a user in a payment application program, a call-up sequence of payment application programs specified by the first entity, and a call-up sequence of the payment application programs specified by the third entity.
Collicoat makes these teachings in a related endeavor ([0043] “If the parallel payment system 135 determines that the parallel card is not compatible with the merchant's store or website, then the processing system 130 may proceed to step 414 and complete the transaction in accordance with the open-loop payment process as described above. If the parallel payment system 135 determines that the parallel card is compatible with the merchant's store or website, then the parallel payment system
135 may check for merchant program options, user payment preferences, and/or the parallel card's available balance at step 422. At step 424, the parallel payment system 135 may determine whether the parallel card has any available closed-loop fund balance. If the parallel payment system 135 determines that there is no available closed-loop fund balance associated with the parallel card, then the processing system 130 may proceed to step 414 and complete the transaction in accordance with the open-loop payment process.”). It would have been obvious to one of ordinary skill in the art at the time of the invention to incorporate the teachings of Collicoat to the invention of Sarjaz as described above for the motivation of providing an entity with flexibility in the processing of remote payments.
Re Claim 4: (Original) Sarjaz in view of Collicoat in view of Bodalia discloses the method according to claim 1. Regarding the limitation(s) comprising:
wherein interacting, by the second SDK called by the first target payment application program, with the remote payment platform to complete a payment comprises:
querying, by the second SDK, a locally stored multi-party payment function activation sign bit to determine whether the first target payment application program in the user terminal has activated a multi-party payment function;
when the multi-party payment function is activated in the first target payment application program in the user terminal, interacting, by the second SDK, with the remote payment platform to complete the payment.
Collicoat makes these teachings in a related endeavor ([0005] “One embodiment provides a method for executing an electronic transaction by a parallel transaction system, comprising: receiving, by a parallel transaction system, an electronic transaction request of a payment vehicle; determining,
by the parallel transaction system, a type of the payment vehicle, the type of the payment vehicle being at least one of an open loop type, a closed loop type, or a parallel type; executing, by the parallel transaction system, an open-loop transaction, a closed-loop transaction, and/or a parallel transaction, based on the determined type of the payment vehicle; and completing, by the parallel transaction system, the electronic transaction request”; [0039] “The systems 100 and 200 may utilizes a software development kit (SDK) server (not shown) that may provide various SDK functions (or SDK) that the merchant system 120 may utilize to configure the POS terminal 110 and the browser 115 to facilitate communication with the processing system 130. Further, the systems 100 and 200 may utilize an application programming interface (API) server (not shown) that may provide various APIs that the merchant system 120 may to configure the POS terminal 110 and the browser 115 to facilitate communication with the processing system 130.”). It would have been obvious to one of ordinary skill in the art at the time of the invention to incorporate the teachings of Collicoat to the invention of Sarjaz as described above for the motivation of providing an entity with flexibility in the processing of remote payments.
Re Claim 5: (Original) Sarjaz in view of Collicoat in view of Bodalia discloses the method according to claim 4. Regarding the limitation(s) comprising:
wherein, before querying, by the second SDK, a locally stored multi-party payment function activation sign bit to determine whether the first target payment application program in the user terminal has activated the multi-party payment function, the method further comprises: interacting, through the second SDK called by the first target payment application program, with the remote payment platform to complete an initialization of the second SDK.
Collicoat makes these teachings in a related endeavor ([0005] “One embodiment provides a method for executing an electronic transaction by a parallel transaction system, comprising: receiving, by a parallel transaction system, an electronic transaction request of a payment vehicle; determining,
by the parallel transaction system, a type of the payment vehicle, the type of the payment vehicle being at least one of an open loop type, a closed loop type, or a parallel type; executing, by the parallel transaction system, an open-loop transaction, a closed-loop transaction, and/or a parallel transaction, based on the determined type of the payment vehicle; and completing, by the parallel transaction system, the electronic transaction request”; [0039] “The systems 100 and 200 may utilizes a software development kit (SDK) server (not shown) that may provide various SDK functions (or SDK) that the merchant system 120 may utilize to configure the POS terminal 110 and the browser 115 to facilitate communication with the processing system 130. Further, the systems 100 and 200 may utilize an application programming interface (API) server (not shown) that may provide various APIs that the merchant system 120 may to configure the POS terminal 110 and the browser 115 to facilitate communication with the processing system 130.”). It would have been obvious to one of ordinary skill in the art at the time of the invention to incorporate the teachings of Collicoat to the invention of Sarjaz as described above for the motivation of providing an entity with flexibility in the processing of remote payments.
Re Claim 6: (Original) Sarjaz in view of Collicoat in view of Bodalia discloses the method according to claim 4. Regarding the limitation(s) comprising:
wherein, when the multi-party payment function is activated in the first target payment application program in the user terminal, interacting, by the second SDK, with the remote payment platform to complete the payment comprises:
when the first target payment application program in the user terminal activates the multi- party payment function, determining, by the second SDK, whether a user has logged into the first target payment application program;
Collicoat makes these teachings in a related endeavor ([0005] “One embodiment provides a method for executing an electronic transaction by a parallel transaction system, comprising: receiving, by a parallel transaction system, an electronic transaction request of a payment vehicle; determining,
by the parallel transaction system, a type of the payment vehicle, the type of the payment vehicle being at least one of an open loop type, a closed loop type, or a parallel type; executing, by the parallel transaction system, an open-loop transaction, a closed-loop transaction, and/or a parallel transaction, based on the determined type of the payment vehicle; and completing, by the parallel transaction system, the electronic transaction request”; [0039] “The systems 100 and 200 may utilizes a software development kit (SDK) server (not shown) that may provide various SDK functions (or SDK) that the merchant system 120 may utilize to configure the POS terminal 110 and the browser 115 to facilitate communication with the processing system 130. Further, the systems 100 and 200 may utilize an application programming interface (API) server (not shown) that may provide various APIs that the merchant system 120 may to configure the POS terminal 110 and the browser 115 to facilitate communication with the processing system 130.”). It would have been obvious to one of ordinary skill in the art at the time of the invention to incorporate the teachings of Collicoat to the invention of Sarjaz as described above for the motivation of providing an entity with flexibility in the processing of remote payments.
Regarding the limitation comprising:
when the user has logged into the first target payment application program, interacting, by the second SDK, with the remote payment platform to complete the payment.
Bodalia makes these teachings in a related endeavor ([0029] “… In at least one example, the P2P payment platform can transfer funds from an account of the customer, maintained by the P2P payment platform, to an account of the merchant, maintained by the payment processing platform thereby facilitating a contactless (P2P) payment for the transaction. That is, based at least in part on receiving an indication of which payment method a user ( e.g., customer or merchant) intends to use for a transaction, techniques described herein utilize an integration between a P2P payment platform and payment processing platform (which can be a first- or third-party integration)”; [0282] “In some examples, a component may include one or more application programming interfaces (APIs) to perform some or all of its functionality ( e.g., operations). In at least one example, a software developer kit (SDK) can be provided by the service provider to allow third-party developers to include service provider functionality and/or avail service provider services in association with their own third-party applications. Additionally or alternatively, in some examples, the service provider can utilize a SDK to integrate third-party service provider functionality into its applications. That is, API(s) and/or SDK(s) can enable third-party developers to customize how their respective third-party applications interact with the service provider or vice versa.”). It would have been obvious to one of ordinary skill in the art at the time of the invention to incorporate the teachings of Bodalia to the invention of Sarjaz as described above for the motivation of facilitating remote payments in a secure manner.
Re Claim 7: (Currently Amended) Sarjaz in view of Collicoat in view of Bodalia discloses the method according to claim 6. Regarding the limitation(s) comprising:
when the first target payment application program in the user terminal has not activated the multi-party payment function or when the user has not logged into the first target payment application program, calling up a second target payment application program through the second SDK of the first target payment application program, wherein the second SDK of the second target payment application program interacts with the remote payment platform to complete the payment, and the second target payment application program is a designated payment application program or a payment application program with a second highest priority in the intersection of the first payment application list and the second payment application list; or ([0052] “Applications 142A-B may be better discovered through the e-commerce platform 100 through development of an application taxonomy (categories) that enable applications to be tagged according to a type of function it performs for a merchant; through application data services that support searching, ranking, and recommendation models; through application discovery interfaces …”)
when the first target payment application program in the user terminal has not activated the multi-party payment function or when the user has not logged into the first target payment application program, interacting with the remote payment platform through the second SDK of the first target payment application program to display a payment selection page, wherein the payment selection page includes an identifier of a payment application program that has activated the multi-party payment function; ([0052] “Applications 142A-B may be better discovered through the e-commerce platform 100 through development of an application taxonomy (categories) that enable applications to be tagged according to a type of function it performs for a merchant; through application data services that support searching, ranking, and recommendation models; through application discovery interfaces …”)
Regarding the limitation(s) comprising:
in response to a user's first selection input, determining a third target payment application program in the payment selection page; and
calling up the third target payment application program through the second SDK of the first target payment application program, so that a second SDK of the third target payment application program interacts with the remote payment platform to complete the payment; or
when the first target payment application program in the user terminal has not activated the multi-party payment function or when the user has not logged into the first target payment application program, displaying first guidance information and/or second guidance information, wherein the first guidance information is used to guide a user to activate the multi-party payment function for the first target payment application program, and the second guidance information is used to guide the user to log into the first target payment application program;
Collicoat makes these teachings in a related endeavor ([0005] “One embodiment provides a method for executing an electronic transaction by a parallel transaction system, comprising: receiving, by a parallel transaction system, an electronic transaction request of a payment vehicle; determining,
by the parallel transaction system, a type of the payment vehicle, the type of the payment vehicle being at least one of an open loop type, a closed loop type, or a parallel type; executing, by the parallel transaction system, an open-loop transaction, a closed-loop transaction, and/or a parallel transaction, based on the determined type of the payment vehicle; and completing, by the parallel transaction system, the electronic transaction request”; [0039] “The systems 100 and 200 may utilizes a software development kit (SDK) server (not shown) that may provide various SDK functions (or SDK) that the merchant system 120 may utilize to configure the POS terminal 110 and the browser 115 to facilitate communication with the processing system 130. Further, the systems 100 and 200 may utilize an application programming interface (API) server (not shown) that may provide various APIs that the merchant system 120 may to configure the POS terminal 110 and the browser 115 to facilitate communication with the processing system 130.”). It would have been obvious to one of ordinary skill in the art at the time of the invention to incorporate the teachings of Collicoat to the invention of Sarjaz as described above for the motivation of providing an entity with flexibility in the processing of remote payments.
Regarding the limitation comprising:
when the first target payment application program has activated the multi-party payment function and the user has logged into the first target payment application program, the second SDK of the first target payment application program interacting with the remote payment platform to complete the payment.
Bodalia makes these teachings in a related endeavor ([0029] “… In at least one example, the P2P payment platform can transfer funds from an account of the customer, maintained by the P2P payment platform, to an account of the merchant, maintained by the payment processing platform thereby facilitating a contactless (P2P) payment for the transaction. That is, based at least in part on receiving an indication of which payment method a user ( e.g., customer or merchant) intends to use for a transaction, techniques described herein utilize an integration between a P2P payment platform and payment processing platform (which can be a first- or third-party integration)”; [0282] “In some examples, a component may include one or more application programming interfaces (APIs) to perform some or all of its functionality ( e.g., operations). In at least one example, a software developer kit (SDK) can be provided by the service provider to allow third-party developers to include service provider functionality and/or avail service provider services in association with their own third-party applications. Additionally or alternatively, in some examples, the service provider can utilize a SDK to integrate third-party service provider functionality into its applications. That is, API(s) and/or SDK(s) can enable third-party developers to customize how their respective third-party applications interact with the service provider or vice versa.”). It would have been obvious to one of ordinary skill in the art at the time of the invention to incorporate the teachings of Bodalia to the invention of Sarjaz as described above for the motivation of facilitating remote payments in a secure manner.
Re Claim 8: (Original) Sarjaz in view of Collicoat in view of Bodalia discloses the method according to claim 1. Sarjaz further discloses:
calling the second SDK to monitor, through a payment pre-protocol interface or a monitoring interface, whether a payment cancellation action occurs; ([0064] “… merchant may then review and fulfill ( or cancel) the order.”)
when a payment cancellation action occurs, calling the second SDK to interact with the remote payment platform to display a payment selection page, wherein the payment selection page includes an identifier of a payment application program that has activated a multi-party payment function; ([0049] “… e-commerce platform 100 may provide for a platform payment facility 120, which is another example of a component that utilizes data from the commerce management engine 136”)
Regarding the limitation comprising:
in response to a second selection input by a user, determining a fourth target payment application program in the payment selection page;
Collicoat makes these teachings in a related endeavor ([0005] “One embodiment provides a method for executing an electronic transaction by a parallel transaction system, comprising: receiving, by a parallel transaction system, an electronic transaction request of a payment vehicle; determining,
by the parallel transaction system, a type of the payment vehicle, the type of the payment vehicle being at least one of an open loop type, a closed loop type, or a parallel type; executing, by the parallel transaction system, an open-loop transaction, a closed-loop transaction, and/or a parallel transaction, based on the determined type of the payment vehicle; and completing, by the parallel transaction system, the electronic transaction request”; [0039] “The systems 100 and 200 may utilizes a software development kit (SDK) server (not shown) that may provide various SDK functions (or SDK) that the merchant system 120 may utilize to configure the POS terminal 110 and the browser 115 to facilitate communication with the processing system 130. Further, the systems 100 and 200 may utilize an application programming interface (API) server (not shown) that may provide various APIs that the merchant system 120 may to configure the POS terminal 110 and the browser 115 to facilitate communication with the processing system 130.”). It would have been obvious to one of ordinary skill in the art at the time of the invention to incorporate the teachings of Collicoat to the invention of Sarjaz as described above for the motivation of providing an entity with flexibility in the processing of remote payments.
Regarding the limitation comprising:
calling up the fourth target payment application program through the second SDK of the first target payment application program, so that a second SDK of the fourth target payment application program interacts with the remote payment platform to complete the payment.
Bodalia makes these teachings in a related endeavor ([0029] “… In at least one example, the P2P payment platform can transfer funds from an account of the customer, maintained by the P2P payment platform, to an account of the merchant, maintained by the payment processing platform thereby facilitating a contactless (P2P) payment for the transaction. That is, based at least in part on receiving an indication of which payment method a user ( e.g., customer or merchant) intends to use for a transaction, techniques described herein utilize an integration between a P2P payment platform and payment processing platform (which can be a first- or third-party integration)”; [0282] “In some examples, a component may include one or more application programming interfaces (APIs) to perform some or all of its functionality ( e.g., operations). In at least one example, a software developer kit (SDK) can be provided by the service provider to allow third-party developers to include service provider functionality and/or avail service provider services in association with their own third-party applications. Additionally or alternatively, in some examples, the service provider can utilize a SDK to integrate third-party service provider functionality into its applications. That is, API(s) and/or SDK(s) can enable third-party developers to customize how their respective third-party applications interact with the service provider or vice versa.”). It would have been obvious to one of ordinary skill in the art at the time of the invention to incorporate the teachings of Bodalia to the invention of Sarjaz as described above for the motivation of facilitating remote payments in a secure manner.
Re Claim 9: (Original) Sarjaz in view of Collicoat in view of Bodalia discloses the method according to claim 1. Sarjaz further discloses:
wherein calling up, by the first SDK, a first target payment application program comprises:
sending, by the first SDK, a call-up message to the first target payment application program; ([0051] “In embodiments, applications 142A-B may deliver functionality to a merchant through the interface 140A-B, such as where an application 142A-B is able to surface transaction data to a merchant ( e.g., App: "Engine, surface my app data in mobile and web admin using the embedded app SDK"), and/or where the commerce management engine 136 is able to ask the application to perform work on demand …”; [0057] “… Integration applications may include applications that provide useful integrations that participate in the running of a business, such as … payment gateways.”; [0043] The e-commerce platform 100 may provide for a communications facility 129 and associated merchant interface for providing electronic communications and marketing, such as utilizing an electronic messaging aggregation facility for collecting and analyzing communication interactions between merchants, customers, merchant devices 102, customer devices 150, POS devices 152, and the like, to aggregate and analyze the communications”)
in response to the call-up message, the first target payment application program starting and directly jumping to a page indicated by the call-up message. ([0049] “… e-commerce platform 100 may provide for a platform payment facility 120, which is another example of a component that utilizes data from the commerce management engine 136”)
Re Claim 10: (Original) Claim 10, as best understood by the Examiner, encompasses the same or substantially the same scope as claim 1. Accordingly, claim 10 is rejected in the same or substantially the same manner as claim 1.
Re Claim 11: (Original) Claim 11, as best understood by the Examiner, encompasses the same or substantially the same scope as claim 2. Accordingly, claim 11 is rejected in the same or substantially the same manner as claim 2.
Re Claim 12: (Original) Claim 12, as best understood by the Examiner, encompasses the same or substantially the same scope as claim 3. Accordingly, claim 12 is rejected in the same or substantially the same manner as claim 3.
Re Claim 13: (Original) Claim 13, as best understood by the Examiner, encompasses the same or substantially the same scope as claim 4. Accordingly, claim 13 is rejected in the same or substantially the same manner as claim 4.
Re Claim 14: (Original) Claim 14, as best understood by the Examiner, encompasses the same or substantially the same scope as claim 5. Accordingly, claim 14 is rejected in the same or substantially the same manner as claim 5.
Re Claim 15: (Original) Claim 15, as best understood by the Examiner, encompasses the same or substantially the same scope as claim 6. Accordingly, claim 15 is rejected in the same or substantially the same manner as claim 6.
Re Claim 16: (Currently Amended) Claim 16, as best understood by the Examiner, encompasses the same or substantially the same scope as claim 7. Accordingly, claim 16 is rejected in the same or substantially the same manner as claim 7.
Re Claim 17: (Currently Amended) Claim 17, as best understood by the Examiner, encompasses the same or substantially the same scope as claim 8. Accordingly, claim 17 is rejected in the same or substantially the same manner as claim 8.
Re Claim 18: (Original) Claim 18, as best understood by the Examiner, encompasses the same or substantially the same scope as claim 1. Accordingly, claim 18 is rejected in the same or substantially the same manner as claim 1.
Re Claims 19 - 23: (Canceled)
Re Claim 24: (New) Claim 24, as best understood by the Examiner, encompasses the same or substantially the same scope as claim 2. Accordingly, claim 24 is rejected in the same or substantially the same manner as claim 2.
Re Claim 25: (New) Claim 25, as best understood by the Examiner, encompasses the same or substantially the same scope as claim 3. Accordingly, claim 25 is rejected in the same or substantially the same manner as claim 3.
Conclusion
The prior art(s) made of record and not relied upon is/are considered pertinent to applicant's disclosure.
Hilliar (US 2016/0219055 A1) discloses authorizing access to an application library. To prevent malicious code from accessing security sensitive functions implemented in a private portion of an application, accesses to the private portion are performed using a secure session established within the application between the private portion and a public portion of the same application. An authorization key can be shared between the public portion and the private portion. When the public portion attempts to invoke a function implemented in the private portion, a secure session is set up by generating a session ID, combining the session ID and the authorization key in a key derivation function to generate a conversation key, and using the conversation key to encrypt the function call from the public potion. The private portion can then decrypt a properly encrypted function call and invoke the appropriate function.
McCarthy et al. (US 11,605,065 B2) discloses systems and methods for secure remote commerce. Embodiments may provide systems, methods and computer program code to facilitate a secure remote transaction and may include detecting an event identifying initiation of a checkout process involving a transaction between a consumer and a merchant, identifying a secure remote commerce system to use in facilitating the transaction, the secure remote commerce system storing a consumer
profile including information identifying at least a first payment card of the consumer. In some embodiments, a checkout user interface displayed to the consumer is modified based on information from the consumer profile to display information associated with the at least one payment card. A checkout request from the consumer and a payload is obtained from the secure remote commerce system including information identifying the at least first payment card, the merchant and transaction details.
Claims 1-18, 24-25 are rejected.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Clifford Madamba whose telephone number is 571-270-1239. The examiner can normally be reached on Mon-Thu 7:30-5:00 EST Alternate Fridays.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Ryan Donlon, can be reached at 571-272-3602. 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.
/CLIFFORD B MADAMBA/Primary Examiner, Art Unit 3692
Prosecution Insights