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 .
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-21 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 method (claims 1-10 and 21), a system (claims 11-18), or one or more non-transitory computer-readable storage media (claims 19-20) and thus fall into at least one statutory category enumerated in 35 U.S.C. § 101 (Step 1 – yes).
However, claim 1 and (claims 11 and 20, in substance) recite(s):
generating, […], a data object for an exchange card, the data object comprising one or more data field-value pairs each corresponding to a different parameter of the one or more parameters, detecting, […] an event regarding the exchange card; generating, […] a message regarding the event in the format input into the one or more forms; and responsive to detecting the event, […] transmitting/forwarding, the message regarding the event in the format
This is an abstract idea that falls under the grouping of Commercial or Legal Interactions (marketing or sales activities or behaviors, and business relations). (see MPEP § 2106.04(a)(2), subsection II.B) because the claim recites receiving parameters of a card program, generating data for an exchange card, detecting an event regarding the exchange card, and transmitting/forwarding a message regarding the event.
This judicial exception is not integrated into a practical application because the additional elements include: a user interface, a communication network interface to interface with a communication network; a memory; and one or more processors, the one or more processors to: establish a connection with a remote computing device, a computing system; issuing processor computing system; a pointer to a computing device of the computing system, a computing device of the computing system.
The Applicant’s specification at ¶[0207] explains:
Each processor may be implemented as one or more general-purpose processors, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs), or other suitable electronic data processing components structured to execute instructions provided by memory. The one or more processors may take the form of a single core processor, multi-core processor (e.g., a dual core processor, triple core processor, quad core processor), microprocessor. In some embodiments, the one or more processors may be external to the apparatus, for example the one or more processors may be a remote processor (e.g., a cloud based processor). Alternatively, or additionally, the one or more processors may be internal and/or local to the apparatus.
and at ¶[0208] of the specification:
Each memory device may include non- transient volatile storage media, non-volatile storage media, non-transitory storage media (e.g., one or more volatile and/or non-volatile memories), etc. In some embodiments, the non-volatile media may take the form of ROM, flash memory (e.g., flash memory such as NAND, 3DNAND, NOR, 3D NOR), EEPROM, MRAM, magnetic storage, hard discs, optical discs, etc. In other embodiments, the volatile storage media may take the form of RAM, TRAM, ZRAM, etc.
Thus, the additional elements are recited at a high-level of generality and amount to no more than mere instructions to apply the abstract idea using generic computer and computer networking components or amount to merely using a computer as a tool to perform the abstract idea. See MPEP 2106.05(f). Accordingly, these additional elements do not integrate the abstract idea into a practical application. The claim is directed to an abstract idea.
The claim does not include additional elements, individually and in combination, that are sufficient to amount to significantly more than the judicial exception because, as discussed above with respect to integration of the abstract idea into a practical application, the additional elements of using generic computer components or merely using a computer as a tool to perform the abstract ideas amount to no more than mere instructions to apply the exception using generic computer and computer network components. Mere instructions to apply an exception using generic computer components cannot provide an inventive concept. Thus, the claim is not patent-eligible. Independent claims 11 and 19 recite substantially the same limitations as independent claim 11 but are recite a method reciting the same functionality (claim 1) or and as a computer readable medium storing instructions for executing the same functionality, and thus does not integrate the abstract idea into a practical application or provide significantly more.
Regarding claim(s) 2, 12, 20, the claims recite the use of URL/webhooks used for computing with a computing device. These elements are recited at a high level of generality and do not integrate the abstract idea into a practical application or provide significantly more.
Regarding claim(s) 3 and 13, the claims recite a plurality of pointers, each of the pointers corresponding to a different event type. This merely implements the abstract idea of routing card program events using generic computer networking elements of pointers, and does not integrate the abstract idea into a practical application or provide significantly more.
Regarding claim(s) 4 and 14, the claims recite various event categories of exchange card events and is part of the abstract idea and does not add any additional elements to the abstract idea.
Regarding claim(s) 5 and 15, the claims recite determining an event type of the detected event and transmitting and routing a message regarding the event . The additional elements include transmitting the message by processors using the pointer and this amounts to using a computer as tool to carry out the abstract idea and does not integrate the abstract idea into a practical application or provide significantly more.
Regarding claim(s) 6 and 16, the claims recite receiving and transmitting a unique identifier for the exchange card, receiving a token for the exchange card, and mapping the token for the exchange card to the unique identifier for the exchange card. This is a mental process that can be done with pen and paper, does not integrate the abstract idea into a practical application or provide significantly more. The addition of generic processors to perform the abstract idea does not integrate the abstract idea into a practical application or provide significantly more.
Regarding claim(s) 7 and 17, the claims introduce a ledger and receiving and transmitting information associated with the exchange card. This is part of the abstract idea. The addition of generic computer elements to perform the abstract idea does not integrate the abstract idea into a practical application or provide significantly more.
Regarding claim(s) 8 and 18, the claims recite updating the ledger based on exchange data .This is part of the abstract idea. The addition of generic computer elements to perform the abstract idea does not integrate the abstract idea into a practical application or provide significantly more.
Regarding claim(s) 9 and 10, These claims recite presenting forms configured to receive a format for communication, receiving the format as input, and generating and transmitting the message in the inputted format. .This is part of the abstract idea. The addition of generic computer elements (processor, computing system, and pointer) to perform the abstract idea does not integrate the abstract idea into a practical application or provide significantly more.
Regarding claims 21, the claim further comprises an API configured to facilitate communication and wherein generating the message regarding the event in the format is performed using the API. An API is a generic computer element and the addition of generic computer elements to perform the abstract idea does not integrate the abstract idea into a practical application or provide significantly more.
Accordingly, each of claims 1-21 are rejected under 35 U.S.C. § 101 as being patent-ineligible.
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 (i.e., changing from AIA to pre-AIA ) 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.
The factual inquiries 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, 2, 6-8, 11, 12, 16-21 are rejected under 35 U.S.C. § 103 as being unpatentable over THAIRU (US 20240037513 A1 to Thairu; Timothy et al.) in view of PHILLIPS (US 20170132627 A1 to Phillips; Ashley et al.) in further view of DIWAKARAN (US 11271987 B1 to Diwakaran; Umakanthan).
Regarding claim(s) 1, 11, 19,
THAIRU discloses:
A computer-implemented method[/system/[o]ne or more non-transitory computer-readable storage media having instructions stored thereon] (THAIRU: ¶[0015]: computer system; ¶[0121]: system, method, and process […] can be implemented as software stored in main memory 850 or read only memory 820 and executed by processor 810.), THAIRU ¶[0180]: one or more non-transitory computer readable storage media having instructions stored thereupon) comprising:
establishing, by one or more processors (THAIRU: ¶[0117]:data processing system including bus.internal communication means, processor coupled to the bus, RAM or other memory, ROM, data storage device ),
a connection with a remote computing device of a computing system (THAIRU: ¶[0164]: Receive interface 1901 and transmit interface 1902 communication transaction information)
connected with an issuing processor computing system (THAIRU: ¶[0042]: The Service Provider (100) uses the Single-use Token (350) to submit a charge request to Stripe; ¶[0074]: Transaction information is sent via signals 303 from acquirer 302 to a paying network 304 (e.g., Visa); ¶[0075]: Paying network 304 sends the information via signals 305 to a payment processor 306, which is also the issuer of card 340, to be approved or declined synchronously. In one embodiment, signals 305 comprise raw 8583 messages.);
presenting, by the one or more processors, a user interface at the remote computing device over the connection (THAIRU: ¶[0129]: cards and their issuance are managed using an API and a dashboard that is generated and operated using a dashboard module including set rules through the dashboard; ¶[0037]: A Service Provider's Customer (200) uses an internet-enabled browser (210) to visit the Service Provider's site. In one embodiment, Customer (200) is served a Stripe.js enabled Payment Form (110) using standard web technologies; ¶[0037]: The Customer (200) enters the necessary information),
[…]
receiving, by the one or more processors from the remote computing device (THAIRU: ¶[0129]: cards and their issuance are managed using an API and a dashboard that is generated and operated using a dashboard module including set rules through the dashboard; ¶[0037]: A Service Provider's Customer (200) uses an internet-enabled browser (210) to visit the Service Provider's site. In one embodiment, Customer (200) is served a Stripe.js enabled Payment Form (110) using standard web technologies; ¶[0037]: The Customer (200) enters the necessary information),
[…]
one or more parameters of a card program, (THAIRU: figure 10: pay curl api issuing/cardholders, “name, email, billing name billing line, status=active; figure 11: object: issuing-cardholder; figure 10 and ¶[0138]: a Cardholder with a name, billing address, entity type, and any additional information is created as shown in FIG. 10; ¶[0140]: After creating a cardholder, a card that is assigned to them is created. In one embodiment, this is performed by generating a request to a card creation module (1902 of FIG. 19) of the payment processor. In one embodiment, this request contains the ID of the Cardholder object, currency, and card type (either physical or virtual). In one embodiment, if creating a physical card, a shipping address is required.)
and a pointer to a computing device of the computing system (THAIRU [0089]: For the issuing.authorization.created (401) and its associated hold state (402), in one embodiment, when an activated card is charged, the payment processor sends an issuing.authorization.request webhook in real-time to a universal resource locator (URL) of the customer, which represents a designated endpoint of the customer of the payment processor for handling responses to the authorizations. The endpoint's response controls whether the authorization is approved or declined. In one embodiment, the customer's endpoint approves a transaction by responding to the authorization with a HTTP status code 200 and declines a transaction by responding to the authorization with HTTP status code 403, with all other status codes resulting in declines and logged as warnings; THAIRU: ¶[0125] and figure 9: [0125]:int The intermediary platform 1000 provides services to its customers, which are the payment processor users 1002),
[…]
the one or more parameters comprising an identification of the issuing processor computing system (THAIRU: ¶[0089]: the payment processor sends an issuing.authorization.request webhook in real-time to a universal resource locator (URL) of the customer, which represents a designated endpoint of the customer of the payment processor for handling responses to the authorizations; ¶[0154]: a check is made to determine if the user has configured an authorization endpoint (e.g., a platform) to handle authorization requests; figure 10: $ pay curl api /v1/issuing/cardholders; ¶[0139]: in response to the above curl, a card holder creation module (e.g., 1901 of FIG. 19) of the system of the payment processor returns aCardholder object that contains the information that was provided by a user, and sends an issuing_card.created webhook event to the user; figure 12; $ pay curl api /v1/issuing/cards (URL);
generating, by the one or more processors, a data object for an exchange card (THAIRU: [0139]: in response to the above curl, a card holder creation module returns a Cardholder object that contains the information that was provided by a user, and sends an issuing_card.created webhook event to the user. An example of the Cardholder object is shown in FIG. 11.; [0140]: a card is created. In one embodiment, this is performed by generating a request to a card creation module (1902 of FIG. 19) of the payment processor. In one embodiment, this request contains the ID of the Cardholder object, currency, and card type (either physical or virtual). In one embodiment, if creating a physical card, a shipping address is required),
the data object comprising one or more data field-value pairs each corresponding to a different parameter of the one or more parameters (THAIRU: figure 11: data object composed of field-value pairs such as “object” – “issuing_cardholder”; city-San Francisco, country – US; figure 10: name-Jenny Rosen),
the data object corresponding to the issuing processor computing system (THAIRU: ¶[0139]: card holder creation module (e.g., 1901 of FIG. 19) of the system of the payment processor returns aCardholder object that contains the information that was provided by a user, and sends an issuing_card.created webhook event to the user. An example of the Cardholder object is shown in FIG. 11.; (THAIRU: figure 11: data object “object”:“issuing_cardholder”);
detecting, by the one or more processors, an event regarding the exchange card (THAIRU: figure 3: “Start”; Card Swiped; ¶[0074]: Referring to FIG. 3, the data flow begins with an acquirer 302 (e.g., a merchant) acquiring card information 301. This may occur in a number of ways, such as, for example, by swiping a card 340 by an acquirer 302, inserting the card into a reader so that an EMV chip is read, wirelessly or other contactless transmission of card information 301, etc.);
generating, by the one or more processors, a message regarding the event (THAIRU: ¶[0141]: the payment processor returns an Issuing Card object upon creation and sends an issuing_card.created event to the user. An example of the Issuing Card object is shown in FIG. 12.; [0144]: In one embodiment, any card event that results in funds entering or leaving a payment processor account, such as a completed purchase, refund, or ATM withdrawal, is represented by a Transaction object. In one embodiment, transactions contain information about the card used, the cardholder, and the business to which it relates.; ¶[0158]: . Once configured, the payment processor sends events any time an authorization request is received. This event contains an Authorization object with information about the authorization request, such as, for example, the amount, card used, and business information (merchant_data). An example is shown in FIG. 17.; ¶[0077]: In one embodiment, once the card is activated, the payment processor's customer automatically receives webhooks for every authorization. In one embodiment, the webhook having the authorization request comprises a POST hook. In one embodiment, the webhook contains the authorization object, which includes information such as, for example, but not limited to, the transaction amount, an indication of the card being used (e.g., a card number or identifier), and merchant properties.)
[…]
and responsive to detecting the event, automatically transmitting, by the one or more processors using the pointer, the message regarding the event , (THAIRU: [0089]: when an activated card is charged, the payment processor sends an issuing.authorization.request webhook in real-time to a universal resource locator (URL) of the customer, which represents a designated endpoint of the customer of the payment processor for handling responses to the authorizations; [0077]:once the card is activated, the payment processor's customer automatically receives webhooks for every authorization. In one embodiment, the webhook having the authorization request comprises a POST hook. In one embodiment, the webhook contains the authorization object, which includes information such as, for example, but not limited to, the transaction amount, an indication of the card being used (e.g., a card number or identifier), and merchant properties),
[…]
wherein the computing device of the computing system forwards data of the message to the issuing processor computing system (THAIRU: [0078]: in response to the authorization request, customer 308 performs a test 310 to determine whether to approve or decline the authorization request. The results of test 310 are sent via signals 310 from customer 308 to payment processor 306; [0159]: The platform then approves or declines the request with the Authorization object's ID.; figure 17: "id": "iauth_lCmMk2IyNTgCDVfzFKICmBgU"; figure 18: $ pay curl api/v1/issuing/authorizations/iauth_lCmMk2IyNTgCDVfzFKICmBgU/approve \).
THAIRU does not disclose, which PHILLIPS however teaches:
the user interface comprising one or more forms configured to receive an identification of a format for communication between the one or more processors and a computing device of the computing system (PHILLIPS: figure 3a: choices of eCommerce Platform and Payment provider in user interface for use with an integration platform (see PHILLIPS ¶[0010]); ¶[0037]: an integration platform may present the merchant with a web page with a menu or other presentation which permits the merchant to select from a variety of electronic commerce platforms; ¶[0093]: may provide an interface to multiple electronic commerce platforms 1350, and may also provide a comma separated value (CSV) interface 1360 which may allow merchants to upload lists of products in a structured data format; ¶[0093]: provide or mediate access between electronic commerce platforms 1350, CSV interface 1360, product feed interface 1370, and the integration platform core API; ¶[0093]: product feed e 1370 may be used by merchants to provide a feed, such as a RSS (really simple syndication) feed or XML feed);
the identification of the format (PHILLIPS: ¶[0093]: may provide an interface to multiple electronic commerce platforms 1350, and may also provide a comma separated value (CSV) interface 1360 which may allow merchants to upload lists of products in a structured data format; ¶[0093]: provide or mediate access between electronic commerce platforms 1350, CSV interface 1360, product feed interface 1370, and the integration platform core API; ¶[0093]: product feed e 1370 may be used by merchants to provide a feed, such as a RSS (really simple syndication) feed or XML feed),
It would have been obvious to one of ordinary skill in the art before the time of filing to combine/modify the system/method of THAIRU, which discloses systems and methods of processing commercial transactions (THAIRU ¶[0003]) with the technique of PHILLIPS, in order to standardize interactions (PHILLIPS ¶[0029]) in electronic commerce).
THAIRU does not expressly disclose the following limitations, which DIWAKARAN however, teaches:
as input into the one or more forms of the user interface (DIWAKARAN: see figure 3 “CREATE WEBHOOK” form and item 310 “TRANSFORM SCRIPT” field; col. 8, ll. 49-65: “The example web-based UI view 300 includes an event name space 302, a subscription group space 304, a webhook URL space 306, [(pointer)] a subscription filter space 308, a transform script space 310 [(format)], and a HTTP headers space 312.”; col. 9, ll. 20-26: “The transform script space 310 is used to configure a transform script that is associated with payload mapping. The transform script is used to transform the payload from the format of the publishing web-application 110 to the format of the one or more subscriber web-applications 104A-N. In the example webhook subscription configuration,” ),
in the format input into the one or more forms of the user interface (DIWAKARAN: col. 2, ll. 14-16: (b) generating a transformed HTTP message from the HTTP message using the HTTP message subscription associated with the event; col. 9, ll. 20-25: The transform script is used to transform the payload from the format of the publishing web-application 110 to the format of the one or more subscriber web-applications 104A-N; see figure 3 “CREATE WEBHOOK” form and item 310 “TRANSFORM SCRIPT” field);
in the format to the computing device of the computing system (DIWAKARAN: col. 2, ll. 14-16: (b) generating a transformed HTTP message from the HTTP message using the HTTP message subscription associated with the event; col. 9, ll. 20-25: The transform script is used to transform the payload from the format of the publishing web-application 110 to the format of the one or more subscriber web-applications 104A-N; see figure 3 “CREATE WEBHOOK” form and item 310 “TRANSFORM SCRIPT” field)
It would have been obvious to one of ordinary skill in the art before the time of filing to combine/modify the system/method of THAIRU, which discloses systems and methods of processing commercial transactions (THAIRU ¶[0003]) using networks and payment networks (THAIRU ¶[0109] and ¶[0153]) with the technique of DIWAKARAN, in order to enable communication between parties in a synchronized and a uniform way (DIWAKARAN col. 1, ll. 35-40).
Regarding claim(s) 2, 12, 20,
THAIRU, PHILLIPS, and DIWAKARAN teaches the limitations of claims 1, 11, and 19.
THAIRU further discloses:
wherein receiving the pointer comprises: receiving, by the one or more processors, a uniform resource locator configured to operate with a webhook to communicate with the computing device of the computing system (THAIRU: ¶[0089]: For the issuing.authorization.created (401) and its associated hold state (402), in one embodiment, when an activated card is charged, the payment processor sends an issuing.authorization.request webhook in real-time to a universal resource locator (URL) of the customer, which represents a designated endpoint of the customer of the payment processor for handling responses to the authorizations.).
Regarding claim(s) 6 and 16,
THAIRU, PHILLIPS, and DIWAKARAN teaches the limitations of claims 1 and 11.
THAIRU further discloses:
receiving, by the one or more processors, a unique identifier for the exchange card (THAIRU: ¶[0140]: After creating a cardholder, a card that is assigned to them is created. In one embodiment, this is performed by generating a request to a card creation module (1902 of FIG. 19) of the payment processor. In one embodiment, this request contains the ID of the Cardholder object, currency, and card type (either physical or virtual));
and transmitting, by the one or more processors, the unique identifier for the exchange card to the computing system (THAIRU: ¶[0140]: In one embodiment, this request contains the ID of the Cardholder object, currency, and card type (either physical or virtual); ¶[0141]: In one embodiment, the payment processor returns an Issuing Card object upon creation and sends an issuing_card.created event to the user. An example of the Issuing Card object is shown in FIG. 12.),
wherein the computing system is configured to: receive a token for the exchange card from the issuing processor computing system; and map the token for the exchange card to the unique identifier for the exchange card (THAIRU: ¶[0040]: If authorized, Stripe (300) will generate and return a secure, Single-use Token (350) to the Customer's Browser (210) that represents the customer's payment information (220) but doesn't leak any sensitive information.; the payment processor (here, Stripe (300)) creates the Token (350) from the payment information sent by the client-side application, wherein the Token (350) functions as a proxy for the payment information (220)); ¶[0074]: the data flow begins with an acquirer 302 (e.g., a merchant) acquiring card information 301. This may occur in a number of ways, such as, for example, by swiping a card 340 by an acquirer 302, inserting the card into a reader so that an EMV chip is read, wirelessly or other contactless transmission of card information 301, etc. These operations may occur at a retail location. Transaction information is sent via signals 303 from acquirer 302 to a paying network 304 (e.g., Visa). In one embodiment, signals 303 include transaction information. In one embodiment, the transaction information includes one or more of a number indicative of an account (e.g., a token, etc.)).
Regarding claim(s) 7 and 17,
THAIRU, PHILLIPS, and DIWAKARAN teaches all of the limitations of the parent claims from which these claim(s) depend (claims 1, 6, 11, 16), as set forth above.
THAIRU further discloses:
wherein receiving the unique identifier for the exchange card comprises receiving the unique identifier (THAIRU: ¶[0077]: the payment processor's customer automatically receives webhooks for every authorization. In one embodiment, the webhook having the authorization request comprises a POST hook. In one embodiment, the webhook contains the authorization object, which includes information such as, for example, but not limited to, the transaction amount, an indication of the card being used (e.g., a card number or identifier), and merchant properties.)
from a ledger computing system hosting an electronic ledger corresponding to the exchange card, and the method further comprising (THAIRU: ¶[0071]: In one embodiment, as part of handling a payment flow, when performing transactions for the service provider (Postmates), the payment processor (Stripe) is able to maintain a running balance, and provide the same to a customer such as a service provider. Such a balance can be increased at time T1 and decreased at time T3; ¶[0113]: payment processing system includes history database 706 to store transaction history. Such transaction history may include all of the customer's transactions because the payment processor is the card issuer; ¶[0112]: That is, tracking engine 705 determines when transactions associated with different payment flows are related to each other so that settlement engine 704 is able to adjust a customer's balance based on a netted amount between the related payment flows; ¶[0107]: , the operation of clearing records includes comparing transaction tracking information (e.g., tags, IDs, etc.) associated with transactions to determine which are related to each other, if any. In one embodiment, this is performed using a tracking engine of a payment processing system. When transactions are identified as being related to each other, the amounts associated with those transactions can be settled together by combining the amounts associated with the two transactions, thereby netting out individual transactions. Once a netted-out amount is available, the settlement engine of the payment processing system adjusts an available balance of the service provider.);
receiving, by the one or more processors, exchange data of a swipe event, an authorization of the swipe event, and the unique identifier for the exchange card from the computing system (THAIRU: ¶[074]: FIG. 3 illustrates a data flow for approving or rejecting a transaction in accordance with one embodiment. Referring to FIG. 3, the data flow begins with an acquirer 302 (e.g., a merchant) acquiring card information 301. This may occur in a number of ways, such as, for example, by swiping a card 340 by an acquirer 302, inserting the card into a reader so that an EMV chip is read, wirelessly or other contactless transmission of card information 301, etc. These operations may occur at a retail location. Transaction information is sent via signals 303 from acquirer 302 to a paying network 304 (e.g., Visa). In one embodiment, signals 303 include transaction information. In one embodiment, the transaction information includes one or more of a number indicative of an account (e.g., a payment card number, a token, etc.), a transaction amount, an acquirer identifier (e.g., a merchant identifier) or category, acquirer location, a statement descriptor with a card holder's application data (e.g., user activity, user location, etc.), information indicative of goods and/or services that are being acquired as part of the transaction, etc.; [0075] Paying network 304 sends the information via signals 305 to a payment processor; ¶[0076]: payment processor 306 forwards an authorization request 307 to the payment processor's customer 308, which is customer to which card 340 was issued; ¶[0078]: in response to the authorization request, customer 308 performs a test 310 to determine whether to approve or decline the authorization request. The results of test 310 are sent via signals 310 from customer 308 to payment processor 306; see also ¶[0077]: In one embodiment, once the card is activated, the payment processor's customer automatically receives webhooks for every authorization. In one embodiment, the webhook having the authorization request comprises a POST hook. In one embodiment, the webhook contains the authorization object, which includes information such as, for example, but not limited to, the transaction amount, an indication of the card being used (e.g., a card number or identifier), and merchant properties; );
and transmitting, by the one or more processors, the unique identifier with the exchange data of the swipe event to the ledger computing system based on the authorization of the swipe event (THAIRU: ¶[0144]: In one embodiment, any card event that results in funds entering or leaving a payment processor account, such as a completed purchase, refund, or ATM withdrawal, is represented by a Transaction object. In one embodiment, transactions contain information about the card used, the cardholder, and the business to which it relates; ¶[0150]: the transactions shown are filtered by specifying the ID of an issued card; [0145]: In one embodiment, when an authorization of a transaction is captured, the following actions take place simultaneously: [0146]: 1) The authorization's status transitions to closed, releasing the previously held funds. A balance transaction is created to represent this. [0147]: 2) A new Transaction object of type capture is created that deducts the purchase amount from the account balance. Another balance transaction is also created. [0148]: the payment processor also notifies the payment processor user or the platform of these changes using the issuing.authorization.updated and issuing.transactions.created webhook events. In one embodiment, most transactions contain the identifier (ID) of the original authorization as a value for authorization. ¶[0155]: Once an authorization request is approved, an Authorization object is created in a pending state, and an issuing.authorization_updated webhook event is sent. The authorized amount is deducted from the user's account balance and held reserve until the authorization is either captured or voided. If it's captured, the Authorization object's status transitions to closed, and a new transaction is created. If voided, its status transitions to reversed.; ¶[0109]: the payment processing system comprises a receive interface 701 and a transmit interface 702. Receive interface 701 and transmit interface 702 communication transaction information, including payment authorization requests and responses between the customers, merchants, service providers and paying networks; ¶[0110]: In one embodiment, the payment processing system includes an authorization processor 703 for authorizing transactions and funding transfers, and performs other authorizations functions; ¶[0111]: the payment processing system includes settlement engine 704 for settling transactions including netted out transactions amounts between payment flows; ¶[0112]:the payment processing system includes tracking engine 705 for tracking transactions, including those with multiple payment flows, to enable settlement to be performed by netting transaction amounts of multiple payment flows. In one embodiment, tracking engine 705 exchanges information with settlement engine 704 to enable settlement engine 704 to perform the netting of transaction amounts. That is, tracking engine 705 determines when transactions associated with different payment flows are related to each other so that settlement engine 704 is able to adjust a customer's balance based on a netted amount between the related payment flows.; ¶[0113]: In one embodiment, the payment processing system includes history database 706 to store transaction history. Such transaction history may include all of the customer's transactions because the payment processor is the card issuer. The transaction history is provided to the payment processor's customers for use in analyzing their transaction information. In one embodiment, transaction history is provided to tracking engine 705 to facilitate the determination that transactions of different payment flows are related to each other).
Regarding claim(s) 8 and 18,
THAIRU, PHILLIPS, and DIWAKARAN teaches all of the limitations of the parent claims from which these claim(s) depend (claims 1, 6, 7, 11, 16 and 17), as set forth above.
THAIRU further discloses:
wherein the ledger computing system is to:
identify the electronic ledger corresponding to the exchange card based on the unique identifier (THAIRU: ¶[0113]: the payment processing system includes history database 706 to store transaction history. Such transaction history may include all of the customer's transactions; [0144] In one embodiment, any card event that results in funds entering or leaving a payment processor account, such as a completed purchase, refund, or ATM withdrawal, is represented by a Transaction object. In one embodiment, transactions contain information about the card used, the cardholder, and the business to which it relates.; ¶[0149]: , the dashboard view lists all of the transactions across all issued cards, providing details such as, for example, amount, card used, date, description, name on card, and business and merchant category; [0150]: In one embodiment, the transactions shown are filtered by specifying the ID of an issued card.);
and update the electronic ledger based on the exchange data of the swipe event based on the authorization of the swipe event (THAIRU: [0145]: when an authorization of a transaction is captured: [0146]: A balance transaction is created. [0147]: 2) A new Transaction object of type capture is created that deducts the purchase amount from the account balance. Another balance transaction is also created.; ¶[0148]: the payment processor also notifies these changes using the issuing.authorization.updated and issuing.transactions.created webhook events.; [0094] when a merchant captures an authorization, the following changes occur simultaneously: 1) the authorization releases the previously-held funds via a new balance transaction, a new transaction object is created to represent the capture, where the object references a new balance transaction that deducts the full capture amount from your balance; [0081]: When customer 308 approves an authorization, the balance changes for a purchase are as follows: [0082]: 1) upon authorization, payment processor 306 (e.g., card issuer) deducts the authorization amount from the available balance of customer 308 so that it is placed in a “held” state; and [0083]: 2) upon clearing, payment processor 306 releases the held authorization amount and deducts the clearing amount from the available balance of customer 308; ¶[0113] and ¶[0168]: the payment processing system includes history database to store transaction history. Such transaction history may include all of the customer's transactions).
Regarding claim 21,
THAIRU, PHILLIPS, and DIWAKARAN teaches the limitations of claim 1.
THAIRU further discloses:
for forwarding to the issuing processor computing system (THAIRU: [0075]: Paying network 304 sends the information via signals 305 to a payment processor 306, which is also the issuer of card 340, to be approved or declined synchronously.; ¶[0078]: The results of test 310 are sent via signals 310 from customer 308 to payment processor 306.),
wherein generating the message regarding the event in the format is performed using the API (THAIRU: col. 9, ll. 55-58: . At step 404, the method comprises generating a transformed HTTP message from the HTTP message using the HTTP message subscription associated with the event.; col. 9, ll. 60-65: the method comprises transforming a payload associated with the HTTP message from a format of the publishing web-application to a format of the subscriber web-application using payload mapping; col. 4, ll. 10-30: “transmitting the transformed HTTP message from the publishing web-application to the subscriber web-application to invoke an API for synchronization”; col. 10, ll. 1-7: “At step 412, the method comprises transmitting the transformed HTTP message from the publishing web-application to the subscriber web-application to invoke an API for synchronization of the publishing web-application and the subscriber web-application.”).
THAIRU does not expressly disclose the following limitations, which DIWAKARAN however, teaches:
generating, by the one or more processors, an application programming interface (API) in response to the identification of the format input into the one or more forms of the user interface,(DIWAKARAN: col. 9, ll. 20-30: The transform script space 310 is used to configure a transform script that is associated with payload mapping. The transform script is used to transform the payload from the format of the publishing web-application 110 to the format of the one or more subscriber web-applications 104A-N.; col. 8, ll. 43-48: the synchronization module 216 may invoke an endpoint of a representational state transfer application programming interface (REST API) by implementing the HTTP message subscription as a webhook subscription configuration to universally connect the subscriber web-application and the publishing web-application; col. 3, ll. 10-29: when executed by the processor further invokes an endpoint of a representational state transfer application programming interface (REST API) by implementing the HTTP message subscription as a webhook subscription configuration to universally connect the subscriber web-application and the publishing web-application.)
It would have been obvious to one of ordinary skill in the art before the time of filing to combine/modify the system/method of THAIRU, which discloses systems and methods of processing commercial transactions (THAIRU ¶[0003]) using networks and payment networks (THAIRU ¶[0109] and ¶[0153]) with the technique of DIWAKARAN, in order to enable communication between parties in a synchronized and a uniform way (DIWAKARAN col. 1, ll. 35-40).
THAIRU does not expressly disclose the following limitations, which PHILLIPS however, teaches:
the API configured to facilitate communication between the one or more processors and the computing device of the computing system (PHILLIPS: ¶[0029]: an integration platform may offer one or more interfaces, such as one or more application programming interfaces (APIs), to connect with one or more consumer or third party channels, and to also connect with electronic commerce platforms, merchants, and payment processor. The APIs offered by the integration platform may standardize interactions between, for example, the third party channels and the electronic commerce platforms, such that a particular third party channel only needs to configure its systems once to interact with the integration platform, which in turn may serve much like a conduit to interact with any of the electronic commerce platforms which operate in conjunction with the integration platform; ¶[0063]: details of a payment method […] can be forwarded to an end-point using a POST request ).
It would have been obvious to one of ordinary skill in the art before the time of filing to combine/modify the system/method of THAIRU, which discloses systems and methods of processing commercial transactions (THAIRU ¶[0003]) with the technique of PHILLIPS, in order to standardize interactions (PHILLIPS ¶[0029]) in electronic commerce).
Claims 3-5, 10, and 13-15 are rejected under 35 U.S.C. § 103 as being unpatentable over THAIRU (US 20240037513 A1 to Thairu; Timothy et al.) in view of PHILLIPS (US 20170132627 A1 to Phillips; Ashley et al.) in further view of DIWAKARAN (US 11271987 B1 to Diwakaran; Umakanthan) and in further view of DUCKER (US 20230306431 A1 to Ducker; Michael et al.).
Regarding claim(s) 3 and 13,
THAIRU, PHILLIPS, and DIWAKARAN teaches the limitations of claims 1, 11, and 19.
THAIRU does not expressly disclose the following limitations, which DUCKER however, teaches:
wherein receiving the pointer comprises receiving, by the one or more processors, a plurality of pointers, including the pointer, each of the plurality of pointers corresponding to a different event type. (DUCKER: [0065] In one example implementation, the system 150 establishes, at a point in time in advance of step 430, one or more webhook interfaces with different third party payment processing systems, such as property management software, and the like. The contact information and/or webhook information for these system may be stored in some embodiments in third party payment system database 344, with each of a plurality of webhook URLs being respectively associated with each of the plurality of remote servers/systems specified in the database 344. These third party systems may be include, for instance, the most common or most well-known/widely-used systems, may include systems relevant or specific to a transaction type or category, may be specified by the payer 110, and/or may be otherwise collected or selected in any appropriate way. ; ¶[0015]: transaction management system could use webhooks to send data (notification of payment) to a plurality of third-party payment systems; ¶[0064]: system 150 may send out a broadcast stream of transaction information, each broadcast communication being automatically triggered by the credit of a desired amount of money to a payee account. […]. The broadcast communication may be made on a transmission to each of the plurality of webhook URLs)
It would have been obvious to one of ordinary skill in the art before the time of filing to combine/modify the system/method of THAIRU, which discloses systems and methods of processing commercial transactions (THAIRU ¶[0003]) with the technique of DUCKER, in order to improve security and convenience of transactions (DUCKER ¶[0003]), reduce bandwidth and improve convenience, speed, security, and accessibility of the computer systems handling digital payment processing (DUCKER ¶[0017]).
Regarding claim(s) 4 and 14,
THAIRU, PHILLIPS, and DIWAKARAN teaches claims 1, 3, 11, and 13.
THAIRU further discloses:
wherein the event types of the plurality of pointers comprise one or more of swipe event created, swipe created, swipe updated, card created, or card status updated (THAIRU: ¶[0139]: sends an issuing_card.created webhook event; ¶[0148]: issuing.authorization.updated and issuing.transactions.created webhook events; ¶[0143]: e. In one embodiment, the status of each card is maintained in a record in a database of the payment processor along with its associated card information. Only active cards can be used to make a purchase. Any authorization requests using a card with a status of cancelled or inactive are automatically declined.).
Regarding claim(s) 5 and 15,
THAIRU, PHILLIPS, and DIWAKARAN teaches claims 1, 3, 11, and 13:
THAIRU further discloses:
determining, by the one or more processors, an event type of the detected event (THAIRU: [0137]: Step 1: Create a Cardholder; [0138]: In one embodiment, a Cardholder with a name, billing address, entity type, and any additional information is created as shown in FIG. 10; figure 10: issuing cardholders curl; [0139]: in response to the above curl, a card holder creation module (e.g., 1901 of FIG. 19) of the system of the payment processor returns a Cardholder object that contains the information that was provided by a user, and sends an issuing_card.created webhook event; );
THAIRU does not expressly disclose the following limitations, which DUCKER however, teaches:
and transmitting, by the one or more processors using the pointer, the message regarding the event to the computing device of the computing system responsive to the pointer corresponding to the event type (DUCKER: [0065] In one example implementation, the system 150 establishes, at a point in time in advance of step 430, one or more webhook interfaces with different third party payment processing systems, such as property management software, and the like. The contact information and/or webhook information for these system may be stored in some embodiments in third party payment system database 344, with each of a plurality of webhook URLs being respectively associated with each of the plurality of remote servers/systems specified in the database 344. These third party systems may include, for instance, the most common or most well-known/widely-used systems, may include systems relevant or specific to a transaction type or category, may be specified by the payer 110, and/or may be otherwise collected or selected in any appropriate way. ; ¶[0015]: transaction management system could use webhooks to send data (notification of payment) to a plurality of third-party payment systems).
It would have been obvious to one of ordinary skill in the art before the time of filing to combine/modify the system/method of THAIRU, which discloses systems and methods of processing commercial transactions (THAIRU ¶[0003]) with the technique of DUCKER, in order to improve security and convenience of transactions (DUCKER ¶[0003]), reduce bandwidth and improve convenience, speed, security, and accessibility of the computer systems handling digital payment processing (DUCKER ¶[0017]).
Regarding claim(s) 10,
THAIRU, PHILLIPS, and DIWAKARAN teaches all of the limitations claim 1, as set forth above.
THAIRU further discloses:
wherein the user interface comprises a form configured to receive a type of method for communication using the pointer (THAIRU: ¶[0170]; an issuer engine 1908 comprises a dashboard module 1910 for generating and presenting a user interface; THAIRU: ¶[0089]: the payment processor sends an issuing.authorization.request webhook in real-time to a universal resource locator (URL) of the customer, which represents a designated endpoint); THAIRU figure 17: specifying “authorization method” in messages; and THAIRU ¶[0158]: configuring a webhook by specifying an endpoint in settings (“Issuingsettings”)
THAIRU does not disclose the following, which DUCKER teaches:
the method comprising: receiving, by the one or more processors, a first type of method as input via the form, wherein using the pointer to transmit the message regarding the event to the computing device comprises transmitting the message using the input first type of method (DUCKER: ¶[0015]: the transaction management system could use webhooks to send data (notification of payment) to a plurality of third-party payment systems; ¶[0065]: the system 150 establishes, at a point in time in advance of step 430, one or more webhook interfaces with different third party payment processing systems; ¶[0065]: The contact information and/or webhook information for these system may be stored in some embodiments in third party payment system database 344, with each of a plurality of webhook URLs being respectively associated with each of the plurality of remote servers/systems specified in the database 344. These third party systems may be include, for instance, the most common or most well-known/widely-used systems; ¶[0064]: The broadcast communication may be made on a transmission to each of the plurality of webhook URLs, or an HTTP command (e.g., HTTP GET request) containing the generated serialized data; ¶[0067]: because text or email or other messaging may be used from an entity known to the payee (the payer), both parties can feel confident in the source of the transaction; ¶[0024]: devices 112, 122 may be capable of receiving and displaying notification data via a dedicated application (app) or website, email, text or instant messaging, voice, SMS, QR code, voicemail, or any other appropriate type of communication; ¶[0032]: communication logic 322 may use APIs provided by these entities or webhooks established between the transaction management system 150 and/or one or more third party payment processing systems 140 (or other entities) to obtain their respectively stored data or transmit data or instructions to their systems. However, other methods of data collection/transmission may alternatively be used such as one or more software development kits, which may include, e.g., one or more application programming interfaces (APIs), web APIs, tools to communicate with embedded systems, or any other appropriate implementation; ).
It would have been obvious to one of ordinary skill in the art before the time of filing to combine/modify the system/method of THAIRU, which discloses systems and methods of processing commercial transactions (THAIRU ¶[0003]) with the technique of DUCKER, in order to improve security and convenience of transactions (DUCKER ¶[0003]), reduce bandwidth and improve convenience, speed, security, and accessibility of the computer systems handling digital payment processing (DUCKER ¶[0017]).
Response to Arguments
Applicant’s arguments, see pages 9-13 filed 24 November 2025 that the claims are patent-eligible under 35 U.S.C. § 101 have been fully considered and are unpersuasive. At page 10, Applicant argues the claims solve a technical problem of communication in different formats between systems. This argument has been considered but is unpersuasive. A specific middleware structure does not appear in the claims and the claims are recited using generic elements and functions, and thus are directed to an abstract idea without significantly more and the additional generic elements do not integrate the abstract idea into a practical application.
Applicant argues at page 10 that the claims do not recite an abstract idea. This argument has been considered but is unpersuasive. This is an abstract idea that falls under the grouping of Commercial or Legal Interactions (marketing or sales activities or behaviors, and business relations). (see MPEP § 2106.04(a)(2), subsection II.B) because they recite receiving parameters of a card program, generating data for an exchange card, detecting an event regarding the exchange card, and transmitting/forwarding a message regarding the event.
Applicant argues at page 13 that system of claim 1 could not be performed without the integral use of the respective user interfaces that facilitate configuration of the communication between the different computing systems of issuing processors and the middleware system, and therefore is patent eligible as a practical application. This argument has been considered but is unpersuasive. The additional claim elements are recited at a high level of generality and thus do not integrate the abstract idea into a practical application.
Applicant’s arguments at pages 13-15 with respect to the prior art rejection for claim(s) 1-8 are 10-21 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
US 20140344153 A1 teaches systems and methods for implementing a central mobile tokenization hub that may provide common tokenization between a number of different entities, for a number of different purposes. For example, the CTC module can provide and store tokens for mobile payment transactions, transit transactions, digital wallet applications, merchant point of sale (POS) applications, personalization services, account and token management systems, and the like.
US 20210192479 A1 discloses Merchant Agents and Payer Agents register specific webhooks—i.e., URLs that accept HTTP POST messages—for various events that concern them. When a payment message arrives, the server 700 stores the message, looks up what event the message triggers, and then sends a HTTP POST with that message to the webhook registered for that event in the Webhook Directory.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BOLKO HAMERSKI whose telephone number is (571)270-7621. The examiner can normally be reached Monday-Friday 10:00 AM to 6:00 PM.
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, BENNETT SIGMOND can be reached at (303) 297-4411. 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.
BOLKO HAMERSKI
Examiner
Art Unit 3694
/BOLKO M HAMERSKI/Examiner, Art Unit 3694
/BENNETT M SIGMOND/Supervisory Patent Examiner, Art Unit 3694
Prosecution Insights