DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
This action is in response to amendment filed on 22 October 202. Claims 1-20 have been cancelled. Claims 21-40 are currently pending and have been examined.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Step 1: Claims 21-37 are a method and claims 38-40 are system. Thus, each independent claim, on its face, is directed to one of the statutory categories of 35 U.S.C 101. However, the claims 1-20 are rejected under 35 U.S.C 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 2A-Prong 1: the claims as a whole recited a method of organizing human interaction. The claimed invention recites assigning a pseudo-bank identification number (pseudo-BIN) to a payouts service provider supporting endpoint without out financial card accounts, assigning a pseudo-primary account number (pseudo-PAN) to the payouts service provider, payment amount, sending account , recipient account determining the payouts service provider based , generating a look-ahead query to the payouts service provider using the pseudo BIN associated with the pseud-PAN, assessing the recipient endpoint dataset to determine a success factor for the fulfilling the re quest to transfer fund, response to success factor exceeding a predetermine threshold, preparing a transaction payload including data from the recipient end point and executing transfer using truncation payload, which is a method of managing interaction between people and . Simply put, these limitations merely describe routing financial payments, looking up account data, assessing a "success factor," and initiating a transfer, which is clearly business arrangement in its purest form. Claims 22-37, and 39-40 merely provide additional abstract concept and narrow the abstract idea of claims 21 and 38. Further, claims 21-40 are recited at such a high level that the claimed steps amount to no more than a mental processes, such as concept performed in the mind (including an observation, evaluation, judgment, opinion). The mere nominal recitation of a generic content server and generic network-based storage devices does not take the claim out of the methods of organizing human interactions grouping. Thus, the claim recites an abstract idea.
Independent claims amend to recite a limitation of comparing the success factor to a predetermined threshold. The comparing limitation, as drafted, is a process that, under its broadest reasonable interpretation, covers the performance of the limitation the mind but for the recitations of the generic computer compoints. That is, other than reciting a generic computer component, nothing in the claim precludes the comparing step from practically being performed in the human mind. For example, but the generic computer component language, the claim encompasses the user thinking that the success factor to the predetermine threshold. Thus, this limitation is also a mental process.
In additions, the claims recite (e.g.,. using pseudo-BINs/PANs for routing and onboarding datasets) risks being classified under Mental Processes or Economic/Commercial Principles. Generating a pseudo-card number to route payments is an abstract concept that people previously did with paper, and that generic computer components only execute this conventional task.
Step 2A-Prong 2: the claim recites the combination of additional elements application programing interface (API) for exposing account information in response receiving request and parsing to determining the pseudo-PAN. The application programming interface is recited at high level of generality performing a generic computer function of receiving and exposing information. The generic limiting is no more than mere instructions to apply the exception using a generic computer function. Further the claim as a whole merely describes how to generally “apply” the concept of input our put information in a computer environment. The claimed computer components are recited at a high level of generality and are merely invoked as tools to perform an input and output process. Simply implementing the abstract idea on a generic computer is not a practical application of the abstract idea. Furthmore, the generic implementation of the use of an API, a generic computer, a "pseudo-PAN," and a "pseudo-BIN" may be viewed by the USPTO as merely routine or conventional computer activity that fails to add significantly more to the abstract idea.
Step 2B: As noted previously, the claim as a whole merely describes how to generally “apply” the concept of updating medical records in a computer environment. Thus, even when viewed as a whole, nothing in the claim adds significantly more (i.e., an inventive concept) to the abstract idea. The claim is ineligible.
Under the 2019 PEG, a conclusion that an additional element is insignificant extra-solution activity in Step 2A should be reevaluated in Step 2B. Here, the collecting step was considered to be extra-solution activity in Step 2A, and thus it is reevaluated in Step 2B to determine if it is more than what is well-understood, routine, conventional activity in the field. Brent Clark, in the weapon combat fraud in eCommerce, the Wall Street Journal of 2/10/2000 www.gpayment.com “Pseudo Card Number”, which is a well-known, routine and a generic, off the-shelf computer component, and the Symantec, TLI, and OIP Techs. court decisions cited in MPEP 2106.05(d)(II) indicate that mere collection or receipt of data over a network is a well understood, routine, and conventional function when it is claimed in a merely generic manner (as it is here). Accordingly, a conclusion that the collecting step is well-understood, routine, conventional activity is supported under Berkheimer Option 2. For these reasons, there is no inventive concept in the claim, and thus it is ineligible
The closest reference to the applicants claimed inventions:
Ornce et al (Pub., No., 2012/0203700 A1) focused on for facilitating a credit card transaction wirelessly via a mobile device. The method includes receiving registration information for a credit card and a mobile device, the registration information for the credit card including a primary account number (PAN) of the credit card; associating the registration information for the credit card with a unique token; generating a pseudo-PAN based on the PAN, the pseudo-PAN being different than the PAN; and providing the unique token and the pseudo-PAN to the mobile device for use in one or more credit card transactions(abstract), assigning a pseudo-primary account number (pseudo-PAN) to the payouts service provider (paragraphs [0013], [0014] and [0039] discloses generating a pseudo-PAN based the PAN., providing the unique token and the pseudo-PA to the mobile dice for use in one or more credit card transaction); exposing a send payout application program interface (API) that receives a request to transfer funds from a send account of a card-based network to a recipient account of a non- card-based entity paragraphs [0028] [0029], [0051], discloses a request for settlement funds..) parsing the request to determine the pseudo-PAN (paragraph [0052], discloses identify Token Card issuer by the Bin of the Pseudo-Pan); determining the payouts service provider based on the pseudo-PAN (paragraph [0052], discloses identify Token Card issuer by the Bin of the Pseudo-Pan) and a Bank Identifying Number (BIN) is typically the first 6 digit of credit card number that identifies both the credit card brand (i.e., Visa, MasterCard, Discover, American Express, etc.) as well as the specific card issuing institutions (“issuer”) (paragraph [0023])
Daetz (US Pub., No., 2018/0197174A1) focused on systems and methods are provided for use in facilitating payment account transactions. One exemplary method includes initially issuing, by a computing device, a transaction code to a communication device associated with a consumer for use in a transaction to a payment account by the consumer. The method then includes intercepting, by the computing device, an authorization request including a pseudo primary account number (PAN) for the consumer's transaction, where the pseudo-PAN includes the transaction code, and identifying, by the computing device, a PAN for the payment account associated with the transaction code included in the pseudo-PAN. The method further includes replacing, by the computing device, the pseudo-PAN with the identified PAN for the consumer's payment account, and routing the authorization request with the PAN to an issuer of the consumer's payment account(abstract), the pseudo-PAN to confirm to one or mor payment network restrictions (e.g., to add a check digit consistent with the Luhn algorithm (paragraph [0025]), determining if the customer’s payment account is in good standing if there’s sufficient funds and/or credit card to cover transaction (paragraph [0027]), transaction data may include, for example (and without limitation), pseudo PANs (and the various parts thereof), PANs, amounts of the transactions, merchant IDs for merchants involved in the transactions, merchant category codes (MCCs), balances, payment history, dates/times of the transactions/payments, incentives used (e.g., rebates discounts, etc.), etc., (paragraph [0029]).
Hogan et al (US Pub., No., 2002/0116341 A1) focused on a secure method of conducting an electronic transaction over a public communications network is provided which utilizes a pseudo-expiration date in the expiration date field., providing the pseudo account number with a control field indicating one of a plurality of key-generation processes to be used to generate an authentication key; (b) generating an authentication key associated with the pseudo account number using one of the pluralities of key-generation processes indicated in the control field of the pseudo account number (abstract), assigning a pseudo-bank identification number (pseudo-BIN) to a payouts service provider supporting endpoints without financial card accounts(paragraph [0078], discloses the BIN of a pseudo account number is a ”pseudo BIN” that is not embossed on any MasterCard, there is one pseudo BIN per card issuer, so the issue of a pseudo account number can be identified) and all merchants and acquires know the cardholder by the pseudo account number, but the issuer know the cardholder by the real account number (paragraph [0078]), Once the SPA website has received this information, it examines the BIN. It holds a list of all issued pseudo-BINS, and the SPA website first determines whether or not the BIN of the given account number is on this list. If so, it is a pseudo account number and if not, it is a "real" account number (paragraph [0082]), by holding a second table that relates "real" BINS to pseudo-BINS, and, if it finds an entry in this table for the "real" BIN in question, it knows that this issuer participates in SPA If the BIN is a pseudo BIN, the SPA website knows, from that fact alone, that this is a pseudo account number and that the issuer is a SPA participant (paragraph [0073]) transition SPA procced as follows (see paragraphs [0280]-[0299]and the pseudo-BIN-Key Indicator (as 8 bits) (paragraph [0292]).
Hogan et al (US Pub., No., 2008/0065554 A1) discloses a method is provided for conducting a financial transaction by a purchaser with a merchant having an acquirer bank, over a communications network. The method includes the steps of sending a first authorization request using a pseudo account number associated with a real account number to a service provider which forwards a second authorization request to the issuer using the real account number and preferably a pseudo acquirer code associated with the service provider such that the response to the second request is based on the real account number and sent back to the service provider who preferably forwards a response to the first request preferably to the "real" acquirer.
Carlson (US Pub., No., 2008/0319905 A1) discloses the present invention provides a method for conducting a transaction that includes receiving a pseudo account identifier that corresponds to a primary account identifier. The pseudo account identifier may be received at a portable wireless device and may be generated by a remote server computer. The portable wireless device can receive the pseudo account identifier over a first network and provide the pseudo account identifier to an access device. The access devices generally comprise a reader that can receive the pseudo account identifier, and thereafter send a message to request authorization of a transaction.
Kimberg (US Pub., 2015/0363762 A1) discloses an electronic system for mobile open payments obtains, from a first mobile telephony provider entity, first merchant registration information; and assigns a unique merchant identifier to identify the first merchant. The system obtains, from a second mobile telephony provider entity, a query, initiated based on a payment instruction from a customer of the first merchant and the second mobile telephony provider entity the first merchant to be paid a certain amount. The query includes the unique merchant identifier of the first merchant.
Cacioppo (US Pub., No., 2015/0310425 A1) discloses systems and methods
for processing payment transaction using pseudo-PAN. In an exemplary embodiment, a method generally includes generating an encryption salt, receiving a request from a
consumer indicating a possible payment transaction, in response to the request, generating a one-time token, based on the actual payment information and a most recent generated
encryption salt, the one-time token having the same format as the payment information, with a routing segment of the onetime token being identical to a routing segment of the payment
information, and presenting the one-time token(abstract), when the pseudo-PAN is generated (as depicted in the example of Fig. 4), the first six digits of the PAN, or the routing segment 402 (or Bank Identification Number (BIN) (paragraph [0029]).
Safak et al. ( US Pub. No.: US 2019/0156335 Al) discloses a payment token is generated within a token bank identification number (BIN) range, and is linked with an underlying account number of a consumer. A first instance of the token is made available in at least one of a first portable electronic device, a first mobile payment application (MPA), and a first web wallet of the consumer with an associated first primary account sequence number (PSN) (abstract) and generate a look-ahead query to the payouts service provider using the pseudo-BIN associated with the pseudo-PAN (paragraph [0010], discloses token mapping [look ahead query] used to keep track of which taken is associated with which consumer account …).
None of the above reference either alone or in a combination teaches or suggests that the corrosinding Pseudo-Pan taught by Ornce, or Daetz and the corrosinding Pseudo-BIN by Hogan is used to receiving from the payouts service provider a response to the look-ahead query, the response including a recipient endpoint dataset; assessing the recipient endpoint dataset to determine a success factor for fulfilling the request to transfer funds; comparing the success factor to a predetermined threshold; responsive to the success factor exceeding the predetermined threshold, preparing a transaction payload including data from the recipient endpoint dataset; and executing the transfer using the transaction payload to transfer funds from the send account of the card-based network to the recipient account of the non-card-based entity and wherein the pseudo-BIN and the pseudo-PAN provide a routable destination for the payouts service provider in the card-based network, and wherein the recipient endpoint dataset includes data for onboarding and account verification to reduce a rate of rejected transactions.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SABA DAGNEW whose telephone number is (571)270-3271. The examiner can normally be reached 9-6:45.
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, Waseem Ashraf can be reached on (571) 270 -3948. 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.
/SABA DAGNEW/Primary Examiner, Art Unit 3682
Prosecution Insights