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 the Application
Claims 1-2 and 4-19 are currently pending in this case and have been examined and addressed below. This communication is a Final Rejection in response to the Amendments to the Claims and Remarks filed on 12/23/2025.
Claims 1-2, 4, and 7-10 are currently amended.
Claim 3 is cancelled.
Claims 11-19 are added.
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-2 and 4-19 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., an abstract idea) without significantly more.
Step 1: Claims 1-2, 4-7, 11-16 are drawn to a process. Claims 8-10 and 17-19 are drawn to a machine. As such, claims 1-2 and 4-19 are drawn to one of the statutory categories of invention (Step 1: YES).
Step 2A - Prong One: In prong one of step 2A, the claim(s) is/are analyzed to evaluate whether it/they recite(s) a judicial exception.
Independent Claim 1: A method of processing healthcare payments through an individual coverage health reimbursement arrangement, the method comprising:
receiving, by a control device, a transaction related to a qualified medical expense via a payment card linked to a member checking account;
in response to receiving an authorization request for the transaction and determining, by the control device, that the transaction is a qualified medical expense, transferring, by the control device prior to clearing, an authorization amount corresponding to the transaction from a funding account to the member checking account and placing, by the control device, a hold in the member checking account for the authorization amount;
upon clearing of the transaction, transferring, by the control device, the authorization amount from the member checking account to a seller associated with the transaction and canceling the hold;
recording, by the control device, the authorization amount and clearing of the transaction as separate entries into an invoice database, wherein each recorded amount corresponds to a generated invoice;
combining, by the control device, the generated invoices in the invoice database to calculate an aggregated employer invoice amount at the end of a predetermined period based on a collective sum of the transactions associated with each member of an employer;
debiting, by the control device, the aggregated employer invoice amount from an employer operating account for the predetermined period;
paying, by the control device, the aggregated employer invoice amount into a system batch account;
and initiating, by the control device, a transfer from the system batch account to the funding account.
Independent Claim 7: A method of processing healthcare payments through an individual coverage health reimbursement arrangement for tax savings, the method comprising:
receiving, by a control device, an authorization request related to a medical expense via a payment card associated with a member checking account;
determining, by the control device, whether the medical expense is a qualified medical expense;
in response to the authorization request and the determination that the medical expense is a qualified medical expense, transferring, by the control device, an amount corresponding to the medical expense from a funding account to the member checking account;
approving, by the control device, the authorization request and placing a hold on the member checking account based on the amount corresponding to the medical expense;
creating, by the control device, a transaction based on the authorization request; transferring, by the control device, the amount from the member checking account to a seller associated with the transaction and canceling the hold on the member checking account;
recording, by the control device, the amount of the transaction into an invoice database, wherein each recorded amount corresponds to a generated invoice;
creating, by the control device, an overage invoice if the amount of the transaction exceeds a balance associated with the member checking account;
combining, by the control device, the generated invoices in the invoice database to calculate an aggregated employer invoice amount at the end of a predetermined period based on a collective sum of the transactions associated with each member of an employer;
debiting, by the control device, the aggregated employer invoice amount into a system batch account;
and initiating, by the control device, a transfer from the system batch account to the funding account.
Independent Claim 8: A system, comprising:
a host server including one or more processors and non-transitory computer-readable media storing instructions;
a system database containing a funding account and a batch account in communication with the host server;
an invoice database containing a ledger, wherein the invoice database is in communication with the host server;
a member database containing an employer operating account and a plurality of member checking accounts associated with each member of an employer, the member database in communication with the host server;
and a payment card issued to each member of the employer;
wherein execution of the instructions by the one or more processors of the host server causes the host server to:
a) receive a transaction related to a qualified medical expense via the payment card linked to the member checking account of a member;
b) fund an amount corresponding to the transaction from the funding account on the system database to the member checking account;
c) transfer the amount from the member checking account to a seller associated with the transaction;
d) record the amount of the transaction into the invoice database, wherein each recorded amount corresponds to a generated invoice;
e) combine the generated invoices in the invoice database to calculate an aggregated employer invoice amount at the end of a predetermined period based on a collective sum of the transactions associated with each member of an employer;
f) debit the aggregated employer invoice amount from the employer operating account for the predetermined period;
g) pay the aggregated employer invoice amount into the batch account on the system database;
and h) initiate a transfer from the batch account to the funding account.
Independent Claim 11: A method of processing healthcare payments through an individual coverage health reimbursement arrangement, the method comprising:
receiving, by a host server, a transaction related to a qualified medical expense via a payment card linked to a member checking account;
in response to receiving an authorization request for the transaction and determining, by the host server, that the transaction is a qualified medical expense, transferring, by the host server prior to clearing, an authorization amount corresponding to the transaction from a funding account to the member checking account and placing, by the host server, a hold in the member checking account for the authorization amount;
upon clearing, transferring, by the host server, the authorization amount from the member checking account to a seller associated with the transaction and canceling the hold;
recording, by the host server, the authorization request and the clearing event as separate ledger entries with unique identifiers in an invoice database, wherein each recorded event corresponds to a generated invoice;
combining, by the host server, at the end of a predetermined period, the generated invoices in the invoice database to calculate an aggregated employer invoice amount based on a collective sum of the transactions associated with each member of an employer;
debiting, by the host server, the aggregated employer invoice amount from an employer operating account for the predetermined period;
paying, by the host server, the aggregated employer invoice amount into a system batch account;
and initiating, by the host server, a transfer from the system batch account to the funding account.
(Examiner notes: The above claim terms underlined are additional elements that fall under Step 2A - Prong Two analysis section detailed below)
These steps amount to methods of organizing human activity which includes functions relating to interpersonal and intrapersonal activities, such as managing relationships or transactions between people, social activities, and human behavior; satisfying or avoiding a legal obligation; advertising, marketing, and sales activities or behaviors; and managing human mental activity (MPEP § 2106.04(a)(2)(II)(A) citing the abstract idea grouping for methods of organizing human activity for fundamental economic practices or principles).Therefore, receiving a transaction, transferring an authorization amount corresponding to the transaction in response to receiving an authorization request and determining that the transaction is a qualified medical expense, placing a hold on the member checking account for the authorization amount, transferring the authorization amount from member checking account to a seller, cancelling the hold, recording the authorization amount, combining the generated invoices to calculate an aggregated employer invoice amount, debiting the aggregated employer invoice amount, paying the aggregated employee invoice amount, and initiating a transfer of accounts are directed to managing personal interactions or personal behavior.
The dependent claim 2 is directed to determining if an amount of the transaction exceeds a predetermined member balance associated with the member checking account and, when the amount of the transaction exceeds the predetermined member balance, generating an overage invoice associated with the transaction.
The dependent claim 4 is directed to receiving a plurality of transactions related to qualified medical expenses via a plurality of payment cards associated with a plurality of member checking accounts.
The dependent claim 5 is directed to issuing a member checking account.
The dependent claim 6 is directed to the generated invoice contains one or more recorded amounts.
The dependent claim 12 is directed to creating a hold record that is linked to the authorization amount and is released when the transaction clears.
The dependent claim 13 is directed to linking the generated invoices to an employer payroll system for deduction during a subsequent payroll cycle.
The dependent claim 14 is directed to updating an employer payroll system with payroll deductions corresponding to overage invoices generated for members whose transactions exceed a predetermined member balance, the updating occurring prior to the next payroll cycle.
The dependent claims 15 and 17 are directed to the funding account comprises one of a system operational account, an employer-owned account, a member-owned account, or any combination thereof and selecting an account based on a funding preference associated with a member.
The dependent claim 16 is directed to transferring the authorization amount from the funding account to the member checking account is performed only in response to a determination that the transaction is for an insurance premium or an approved medical expense.
The dependent claim 18 is directed to update an employer payroll system with payroll deductions corresponding to overage invoices for members whose transactions exceed a predetermined member balance.
The dependent claim 19 is directed to fund the member checking account only after determining that the transaction is associated with an insurance premium or an approved medical expense.
Each of these steps of the preceding dependent claims 2, 4-6, 9-10, and 12-19 only serve to further limit or specify the features of independent claims 1, 7, 8, and 11 accordingly, and hence are nonetheless directed towards fundamentally the same abstract idea as the independent claim and utilize the additional elements analyzed below in the expected manner.
As such, the Examiner concludes that the preceding claims recite an abstract idea (Step 2A – Prong One: YES).
Step 2A - Prong Two: In prong two of step 2A, an evaluation is made whether a claim recites any additional element, or combination of additional elements, that integrate the exception into a practical application of that exception. An “additional element” is an element that is recited in the claim in addition to (beyond) the judicial exception (i.e., an element/limitation that sets forth an abstract idea is not an additional element). The phrase “integration into a practical application” is defined as requiring an additional element or a combination of additional elements in the claim to apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that it is more than a drafting effort designed to monopolize the exception.
Claims 1, 4, 7, 12-15 recite the use of a control device, in this case to receiving a transaction related to a qualified medical expense, transferring an authorization amount corresponding to the transaction from a funding account to the member checking account and placing a hold in the member checking account for the authorization amount, transferring the authorization amount from the member checking account to a seller associated with the transaction and canceling the hold, recording the authorization amount and clearing of the transaction as separate entries, combining the generated invoices to calculate an aggregated employer invoice amount at the end of a predetermined period based on a collective sum of the transactions associated with each member of an employer, debiting the aggregated employer invoice amount from an employer operating account for the predetermined period, paying the aggregated employer invoice amount into a system batch account, initiating a transfer from the system batch account into the funding account, receiving a plurality of transactions related to qualified medical expenses associated with a plurality of member checking accounts, receiving an authorization request related to a medical expense, determining whether the medical expense is a qualified medical expense, transferring an amount corresponding to the medical expense from a funding account to the member checking account, approving the authorization request and placing a hold on the member checking account based on the amount corresponding to the medical expense, creating a transaction based on the authorization request, transferring the amount from the member checking account to a seller associated with the transaction and canceling the hold on the member checking account, recording the amount of the transaction, creating an overage invoice if the amount of the transaction exceeds a balance associated with the member checking account, combining the generated invoices to calculate an aggregated employer invoice amount at the end of a predetermined period based on a collective sum of the transactions, debiting the aggregated employer invoice amount into a system batch account, initiating a transfer from the system batch account to the funding account, creating a hold record that is linked to the authorization amount and is automatically released when the transaction clears, updating an employer payroll system with payroll deductions corresponding to overage invoices generated for members whose transactions exceed a predetermined member balance, the updating occurring prior to the next payroll cycle, selects among the accounts based on a funding preference associated with a member, only recites the control device as a tool to perform an existing process and only amounts to an instruction to implement the abstract idea using a computer (MPEP § 2106.05(f)(2)).
Claims 1-2, 4-5, 7-8, and 11 recite the use of a payment card, only as a tool to perform an existing process and only amounts to an instruction to implement the abstract idea using a computer (MPEP § 2106.05(f)(2)).
Claims 1, 7-8, and 11-13 recite The use of an invoice database, only as a tool to perform an existing process and only amounts to an instruction to implement the abstract idea using a computer (MPEP § 2106.05(f)(2)).
Claims 8 and 18-19 recite the use of a host server including one or more processors and non-transitory computer-readable media storing instructions, in this case to receive a transaction related to a qualified medical expense, fund an amount corresponding to the transaction, transfer the amount from the member checking account to a seller associated with the transaction, record the amount of the transaction, combine the generated invoices to calculate an aggregated employer invoice amount at the end of a predetermined period, debit the aggregated employer invoice amount, pay the aggregated employer invoice amount, initiate a transfer from the batch account to the funding account, update an employer payroll system with payroll deductions corresponding to overage invoices for members whose transactions exceed a predetermined member balance and fund the member checking account only after determining that the transaction is associated with an insurance premium or an approved medical expense, only recites the a host server including one or more processors and non-transitory computer-readable media storing instructions as a tool to perform an existing process and only amounts to an instruction to implement the abstract idea using a computer (MPEP § 2106.05(f)(2)).
Claim 8 recites the use of a system database, invoice database is in communication with the host server, member database, and member database in communication with the host server, only as a tool to perform an existing process and only amounts to an instruction to implement the abstract idea using a computer (MPEP § 2106.05(f)(2)).
Claim 9 recites the use of a one or more computer processors configured to execute the instructions stored on the non- transitory computer-readable media, only as a tool to perform an existing process and only amounts to an instruction to implement the abstract idea using a computer (MPEP § 2106.05(f)(2)).
Claim 10 recites the use of a non-transitory computer program product embodied on a computer readable medium having instructions that, which, when executed by one or more processors of the host server of the system of claim 8, cause the host server to perform operations, only as a tool to perform an existing process and only amounts to an instruction to implement the abstract idea using a computer (MPEP § 2106.05(f)(2)).
Claim 11 recites the use of a host server, in this case to receiving a transaction related to a qualified medical expense, transferring an authorization amount corresponding to the transaction from a funding account to the member checking account and placing a hold in the member checking account for the authorization amount, transferring the authorization amount from the member checking account to a seller associated with the transaction and canceling the hold, recording the authorization amount and clearing of the transaction as separate entries, combining the generated invoices to calculate an aggregated employer invoice amount at the end of a predetermined period based on a collective sum of the transactions associated with each member of an employer, debiting the aggregated employer invoice amount from an employer operating account for the predetermined period, paying the aggregated employer invoice amount into a system batch account, initiating a transfer from the system batch account into the funding account, only recites the host server as a tool to perform an existing process and only amounts to an instruction to implement the abstract idea using a computer (MPEP § 2106.05(f)(2)).
Claims 16 and 19 recite the use of a merchant category code analysis, transaction descriptors, or a trained classifier, only as a tool to apply data to an algorithm and report the results (MPEP § 2106.05(f)(2)) amounting to instruction to implement the abstract idea using a general purpose computer.
The Examiner has therefore determined that the additional elements, or combination of additional elements, do not integrate the abstract idea into a practical application. Accordingly, the claim(s) is/are directed to an abstract idea (Step 2A – Prong two: NO).
Step 2B: In step 2B, the claims are analyzed to determine whether any additional element, or combination of additional elements, is/are sufficient to ensure that the claims amount to significantly more than the judicial exception.
As discussed above in “Step 2A – Prong 2”, the identified additional elements, such as the control device, payment card, host server including one or more processors and non-transitory computer-readable media storing instructions, system database, invoice database, invoice database in communication with the host server, member database, member database is in communication with the host server, one or more computer processors configured to execute the instructions stored on the non- transitory computer-readable media, non-transitory computer program product embodied on a computer readable medium having instructions that, which, when executed by one or more processors of the host server of the system of claim 8,cause the host server to perform operations, and merchant category code analysis, transaction descriptors, or a trained classifier in independent claims 1, 7, 8, and 11 and dependent claims 2, 4-6, 9-10, and 12-19 are equivalent to adding the words “apply it” on a generic computer. Each of these elements is only recited as a tool for performing steps of the abstract idea, such as the use of the computer and data processing devices to apply the algorithm. These additional elements therefore only amount to mere instructions to perform the abstract idea using a computer and are not sufficient to amount to significantly more than the abstract idea (MPEP 2016.05(f) see for additional guidance on the “mere instructions to apply an exception”). Each additional element under Step 2A, Prong 2 is analyzed in light of the specification’s explanation of the additional element’s structure. The claimed invention’s additional elements are directed to generic computer component and functions being used to perform the abstract idea.
Applicant’s own disclosure in paragraphs [0051] and [0060] acknowledges that the “payment card, e.g., debit card or virtual card…Upon swiping the payment card, a card authorization request is sent to the system”. Paragraphs [0017] and [0045] acknowledge “invoice database contains a ledger, wherein the invoice database is in communication with the host server. The member database contains an employer operating account and a plurality of member accounts associated with each employee of an employer, wherein the member database is in communication with the host server…a system database containing an operating account and a batch account connected to a host server. The system further includes an invoice database containing a ledger and a member database containing an employer operating account and a plurality of member accounts associated with an employee of an employee”. Additionally, paragraphs [0060] and [0087-0089] disclose the “software application also facilitates communication between the multiple databases discussed above… Software applications as described herein may be implemented over system components and configured to execute various steps in the methods described throughout this disclosure…can be provided in digital electronic circuitry, in computer software, firmware, and/or hardware, including the structures disclosed in this specification and their structural equivalents, and/or in combinations of one or more of them…implemented as one or more computer program products, e.g., one or more modules of computer program instructions encoded on a tangible program carrier for execution by, and/or to control the operation of, data processing apparatus”. Furthermore paragraphs [0090-0091] acknowledge that the “processes and/or logic flows described in this specification and/or in the accompanying figures may be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and/or generating output, thereby tying the process to a particular machine (e.g., a machine programmed to perform the processes described herein). The processes and/or logic flows can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) and/or an ASIC (application specific integrated circuit)… Computer readable media suitable for storing computer program instructions and/or data may include all forms of non-volatile memory, media and memory devices, including by way of example semiconductor memory devices (e.g., EPROM, EEPROM, and/or flash memory devices); magnetic disks (e.g., internal hard disks or removable disks); magneto optical disks; and/or CD ROM and DVD ROM disks. The processor and/or the memory can be supplemented by, or incorporated in, special purpose logic circuitry”.
The Examiner has therefore determined that no additional element, or combination of additional claims elements is/are sufficient to ensure the claim(s) amount to significantly more than the abstract idea identified above (Step 2B: NO).
Therefore, claims 1-2 and 4-19 are not eligible subject matter under 35 USC 101.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 5-13, 15-17, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Bull et al. (US-20200402670-A1)[hereinafter Bull], in view of Harrison et al. (US-7922083-B2)[hereinafter Harrison].
As per Claim 1, Bull discloses a method of processing healthcare payments through an individual coverage health reimbursement arrangement in paragraph [0188] (a method of processing healthcare transactions through a health reimbursement account (synonymous to an individual coverage health reimbursement arrangement)), the method comprising: receiving, by a control device, a transaction related to a qualified medical expense via a payment card linked to a member checking account in paragraphs [0189] (receiving, by the server, a transaction related to a qualified medical expense via a debit card linked to the user financial transaction information (synonymous to a member checking account)); in response to receiving an authorization request for the transaction and determining, by the control device, that the transaction is a qualified medical expense, transferring, by the control device prior to clearing, an authorization amount corresponding to the transaction from a funding account to the member checking account in paragraphs [0436] and [0441] (in response to receiving an authorization request for the transaction and determining that the transaction is a qualified medical expense, transferring, by the server (synonymous to a control device) prior to posting (synonymous to clearing), the transaction ( synonymous to an authorization amount corresponding to the transaction) from electronic benefits account information (synonymous to a funding account) to the debit or credit transactions account (synonymous to the member checking account)) and placing, by the control device, a hold in the member checking account for the authorization amount in paragraphs [0009] and [0439] and Figure 9 (a memo-post transaction (synonymous to a hold) is temporarily placed on the debit or credit transactions account, by the server for the transaction); upon clearing of the transaction, transferring, by the control device, the authorization amount from the member checking account to a seller associated with the transaction and canceling the hold in paragraphs [0189] and [0439] and Figure 9 (upon posting the transaction (synonymous to clearing the transaction), transferring, by the server, the transaction from the user financial transaction information to the merchant associated with the transaction and removing the memo-post on the debit or credit transactions account (Examiner notes that user financial transaction information indicates checking account)); debiting, by the control device, the aggregated employer invoice amount from an employer operating account for the predetermined period in paragraphs [0169] and [0436] and [0439] and [0441] and [0469] (debiting, by the computing device, the funds (synonymous to the aggregated employer invoice amount) from the electronic funding source or an employer payroll account (synonymous to an employer operating account) for a particular time period); paying, by the control device, the aggregated employer invoice amount into a system batch account in paragraphs [0169] and [0436] and [0439] and [0469] (depositing, by the computing device, the funds with batch processing (Examiner notes that batch processing occurs in batch accounts)); and initiating, by the control device, a transfer from the system batch account to the funding account in paragraphs [0055] and [0169] and [0436] and [0439] and [0469] (initiating, by the computing device, a transaction with batch processing to fund the electronic benefits account (synonymous to the funding account)).
Bull does not disclose the following limitations. However, Harrison discloses recording, by the control device, the authorization amount and clearing of the transaction as separate entries into an invoice database, wherein each recorded amount corresponds to a generated invoice in column 6 lines 42-52 and column 9 lines 33-55 and column 10 lines 28-column 11 line 21 (recording, by the host computer, the authorization amount and a post-sale transaction as receipts into a receipt of charge database (synonymous to an invoice database), wherein the amount corresponds to a generated receipt (synonymous to an invoice), wherein the receipt includes line item detail statements (Examiner notes that a receipt including line item details is considered an invoice)); combining, by the control device, the generated invoices in the invoice database to calculate an aggregated employer invoice amount at the end of a predetermined period based on a collective sum of the transactions associated with each member of an employer in column 10 line 28-column 11 line 21 (consolidating, by the host computer, the generated receipts in the receipt of charge database to calculate the employer's detailed transaction amount (synonymous to an aggregated employer invoice amount) at the end of a specified period of time based on the total transactions associated with employee (synonymous to a member of an employer)).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the applicant’s invention a method of processing healthcare payments through an individual coverage health reimbursement arrangement, as disclosed by Bull, to be combined with recording the authorization amount and clearing of the transaction as separate entries into an invoice database and combining the generated invoices to calculate an aggregated employer invoice amount at the end of a predetermined period based on a collective sum of the transactions, as disclosed by Harrison, for the purpose of minimizing costs of the employers when administering consumer-directed healthcare plans [column 2 lines 9-12].
As per Claim 5, Bull and Harrison disclose the method of claim 1, Bull also discloses wherein the payment card is issued to a member associated with a member checking account in paragraphs [0189-0190] and [0226] (a debit card is issued to each employee associated with user financial transaction information).
As per Claim 6, Bull and Harrison disclose the method of claim 1.
Bull does not disclose the following limitations. However, Harrison discloses wherein the generated invoice contains one or more recorded amounts in column 10 line 28-column 11 line 21 (the generated receipt includes line item detail statements (synonymous to one or more recorded amounts)).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the applicant’s invention of a method of processing healthcare payments through an individual coverage health reimbursement arrangement, as disclosed by Bull, to be combined with the generated invoice including one or more recorded amounts, as disclosed by Harrison, for the purpose of minimizing costs of the employers when administering consumer-directed healthcare plans [column 2 lines 9-12].
As per Claim 7, Bull discloses a method of processing healthcare payments through an individual coverage health reimbursement arrangement for tax savings in paragraph [0188] (a method of processing healthcare transactions through a health reimbursement account for tax savings (synonymous to an individual coverage health reimbursement arrangement)), the method comprising: receiving, by a control device, an authorization request related to a medical expense via a payment card associated with a member checking account in paragraph [0189] (receiving, by the server, a transaction related to a qualified medical expense via a debit card linked to the user financial transaction information (synonymous to a member checking account)); determining, by the control device, whether the medical expense is a qualified medical expense in paragraph [0441] (determining, by the server, whether the medical expense is a qualified medical expense); in response to the authorization request and the determination that the medical expense is a qualified medical expense, transferring, by the control device, an amount corresponding to the medical expense from a funding account to the member checking account in paragraphs [0436] and [0441] (in response to receiving an authorization request for the transaction and determining that the transaction is a qualified medical expense, transferring, by the server (synonymous to a control device) prior to posting (synonymous to clearing), the transaction ( synonymous to an authorization amount corresponding to the transaction) from electronic benefits account information (synonymous to a funding account) to the debit or credit transactions account (synonymous to the member checking account)); approving, by the control device, the authorization request and placing a hold on the member checking account based on the amount corresponding to the medical expense in paragraphs [0245] and [0347] and [0439] and Figure 9 (approving the authorization transaction request and temporarily place a memo-post transaction (synonymous to a hold) on the debit or credit transactions account (synonymous to the member checking account) until the transaction is posted); creating, by the control device, a transaction based on the authorization request in paragraphs [0433] and [0436] and [0441] (creating, by the server, a transaction based on the authorization request); transferring, by the control device, the amount from the member checking account to a seller associated with the transaction and canceling the hold on the member checking account in paragraphs [0189] and [0439] and Figure 9 (transferring an amount from the user financial transaction information (synonymous to a member checking account) to the merchant associated with the transaction and removing the memo-post on the debit or credit transactions account (Examiner notes that user financial transaction information indicates checking account)); creating, by the control device, an overage invoice if the amount of the transaction exceeds a balance associated with the member checking account in paragraphs [0191] and [0346-0347] and [0379] (creating a report (synonymous to an overage invoice), wherein the report identifies if the amount of transaction exceeds the balance of the qualified expense associated with an electronic checking account); debiting, by the control device, the aggregated employer invoice amount into a system batch account in paragraphs [0436] and [0439] and [0441] (debits the funds (synonymous to the aggregated employer invoice amount) with batch processing (Examiner notes that batch processing occurs in batch accounts)); and initiating, by the control device, a transfer from the system batch account to the funding account in paragraphs [0055] and [0436] and [0439] (initiate a transaction with batch processing to fund the electronic benefits account (synonymous to the funding account)).
Bull does not disclose the following limitations. However, Harrison discloses recording, by the control device, the amount of the transaction into an invoice database, wherein each recorded amount corresponds to a generated invoice in column 6 lines 42-52 and column 10 lines 28-column 11 line 21 (recording the transaction amount in a receipt of charge database (synonymous to an invoice database), wherein the amount corresponds to a generated receipt (synonymous to an invoice), wherein the receipt includes line item detail statements (Examiner notes that a receipt including line item details is considered an invoice)); combining, by the control device, the generated invoices in the invoice database to calculate an aggregated employer invoice amount at the end of a predetermined period based on a collective sum of the transactions associated with each member of an employer in column 10 line 28-column 11 line 21 (consolidate the generated receipts in the receipt of charge database to calculate the employer's detailed transaction amount (synonymous to an aggregated employer invoice amount) at the end of a specified period of time based on the total transactions associated with employee (synonymous to a member of an employer)).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the applicant’s invention a method of processing healthcare payments through an individual coverage health reimbursement arrangement for tax savings, as disclosed by Bull, to be combined with recording the authorization amount and clearing of the transaction as separate entries into an invoice database and combining the generated invoices to calculate an aggregated employer invoice amount at the end of a predetermined period based on a collective sum of the transactions, as disclosed by Harrison, for the purpose of minimizing costs of the employers when administering consumer-directed healthcare plans [column 2 lines 9-12].
As per Claim 8, Bull discloses a system in paragraphs [0005] (a system), comprising: a host server including one or more processors and non-transitory computer-readable media storing instructions in paragraphs [0095] and [0105] and [0324] and [0705] (a server (synonymous to a host server) including one or more processors and a computer-readable medium storing software or programmable code (synonymous to instructions)); a system database containing a funding account and a batch account in communication with the host server in paragraphs [0009-0010] and [0377] and [0440] and Figure 9A (an electronic benefits account transaction queue database (synonymous to a system database) including electronic benefits account information (synonymous to a funding account) and an electronic funding source information (synonymous to the batch account), wherein funding source information includes batch processing, in communication with a server); an invoice database containing a ledger, wherein the invoice database is in communication with the host server in paragraphs [0009-0010] and [0021] (a database (synonymous to an invoice database) including a record of healthcare transaction events (synonymous to a ledger), wherein the database is in communication with the server); a member database containing an employer operating account and a plurality of member checking accounts associated with each member of an employer, the member database in communication with the host server in paragraphs [0009-0010] and [0056] and [0436] (a profile database (synonymous to a member database) includes the electronic funding source or an employer payroll account (synonymous to an employer operating account) and electronic checking accounts associated with the user, in communication with the server); and a payment card issued to each member of the employer in paragraphs [0189-0190] and [0226] (a debit card is issued to each employee); wherein execution of the instructions by the one or more processors of the host server causes the host server to: a) receive a transaction related to a qualified medical expense via the payment card linked to the member checking account of a member in paragraphs [0189] (receiving, by the server, a transaction related to a qualified medical expense via a debit card linked to the user financial transaction information (synonymous to a member checking account)); b) fund an amount corresponding to the transaction from the funding account on the system database to the member checking account in paragraph [0441] (fund a transaction amount from the employer payroll funding account on an electronic benefits account transaction queue database to the user financial transaction information); c) transfer the amount from the member checking account to a seller associated with the transaction in paragraphs [0189] and [0439] and Figure 9 (transfer the transaction from the user financial transaction information to the merchant associated with the transaction); f) debit the aggregated employer invoice amount from the employer operating account for the predetermined period in paragraphs [0436] and [0439] and [0441] (debits the funds (synonymous to the aggregated employer invoice amount) from the electronic funding source or an employer payroll account for a particular time period); g) pay the aggregated employer invoice amount into the batch account on the system database in paragraphs [0436] and [0439] (deposit the funds with batch processing (Examiner notes that batch processing occurs in batch accounts)); and h) initiate a transfer from the batch account to the funding account in paragraphs [0055] and [0436] and [0439] (initiate a transaction with batch processing to fund the electronic benefits account (synonymous to the funding account)).
Bull does not disclose the following limitations. However, Harrison discloses d) record the amount of the transaction into the invoice database, wherein each recorded amount corresponds to a generated invoice in column 6 lines 42-52 and column 10 lines 28-column 11 line 21 (recording the transaction amount in a receipt of charge database (synonymous to an invoice database), wherein the amount corresponds to a generated receipt (synonymous to an invoice), wherein the receipt includes line item detail statements (Examiner notes that a receipt including line item details is considered an invoice)); e) combine the generated invoices in the invoice database to calculate an aggregated employer invoice amount at the end of a predetermined period based on a collective sum of the transactions associated with each member of an employer in column 10 line 28-column 11 line 21 (consolidate the generated receipts in the receipt of charge database to calculate the employer's detailed transaction amount (synonymous to an aggregated employer invoice amount) at the end of a specified period of time based on the total transactions associated with employee (synonymous to a member of an employer)).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the applicant’s invention a system including a host server, a system database, an invoice database, a member database, debiting the aggregated employer invoice amount, pay the aggregated employer invoice amount, and initiate a transfer from the batch account to the funding account, as disclosed by Bull, to be combined with recording the authorization amount and clearing of the transaction as separate entries into an invoice database and combining the generated invoices to calculate an aggregated employer invoice amount at the end of a predetermined period based on a collective sum of the transactions, as disclosed by Harrison, for the purpose of minimizing costs of the employers when administering consumer-directed healthcare plans [column 2 lines 9-12].
As per Claim 9, Bull and Harrison disclose the system of claim 8, Bull also discloses further comprising one or more computer processors configured to execute the instructions stored on the non- transitory computer-readable media in paragraphs [0324] and [0705] (one or more processors to execute the software or programmable code on the computer readable medium).
As per Claim 10, Bull and Harrison disclose the system of claim 8, Bull also discloses a non-transitory computer program product embodied on a computer readable medium having instructions that, which, when executed by one or more processors of the host server of the system of claim 8, cause the host server to perform operations (a) through (h) of claim 8 in paragraph [0705] (a computer-readable program on a computer readable medium having software or programmable, which is executed by a processor of server).
As per Claim 11, Bull discloses a method of processing healthcare payments through an individual coverage health reimbursement arrangement in paragraph [0188] (a method of processing healthcare transactions through a health reimbursement account (synonymous to an individual coverage health reimbursement arrangement)), the method comprising: receiving, by a host server, a transaction related to a qualified medical expense via a payment card linked to a member checking account in paragraphs [0189] (receiving, by the server, a transaction related to a qualified medical expense via a debit card linked to the user financial transaction information (synonymous to a member checking account)); in response to receiving an authorization request for the transaction and determining, by the host server, that the transaction is a qualified medical expense, transferring, by the host server prior to clearing, an authorization amount corresponding to the transaction from a funding account to the member checking account in paragraphs [0436] and [0441] (in response to receiving an authorization request for the transaction and determining that the transaction is a qualified medical expense, transferring, by the server (synonymous to a control device) prior to posting (synonymous to clearing), the transaction ( synonymous to an authorization amount corresponding to the transaction) from electronic benefits account information (synonymous to a funding account) to the debit or credit transactions account (synonymous to the member checking account)) and placing, by the host server, a hold in the member checking account for the authorization amount in paragraphs [0009] and [0439] and Figure 9 (a memo-post transaction (synonymous to a hold) is temporarily placed on the debit or credit transactions account (synonymous to the member checking account), by the server, for the transaction (synonymous to the authorization amount)); upon clearing, transferring, by the host server, the authorization amount from the member checking account to a seller associated with the transaction and canceling the hold in paragraphs [0189] and [0439] and Figure 9 (upon posting the transaction (synonymous to clearing the transaction), transferring, by the server, the transaction from the user financial transaction information (synonymous to a member checking account) to the merchant associated with the transaction and removing the memo-post on the debit or credit transactions account (Examiner notes that user financial transaction information indicates checking account)); debiting, by the host server, the aggregated employer invoice amount from an employer operating account for the predetermined period in paragraphs [0169] and [0436] and [0439] and [0441] and [0469] (debiting, by the server, the funds (synonymous to the aggregated employer invoice amount) from the electronic funding source or an employer payroll account (synonymous to an employer operating account) for a particular time period); paying, by the host server, the aggregated employer invoice amount into a system batch account in paragraphs [0169] and [0436] and [0439] and [0469] (depositing, by the server, the funds with batch processing (Examiner notes that batch processing occurs in batch accounts)); and initiating, by the host server, a transfer from the system batch account to the funding account in paragraphs [0055] and [0169] and [0436] and [0439] and [0469] (initiating, by the server, a transaction with batch processing to fund the electronic benefits account (synonymous to the funding account)).
Bull does not disclose the following limitations. However, Harrison discloses recording, by the host server, the authorization request and the clearing event as separate ledger entries with unique identifiers in an invoice database, wherein each recorded event corresponds to a generated invoice in column 6 lines 42-52 and column 9 lines 33-55 and column 10 lines 28-column 11 line 21 (recording, by the host computer, the authorization amount and a post-sale transaction as receipts into a receipt of charge database (synonymous to an invoice database), wherein the amount corresponds to a generated receipt (synonymous to an invoice), wherein the receipt includes line item detail statements (Examiner notes that a receipt including line item details is considered an invoice)); combining, by the host server, at the end of a predetermined period, the generated invoices in the invoice database to calculate an aggregated employer invoice amount based on a collective sum of the transactions associated with each member of an employer in column 10 line 28-column 11 line 21 (consolidating, by the host computer, the generated receipts in the receipt of charge database to calculate the employer's detailed transaction amount (synonymous to an aggregated employer invoice amount) at the end of a specified period of time based on the total transactions associated with employee (synonymous to a member of an employer)).
As per Claim 12, Bull and Harrison disclose the method of claim 1, Bull also discloses wherein placing the hold comprises creating, by the control device, a hold record in the invoice database that is linked to the authorization amount and is automatically released when the transaction clears in paragraphs [0014] and [0021] and [0189] and [0439] and Figure 9 (creating a memo posting entry (synonymous to an hold record) in the healthcare transaction events database (synonymous to an invoice database) that is linked to the transaction and is removed when the actual transaction is posted).
As per Claim 13, Bull and Harrison disclose the method of claim 7.
Bull does not disclose the following limitations. However, Harrison discloses wherein the step of combining, by the control device, the generated invoices in the invoice database includes programmatically linking each of the generated invoices to an employer payroll system for deduction during a subsequent payroll cycle in column 10 line 28-column 11 line 21 and column 11 lines 35-43 (linking the generated receipts to a corporation or employer expense base (synonymous to an employer payroll system) for deduction during the next payroll cycle).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the applicant’s invention of a method of processing healthcare payments through an individual coverage health reimbursement arrangement for tax savings, as disclosed by Bull, to be combined with recording the authorization amount and clearing of the transaction as separate entries into an invoice database and combining the generated invoices to calculate an aggregated employer invoice amount at the end of a predetermined period based on a collective sum of the transactions, as disclosed by Harrison, for the purpose of minimizing costs of the employers when administering consumer-directed healthcare plans [column 2 lines 9-12].
As per Claim 15, Bull and Harrison disclose the method of claim 1, Bull also discloses wherein the funding account comprises one of a system operational account, an employer-owned account, a member-owned account, or any combination thereof, and wherein the control device selects among the accounts based on a funding preference associated with a member in paragraphs [0188] and [0190] (electronic benefits account information includes an employer-owned account, wherein the server determines the account based on the account that are eligible to pay for the transaction).
As per Claim 16, Bull and Harrison disclose the method of claim 1, Bull also discloses wherein transferring the authorization amount from the funding account to the member checking account is performed only in response to a determination that the transaction is for an insurance premium or an approved medical expense based on at least one of merchant category code analysis, transaction descriptors, or a trained classifier in paragraphs [0190] and [0237-0238] and [0436] and [0441] (transferring the authorization transaction from electronic benefits account information (synonymous to a funding account) to the user financial transaction information is performed only in response to determining that the transaction is an approved medical expense based on a merchant category code (Examiner notes that the merchant category code meets the "at least one of" limitation)).
As per Claim 17, Bull and Harrison disclose the system of claim 8, Bull also discloses wherein the funding account comprises at least one of a system operational account, an employer-owned account, or a member-owned account, and the host server selects the funding account based on a funding preference associated with a member in paragraphs [0188] and [0190] (electronic benefits account information (synonymous to a funding account) includes an employer-owned account, wherein the server determines the account based on the account that are eligible to pay for the transaction).
As per Claim 19, Bull and Harrison disclose the system of claim 8, Bull also discloses wherein the host server is further configured to fund the member checking account only after determining that the transaction is associated with an insurance premium or an approved medical expense based on at least one of merchant category code analysis, transaction descriptors, or a trained classifier in paragraphs [0190] and [0237-0238] and [0436] and [0441] (transferring the authorization transaction from electronic benefits account information (synonymous to a funding account) to the user financial transaction information is performed only in response to determining that the transaction is an approved medical expense based on a merchant category code (Examiner notes that the merchant category code meets the "at least one of" limitation)).
Claims 2, 4, 14 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Bull et al. (US-20200402670-A1)[hereinafter Bull], in view of Harrison et al. (US-7922083-B2)[hereinafter Harrison], in view of Heffley (US-8595031-B1)[hereinafter Heffley].
As per Claim 2, Bull and Harrison disclose the method of claim 1.
Bull and Harrison do not disclose the following limitations. However, Heffley discloses wherein the step of receiving a transaction related to a qualified medical expense via a payment card, further comprises determining if an amount of the transaction exceeds a predetermined member balance associated with the member checking account and, when the amount of the transaction exceeds the predetermined member balance, generating an overage invoice associated with the transaction in column 12 line 4-column 13 line 6 and Figure 2 and Figure 9 (determine if the balance-due amount (synonymous to an amount of the transaction) exceeds the funds available (synonymous to a predetermined member balance) in the participant's account (synonymous to the member checking account), when the balance-due amount exceeds the funds available, generating a virtual adjudicated claim (synonymous to an overage invoice) associated with the transaction).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the applicant’s invention for a method of processing healthcare payments through an individual coverage health reimbursement arrangement, as disclosed by Bull and Harrison, to be combined with the determining if an amount of the transaction exceeds a predetermined member balance and generating an overage invoice when it does, as disclosed by Heffley, for the purpose of improving the efficiency and cost of health reimbursements [column 1 lines 24-57].
As per Claim 4, Bull and Harrison disclose the method of claim 1.
Bull and Harrison do not disclose the following limitations. However, Heffley discloses wherein the step of receiving, by the control device, a transaction related to a qualified medical expense via a payment card, further comprises receiving, by the control device, a plurality of transactions related to qualified medical expenses via a plurality of payment cards associated with a plurality of member checking accounts in column 13 lines 7-33 and Figure 3 (receive one or more transactions related to eligible healthcare expenses (synonymous to qualified medical expenses) via virtual debit cards (synonymous to payment cards) associated with participants accounts (Examiner notes the applicant's spec discloses that the payment card includes a virtual card)).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the applicant’s invention for a method of processing healthcare payments through an individual coverage health reimbursement arrangement, as disclosed by Bull and Harrison, to be combined with the receiving a plurality of transactions related to qualified medical expenses via a plurality of payment cards associated with a plurality of member checking accounts, as disclosed by Heffley, for the purpose of improving the efficiency and cost of health reimbursements [column 1 lines 24-57].
As per Claim 14, Bull, Harrison, and Heffley disclose the method of claim 2.
Bull and Harrison do not disclose the following limitations. However, Heffley discloses further comprising updating, by the control device, an employer payroll system with payroll deductions corresponding to overage invoices generated for members whose transactions exceed a predetermined member balance, the updating occurring prior to the next payroll cycle in column 12 line 4-column 13 line 6 and column 17 lines 13-35 and Figure 2 and Figure 9 (adjusting the employer account set with payroll deductions corresponding to the virtual adjudicated claim generated for participants whose balance-due amount exceeds the funds available, the adjusting occurring prior to the next payroll cycle).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the applicant’s invention for a method of processing healthcare payments through an individual coverage health reimbursement arrangement, as disclosed by Bull and Harrison to be combined with updating an employer payroll system with payroll deductions corresponding to overage invoices generated for members whose transactions exceed a predetermined member balance, as disclosed by Heffley, for the purpose of improving the efficiency and cost of health reimbursements [column 1 lines 24-57].
As per Claim 18, Bull and Harrison disclose the system of claim 8.
Bull and Harrison do not disclose the following limitations. However, Heffley discloses wherein the host server is further configured to update an employer payroll system with payroll deductions corresponding to overage invoices for members whose transactions exceed a predetermined member balance in column 12 line 4-column 13 line 6 and column 17 lines 13-35 and Figure 2 and Figure 9 (adjusting the employer account set with payroll deductions corresponding to the virtual adjudicated claim generated for participants whose balance-due amount exceeds the funds available).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the applicant’s invention for a system database, an invoice database, a member database, debiting the aggregated employer invoice amount, pay the aggregated employer invoice amount, and initiate a transfer from the batch account to the funding account, as disclosed by Bull and Harrison, to be combined with updating an employer payroll system with payroll deductions corresponding to overage invoices generated for members whose transactions exceed a predetermined member balance, as disclosed by Heffley, for the purpose of improving the efficiency and cost of health reimbursements [column 1 lines 24-57].
Response to Arguments
Applicant’s arguments, see Page 8, “Rejections Under 35 U.S.C. § 112”, filed 12/23/2025, with respect to claims 8-9 have been fully considered and are persuasive. The claim rejections of claims 8-9 have been withdrawn.
Applicant's arguments, see Pages 8-10, “Rejections Under 35 U.S.C. § 101”, filed 12/23/2025 with respect to claims 1, 7, and 8 have been fully considered but they are not persuasive.
Applicant argues that the amended claims provide integration into a practical application through an improvement in electronic payment processing and settlement of transactions in ICHRA/HAS contexts. Examiner respectfully disagrees. The claims do not recite an improvement to electronic payment processing technology. The claims merely recite receiving a transaction, transferring an authorization amount corresponding to the transaction in response to receiving an authorization request and determining that the transaction is a qualified medical expense, placing a hold on the member checking account for the authorization amount, transferring the authorization amount from member checking account to a seller, cancelling the hold, recording the authorization amount, combining the generated invoices to calculate an aggregated employer invoice amount, debiting the aggregated employer invoice amount, paying the aggregated employee invoice amount, and initiating a transfer of accounts, which are a part of the abstract idea. An improvement to the abstract ideas of receiving a transaction, transferring an authorization amount corresponding to the transaction in response to receiving an authorization request and determining that the transaction is a qualified medical expense, placing a hold on the member checking account for the authorization amount, transferring the authorization amount from member checking account to a seller, cancelling the hold, recording the authorization amount, combining the generated invoices to calculate an aggregated employer invoice amount, debiting the aggregated employer invoice amount, paying the aggregated employee invoice amount, and initiating a transfer of accounts does not amount to an improvement to technology or a technical field (see MPEP § 2106.05(a)(II) stating “it is important to keep in mind that an improvement in the abstract idea itself (e.g. a recited fundamental economic concept) is not an improvement in technology."). The courts indicated in TLI Communications, 823 F.3d at 612-13, 118 USPQ2d at 1747-48, that gathering and analyzing information using conventional techniques and providing the output is not sufficient to show an improvement to technology. The claim language and instant application fails to provide details regarding how a computer aids the method, the extent to which the computer aids the method, or the significance of a computer to the performance of the method. Here, the improvement is to receiving a transaction, transferring an authorization amount corresponding to the transaction in response to receiving an authorization request and determining that the transaction is a qualified medical expense, placing a hold on the member checking account for the authorization amount, transferring the authorization amount from member checking account to a seller, cancelling the hold, recording the authorization amount, combining the generated invoices to calculate an aggregated employer invoice amount, debiting the aggregated employer invoice amount, paying the aggregated employee invoice amount, and initiating a transfer of accounts. There is no indication in the disclosure that the involvement of a computer assists in improving the technology for the outlined problem statement. Merely adding generic computer components to perform the method is not sufficient.
Applicant’s arguments, see Page 10, “Rejections Under 35 U.S.C. § 103”, filed 12/23/2025 with respect to claims 1-10 have been fully considered. With regards to Claims 1, 7, and 8, Applicant argues that neither Fredman, Harrison, Bull, Heffley or Davidson, alone or in combination, disclose or suggest the amended independent claims. Examiner disagrees and points Applicant to the updated rejection and citations in the 103 rejections above. In response to the argument that the references do not disclose or suggest transferring funds from a defined funding account into a member checking account at authorization time, approving the authorization, placing a hold, and subsequently clearing the transaction, paying the seller, and canceling the hold, Examiner respectfully disagrees. Bull discloses in paragraphs [0436] and [0441] transferring funds from a funding account into a member checking account at the time of authorization. Additionally, Bull discloses in paragraphs [0245], [0347], and [0439] approving the authorization transaction, paragraph [0439] discloses placing a temporary memo-post transaction (synonymous to a hold), and paragraphs [0189] and [0439] disclose posting or clearing the transaction, paying the seller, and cancelling the hold.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Pletz et al. (US 20140297307 A1) teaches a system and method for processing qualified healthcare account transactions within a transaction processing system.
Rubleski, Jeff S. “An emerging health insurance option primarily for small business – individual coverage HRA” (2021) teaches on individual coverage HRA
THIS ACTION IS MADE FINAL. 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 KRYSTEN N WRIGHT whose telephone number is (571)272-5116. The examiner can normally be reached Monday thru Friday 8 - 5 pm, ET.
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, Fonya Long can be reached on (571)270-5096. 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.
/K.N.W./Examiner, Art Unit 3682
/FONYA M LONG/Supervisory Patent Examiner, Art Unit 3682