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 .
DETAILED ACTION
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 3, 5 – 12 and 14 – 20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 5 and 14 each recite “a second set of database transactions that updates a second record, wherein the second record is linked to the source record”. Parent claim 4 recites “an amount associated with a dependent record that is linked to a source record”, and parent claim 13 recites “wherein the dependent record is linked to a source record”. Claims 5 and 14 thus introduce “a second record” defined only by the same relationship already recited for the dependent record, namely being linked to the source record. It cannot be determined whether the “second record” is the dependent record of the parent claim or a different, additional record. The two constructions differ materially in scope: under the first, the second set of database transactions updates the same dependent record whose field is increased in claims 4 and 13; under the second, the claims require an additional record linked to the source record whose role in the transfer is not stated.
The ambiguity extends to the sets of database transactions. Claims 4 and 13 each recite “causing a set of database transactions that reduces a field of the source record by the amount and increases a field of the dependent record by the amount in response to the indication that the amount is validated”. Claims 5 and 14 then recite “obtaining the second identifier and the second amount based on a second set of database transactions”. The claims do not establish whether the set of database transactions of claims 4 and 13 is the “second set of database transactions,” the “first set of database transactions,” or a further set. If the second record is the dependent record and the set of claims 4 and 13 is the second set, the claims are circular, because the second amount would be obtained based on transactions that are themselves caused in response to the indication that the second amount is validated. The specification does not resolve these questions: it states that “ordinal numbers used to denote an item do not define the item's position” (0076), and the enumerated embodiments use “second record” for the debited record (“causing a second set of database transactions that reduces a field of the second record by the amount and increases a field of the first record by the amount” (0079); see also (0081). That usage does not identify which record in claims 5 and 14 is the second record, or map the transaction sets of claims 5 and 14 to the set recited in their parent claims. Because claims 5 and 14 are amenable to two or more plausible constructions as to which record is updated by the second set of database transactions and which set of transactions is caused in response to the validation, claims 5 and 14 are indefinite. Claims 6-12 depend from claim 5 and claims 15-20 depend from claim 14; each fails to cure, and therefore includes, this defect.
Claims 6 and 15 additionally operate on “the second record” (“freezing the second record when obtaining the indication that the second amount is validated”), so the record that is frozen is likewise uncertain. Applicant is required to state expressly whether the second record is the dependent record (e.g., by reciting “the dependent record” in place of “a second record”) or, if a different record is intended, to recite that record's relationship to the dependent record, and to recite the relationship between the set of database transactions of claims 4 and 13 and the first and second sets of database transactions of claims 5 and 14.
Claim 3 recites “wherein a client device independently determines the earlier identifier using image processing techniques”. The claim does not state what the client device is independent of, e.g., the one or more processors of the claimed system, a server, a user, or other devices, and the term “independently” does not appear in the specification, which therefore provides no standard for measuring the required independence. The closest disclosure describes a federated arrangement in which “a server may send model parameters to a client computing device to allow the client computing device to perform some or all of a prediction operation using a neural network or another machine learning model” (0048). The specification thus contemplates client-side determinations that depend on server-supplied parameters and that may constitute only part of the prediction operation, and a person of ordinary skill in the art cannot determine whether such a determination is “independent” within the meaning of the claim. Because neither the claim nor the specification supplies a reference point or objective boundary for “independently”, claim 3 fails to inform one of ordinary skill in the art of its scope with reasonable certainty. Applicant is required to delete the term or to recite the reference against which independence is measured (e.g., that the client device determines the earlier identifier with a local version of a prediction model and provides the earlier identifier to the one or more processors), with identification of supporting disclosure.
Claim 11 recites determining “that a timestamp associated with the second set of database transactions is within a temporal boundary characterized by the first set of database transactions”. Claim 20 recites “wherein obtaining the second amount comprises obtaining a timestamp” and determining “that the timestamp is within a temporal boundary characterized by the first set of database transactions”. The claims do not identify the nexus by which the first set of database transactions characterizes the temporal boundary: it cannot be determined whether the boundary begins or ends at a time of the first set, spans the first set, extends some duration before or after a time of the first set, or is merely influenced by the first set in some unstated way. The specification does not use the phrase “temporal boundary” or define what it means for a boundary to be “characterized by” a set of database transactions. The specification describes, as one example, determining “whether a time difference between a timestamp of a first set of database transactions initiated by a third party and a timestamp of a second set of database transactions initiated by a first user is within a duration threshold” (0041), but that example does not define the broader relationship recited in the claims. Claim 20 is further unclear because the timestamp obtained as part of “obtaining the second amount” is not tied to any event or data; it cannot be determined whether the timestamp marks the second set of database transactions, the capture of metadata, the obtaining step itself, or some other event. Claims 11 and 20 therefore fail to inform one of ordinary skill in the art of their scope with reasonable certainty. Applicant is required to recite how the temporal boundary is determined from the first set of database transactions (e.g., a recited duration threshold relative to a timestamp of the first set of database transactions) and, in claim 20, the event that the obtained timestamp indicates.
Claim 13 recites one or more non-transitory, computer-readable media storing instructions that, when executed, “cause the one or more processors to perform operations comprising” the recited acts. Claim 14, which depends from claim 13, recites “wherein the amount is a second amount, further comprising: obtaining a first amount” and then further acts of obtaining and retrieving. Claim 14 does not recite that the operations further comprise these acts. As drafted, the acts are recited as further elements of the claimed media, which are articles of manufacture, rather than as operations performed by a processor executing the stored instructions. Claims 15, 17, and 18, which depend from claim 14, recite “the operations further comprising”, confirming that the claims distinguish between the media and the operations performed upon execution of the stored instructions. A single claim that recites both an article and acts that are not attributed to that article is indefinite, because it is unclear whether the claim is directed to the article or to the performance of the acts.
Claims 15-20 depend from claim 14 and include this defect. Applicant is required to amend claim 14 to recite language such as “the operations further comprising” in place of “further comprising”.
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 2, 3, 5 – 12 and 14 – 20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claims contain subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor had possession of the claimed invention at the time the application was filed. The written description requirement is satisfied only if the specification reasonably conveys to a person of ordinary skill in the art that the inventor had possession of the claimed subject matter as of the filing date.
Claim 2 recites “querying a networked database with a first query comprising the earlier identifier to retrieve a first category value”, “querying the networked database with a second query comprising the later identifier to retrieve a second category value”, and “wherein obtaining the indication that the later amount is validated comprises validating the later amount based on the first category value matching the second category value and
the earlier amount matching the later amount”. Claim 2 thus requires, as the basis for validating the later amount, the conjunction of (1) a match between two category values, each retrieved by a query comprising a respective earlier or later identifier, and (2) a match between the earlier amount and the later amount.
The specification does not describe this conjunction. It describes retrieving a category with a query comprising an object identifier: “some embodiments may retrieve a record from a database by using a query that includes the object identifier, where a record value of the record may be the name of an object category” (0051). Categories so retrieved are tested for membership in a set of permitted or prohibited object categories (0055 and 0062), not compared with a category retrieved for another transaction.
The closest cross-transaction disclosure compares object identifiers, not database-retrieved category values, and results in a configuration change for future transactions rather than validation of the later amount: “Some embodiments may determine whether this later-determined object identifier matches the previous object identifier and that a set of criteria is satisfied. If a match is detected and any of the set of criteria is satisfied, some embodiments may update a configuration value associated with the first user's record that enables additional transfers from the second user's record without requiring the first user to provide additional metadata for future transactions.” (0040). Paragraph (0041) describes a cross-transaction comparison of merchant category codes carried in transaction data (“some embodiments may determine whether a merchant category code of transaction data for a first set of transactions matches a merchant category code of transaction data of a later device-provided data for a later transaction” (0041), but a merchant category code carried in transaction data is not a category value retrieved by querying a database with a query comprising an identifier, and (0041) is not described in combination with any amount comparison. Paragraph (0046) uses an identifier match only for
data-storage management, to “delete the earlier-obtained image data while re-associating the earlier set of database transactions with the later-obtained image data” (0046).
Further, no passage of the specification compares an earlier amount with a later amount to determine whether they match. The amount tests disclosed are a fixed ceiling (“later transactions may be verified for reimbursement or other actions if the corresponding transaction amount is less than a transaction amount threshold” (0043) and a threshold range derived from the price history of an identified object (0058). The statement that “The amount that is transferred is equal to the amount by which the first record was reduced.” (0022) describes the reimbursement amount for a single transaction, not a comparison between amounts of an earlier and a later transaction used to validate the later amount. The general statement that “the features and limitations described in any one embodiment may be applied to any other embodiment herein” (0066) does not direct a person of ordinary skill in the art to the specific claimed combination; written description is not satisfied by a disclosure from which the claimed combination could be assembled by picking and choosing among separately described features. In re Ruschig, 379 F.2d 990, 994-95 (CCPA 1967); Purdue Pharma L.P. v. Faulding Inc., 230 F.3d 1320, 1326-27 (Fed. Cir. 2000); MPEP 2163(II)(A)(3)(b); MPEP 2163.05. Claim 2 is therefore rejected. Claim 3 depends from claim 2; its additional limitations (a client device determining the earlier identifier using image processing techniques, and obtaining the earlier identifier from a client device) do not supply the missing description of the validation recited in claim 2, and claim 3 is rejected for the same reasons.
Claim 5 recites “wherein obtaining the indication that the second amount is validated comprises determining that the second amount is validated based on (1) the first category value matching the second category value and (2) the first amount being within the threshold range of the second amount”.
Claim 14 similarly recites “determining that the second amount is validated
based on a set of results indicating that (1) the first category value matches the second category value and (2) the first amount is within a threshold range of the second amount”. In claims 5 and 14, the first and second category values are retrieved by querying a database with queries comprising a first identifier (associated with a first amount indicated by a first set of database transactions) and a second identifier (obtained based on a second set of database transactions), respectively.
For the reasons set forth above, the specification does not describe comparing category values retrieved for two different sets of database transactions as a basis for validating an amount; retrieved object categories are tested only against a set of permitted or prohibited categories (0055 and 0062), and the specification's earlier/later comparison (0040) compares object identifiers of transactions whose records “may be unrelated to each other” (0040) and updates a configuration value rather than validating the amount of the later transaction. With respect to the requirement that the first amount be within a threshold range of the second amount, the only disclosed threshold-range validation derives the range from the price history of an identified object and tests a current price against it: “Some embodiments may, after identifying an object, retrieve previous prices associated with the object identifier.” (0058); “Some embodiments may then determine a threshold range based on the history of price values.” (0058). The specification does not describe a threshold range defined relative to a second amount of a second set of database transactions within which a first amount of a first set of database transactions must fall, and the fixed transaction-amount threshold of (0043) is a ceiling rather than a range associated with another amount. No passage describes the conjunctive test of (1) a match of database-retrieved category values and (2) an amount-within-range condition as the basis for validating the second amount. The claimed combination is, at most, assembled from separate passages without explicit directions directing a person of ordinary skill in the art to it, and therefore does not demonstrate possession of the claimed subject matter. Ruschig, 379 F.2d at 994-95; Purdue Pharma, 230 F.3d at 1326-27; MPEP 2163(II)(A)(3)(b); MPEP 2163.05. Claims 5 and 14 aretherefore rejected. Claims 6-12 depend from claim 5 and claims 15-20 depend from claim 14; each includes the unsupported validation combination, none supplies the missing description, and each is rejected for the same reasons.
Claims 6 and 15 each recite “freezing the second record when obtaining the indication that the second amount is validated”, in addition to the requirement of the parent claims that a set of database transactions increase a field of the dependent record in response to that indication. The only disclosure of freezing states that, based on a current price being within a threshold range, “the second set of database transactions may represent a transfer operation, a record-flagging operation, a record-freezing operation that prevents one or more fields of a record from being updated, etc.” (0058). That passage lists alternative forms that the second set of database transactions may take, and refers only to “a record”. It does not describe freezing the second record, i.e., the record that is updated by the second set of database transactions from which the second amount is obtained and that is linked to the source record, as a further act performed when the validation indication is obtained, together with a transfer that increases a field of the dependent record. The only other disclosure of preventing record updates occurs on the opposite condition and for a different record: “in response to a determination that the object category or other metadata does not satisfy a set of transaction criteria, some embodiments may update a configuration value associated with the first record to prevent further updates to a selected field of the first record” (0059). Selecting two items from a list of alternatives and combining them with a particular record, without instructions directing a person of ordinary skill in the art to that combination, does not show possession of the claimed subject matter. Ruschig, 379 F.2d at 994-95; MPEP 2163(II)(A)(3)(b); MPEP 2163.05. Claims 6 and 15 are rejected on this additional ground.
Claim 9 recites “further comprising obtaining audio data captured by a client device, wherein determining that the second amount is validated comprises determining that the audio data satisfies a set of criteria”. Claim 18 recites “obtaining audio data captured by a client device, wherein determining that the second amount is validated comprises determining that the audio data satisfies a set of criteria”. The term “audio” appears in only two paragraphs of the specification, in each case as an item in a list of data types: “The set of servers 232 may receive metadata such as image data, location data, audio data, or other types of data from a client computing device 290 associated with transaction data provided by a card reader device 202.” (0025); and augmenting transaction data “with other types of data provided by a client computing device, such as image data, geographical data, audio data, other sensor data, etc” (0045). Paragraph (0025) further states generically that “Based on whether a set of criteria is satisfied by the object categories or other data, the set of servers 232 may then initiate operations to permit a second set of database operations.” (0025). The specification does not describe any criterion that audio data satisfies, any processing or analysis of audio data, or any relationship between the content of audio data and the validity of a transaction amount; every validation technique that is actually described operates on image-derived object identifiers and categories, transaction data, geolocation, timestamps, merchant category codes, or prices. The generic reference in (0025) to criteria satisfied by “other data” is a statement of a desired result and does not describe how audio data is evaluated to validate an amount. A recitation of a data type together with the desired result of evaluating it does not show possession of the claimed function. MPEP 2161.0l(I); MPEP 2163(II)(A)(3)(a). Claims 9 and 18 are rejected on this additional ground.
Claim 12 recites “further comprising determining the threshold range based on geographical location data provided by a client device”. The only disclosed manner of determining a threshold range is from price history: “Some embodiments may then determine a threshold range based on the history of price values” (0058). Geographical location data is identified only as a possible basis for the current price that is compared with the range: “Some embodiments may then determine a current price based on transaction data or metadata associated with the transaction data (e.g., image data, geographical location data, etc.)” (0058). Elsewhere, geographical data is used to test a permitted geographic boundary (0057), to set a reimbursement flag (0026), or to determine a merchant category code (0056); none of these passages determines a threshold range. The specification therefore does not describe determining the threshold range based on geographical location data provided by a client device. MPEP 2163(II)(A)(3)(b); MPEP 2163.05. Claim 12 is rejected on this additional ground.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Claim 1 is rejected under 35 U.S.C. 103 as being unpatentable over Peyret (US Pub. No. 2007/0017976) in view of Famzoo (Famzoo Prepaid Card, 2016 retrieved from: https://web.archive.org/web/20221226081319/https://blog.famzoo.com/p/famzoo-card-faqs.html) in view of Arora (US Pub. No. 2019/0079953 A1).
Per claim 1, Peyret (US Pub. No. 2007/0017976) is relied upon to teach a system for updating network database records while maintaining validation ) (reads on "Back-end system 340 interfaces with child account 350 for child charges and reports 338; it interfaces with parent account 360 for parent charges and reports 364," see Peyret para 0053. Peyret's back-end system updates the child and parent accounts, which Peyret states "are essentially database records, hosted on servers" (see Peyret para 0053) and reached over networks, "Thus, the system of FIG. 5 usually encompasses a plurality of physical servers and communication networks" (see Peyret para 0053)), the system comprising one or more processors and a set of non-transitory, computer-readable storage media storing instructions that, when executed by the one or more processors (a necessary limitation of having back-end physical servers, see Peyret para 0053); that the amount is validated (Peyret confirms that a parent-child card system identifies the validity of the submitted evidence and the associated amount before the linked accounts are credited and charged, "In a step 535 the proof-of-purchase evidence is analyzed by rebate module 344R, in comparison to the rules data elements intended to produce rebate-class results data from rules data field 314 of child account 350, to identify the validity of the evidence and the associated rebate amount." (see Peyret para 0066).); causing a second set of network database transactions (reads on "Thus, back-end system 340 includes a conventional charge back-end system 280 for charging amounts to parent account 360 and child account 350 and transferring funds to merchant account 260," see Peyret para 0055. Peyret's back end is a conventional charge system that posts charges to the server-hosted parent and child account records, and the same back end credits the child account record, "the rebate amount is credited (i.e. added) to child account 350" (see Peyret para 0066), and it operates over networks, "Thus, the system of FIG. 5 usually encompasses a plurality of physical servers and communication networks" (see Peyret para 0053); These two entries are new transactions distinct from the child's earlier expense debit: they come later (after approval), they touch the funding record as well as the child record, and they run in the opposite direction on the child record.)[AltContent: textbox (()] increases a field of the dependent record (reads on "the rebate amount is credited (i.e. added) to child account 350," see Peyret para 0066. Crediting ("added") the child account record increases the value held in that record; Peyret's child account 350 carries limit 116, "Log 112, limit 116 and optional restrictions 120 are as described above with respect to the background art of FIGS. lA-B." (see Peyret para 0044), that is, "a limit 116 that represents the instant amount that can be spent" (see Peyret para 0011), and Peyret's own embodiment moves parent funds into that record by "selectably transferring funds from parent account 360 to replenish child account 350" (see Peyret para 0053).) that reduces a field of the source record In the combination that account is a server-hosted database record, "It will be noted that child account 350, parent account 360 and merchant account 260 are essentially database records, hosted on servers that are managed by card issuers and transaction acquirers." (see Peyret para 0053), and its balance is a field of that record.); in response to the indication that the amount is validated Peyret follows the same order at the record level: after the validity and amount are identified in step 535, "Then in a step 539 the rebate amount is credited (i.e. added) to child account 350 and charged[AltContent: textbox (()] to parent account 360, and the particulars are recorded into child account 350 (log 112) and the log of parent account 360 (not shown) for generating the monthly statement.11 see Peyret para 0066)). The prior art of record is silent on explicitly stating obtaining, from a client device, an identifier and an amount indicating a first set of network database transactions to update a dependent record of a dependent user, wherein the dependent record is linked to a source record of a controlling user; obtaining an indication that the amount is validated; and causing a second set of network database transactions that reduces a field of the source record by the amount and increases a field of the dependent record by the amount in response to the indication that the amount is validated.
Famzoo (Famzoo Prepaid Card, 2016) is relied upon to teach obtaining, from a client device (reads on "Submit the form to finish handling the reimbursement," see FamZoo p. 24. The parent reaches the Reimburse This? form by selecting the pending expense in the Transactions page, "In the desktop interface, click on the Reimbursement Pending status label." (see FamZoo p. 24) or the mobile equivalent, and submitting that form sends its contents from the parent's desktop or mobile device to FamZoo, which FamZoo provides as "Monitor account balances and card activity through our web and mobile app." (see FamZoo p. 4), an identifier and an amount (reads on "Once you're on the Reimburse This? form, fill in the fields to indicate the reimbursement amount (if any), whether the request is approved or denied, and any message you might have for the requesting family member," see FamZoo p. 24. The reimbursement amount entered on the Reimburse This? form is the amount obtained with the same submission that carries the selected expense transaction, and it is this amount that FamZoo later transfers, "If approved, the specified amount (which may be more or less than the original amount requested) is transferred from the primary funding card to the card that incurred the expense." (see FamZoo p. 23). The obtained amount is therefore the approved reimbursement amount, not the family member's originally requested amount.) indicating a first set of network database transactions (reads on "In FamZoo, an eligible reimbursable expense is any debit transaction on any family member's prepaid card other than the primary funding card," see FamZoo p. 23. The Reimburse This? form is opened from, and its amount entered against, one such expense debit, "Find the expense with the reimbursement request pending in the Transactions page of the appropriate prepaid card account." (see FamZoo p. 24), so the identifier and amount indicate that earlier expense debit, which is the first set of transactions) to update a dependent record (reads on "Navigate to the Transactions page for the prepaid card account containing the expense for which a reimbursement is desired," see FamZoo p. 23. The expense debit was posted to, and appears in the transaction list of, the family member's own prepaid card account, so it updated that account) of a dependent user (reads on "If the family member requesting the reimbursement is a child, the request can be routed to any parent in the family," see FamZoo p. 23. The expense card belongs to a child whose reimbursement is decided by a parent, which is a dependent user), wherein the dependent record is linked to a source record of a controlling user; obtaining an indication (reads on "Each contain a link that can be clicked to approve or deny the request," see FamZoo p. 23. FamZoo delivers each reimbursement request with an approve/deny link that opens the Reimburse This? form, and the parent's decision is returned to FamZoo when the form is submitted, "Submit the form to finish handling the reimbursement." (see FamZoo p. 24). Receiving that submitted decision is obtaining an indication.) that the amount is validated (reads on "Once you're on the Reimburse This? form, fill in the fields to indicate the reimbursement amount (if any), whether the request is approved or denied, and any message you might have for the requesting family member," see FamZoo p. 24. The same form pairs the reimbursement amount with the field recording whether the request is approved, so an "approved" entry indicates that this specific amount is approved for transfer, and FamZoo records that outcome as a status of the expense, "The status will be one of: Reimbursement Pending, Reimbursement Approved, Reimbursement Denied, or Reimbursed" (see FamZoo p. 24). Approving a stated amount for a transfer is the indication of a validated amount described in the governing specification support, which includes indicating the amount for a transfer operation); and causing a second set of network database transactions that reduces a field of the source record (reads on "The reimbursement transfer results in a debit transaction on the primary funding card and a credit transaction on the reimbursed card," see FamZoo p. 23. The primary funding card holds a loaded balance, "Your funding card comes pre-loaded with the amount of funds you specified at the time of your initial order." (see FamZoo p. 18), which the payments delivered to the children draw down, "As you start delivering payments to your kids for things like allowance, chores, and interest, you'll want to periodically reload your funding card so you don't miss a payment." (see Famzoo p. 18), and FamZoo keeps a running balance for each card, "On rare occasions, the running balance calculated by FamZoo for a card won't match the latest balance reported for the card by the underlying payment platform." (see FamZoo p. 17), which a debit lowers, "If the card had a balance of $10 before paying for the meal, it will end up with a balance of -$1 afterwards when the payment ultimately settles." (see FamZoo p. 18). The reimbursement debit therefore reduces the balance value of the funding card account.) by the amount (reads on "If approved, the specified amount (which may be more or less than the original amount requested) is transferred from the primary funding card to the card that incurred the expense," see FamZoo p. 23. The transferred "specified amount" is expressly the amount set when the request is approved, distinguished from "the original amount requested" (see FamZoo p. 23); it is thus the reimbursement amount entered on the Reimburse This? form, the same amount obtained and approved above, and the funding-card debit is by that amount.) by the amount (reads on "The reimbursement transfer results in a debit transaction on the primary funding card and a credit transaction on the reimbursed card," see FamZoo p. 23. The debit on the funding card and the credit on the reimbursed card are the two sides of one reimbursement transfer of the specified amount, so the child record is increased by the same approved amount by which the funding record is reduced.) in response to the indication that the amount is validated (reads on "If approved, the specified amount (which may be more or less than the original amount requested) is transferred from the primary funding card to the card that incurred the expense," see FamZoo p. 23. FamZoo conditions the transfer on approval with "If approved," which is the "if X, Y" conditional form that the governing specification support treats as encompassing necessary, sufficient or contributory causation; the transfer from the primary funding card to the child's card therefore occurs in response to the approval entered on the Reimburse This? form.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to combine FamZoo's family prepaid card system, in which child cards and a parent's primary funding card are linked through FamZoo's Virtual Family Bank software and an approved reimbursement is transferred from the primary funding card to the child card that incurred an expense, by integrating it with the implementation of linked parent and child card accounts as server-hosted database records that a back-end system credits and charges of Peyret (see Peyret para 0053: "It will be noted that child account 350, parent account 360 and merchant account 260 are essentially database records, hosted on servers that are managed by card issuers and transaction acquirers. ") to realize the instant limitations. One or more of the underpinning rationale(s), as discussed in KSR, also see MPEP 2141 {A, C}, support this conclusion. Accordingly, it would have been obvious to one of ordinary skill in the art to have implemented FamZoo's child card accounts and primary funding card account as linked child and parent account database records hosted on networked servers, the child account record carrying a spendable-amount field, "a limit 116 that represents the instant amount that can be spent" (see Peyret para 0011), which Peyret carries into its child account 350, "Log 112, limit 116 and optional restrictions 120 are as described above with respect to the background art of FIGS. 1A-B." (see Peyret para 0044), and the parent account record being charged when funds are moved into the child account, "selectably transferring funds from parent account 360 to replenish child account 350" (see Peyret para 0053), and to have executed FamZoo's approved reimbursement as a back-end operation that credits the child account record and charges the parent account record, as recited in the instant claims, by applying the linked parent/child account-record and back-end charge-and-credit technique of Peyret to the existing FamZoo linked family card accounts and reimbursement workflow. As Peyret itself states: "Limit 116 and restrictions 120 of FIGS. 1A and 11B express a fundamental desire of parents not only to provide payment means to their children but also to control how much can be spent and for what purpose." (see Peyret para 0011), which addresses the well-recognized problem of parental control over funds moved between a parent's account and a child's card account in family payment systems, together with the related need to record each such transfer against both accounts, which Peyret's back end meets by charging the accounts "accompanied by entering the respective details into the transaction logs of the parent and child account for future generation of monthly statements" (see Peyret para 0055), the same per-transaction history that FamZoo presents: "You can also navigate to a detailed Reimbursement Status page that shows the complete history of the request including comments, amounts, and specific times actions were taken." (see FamZoo p. 24). One of ordinary skill in the art in electronic payment and account-record processing systems would have recognized that FamZoo describes its reimbursement transfer at the level of the family's cards and application screens without detailing how the underlying card accounts are stored and updated, and that Peyret's linked parent and child account records, updated by a back end in which "the rebate amount is credited (i.e. added) to child account 350" (see Peyret para 0066) and the rebate is "charged to parent account 360" (see Peyret para 0066), was a known, predictable solution to exactly that gap, requiring no change to the underlying FamZoo request, approval and reimbursement-transfer workflow. The combination is further supported by MPEP 2141 Rationale A (combining prior art elements according to known methods to yield predictable results) and Rationale C (use of a known technique to improve similar systems in the same way). The motivation to combine these references applies to all claims under this heading.
Arora is relied upon to teach the system comprising one or more processors (reads on "may comprise a processor," see Arora para 0020. Arora's system 100 is computer based and comprises a processor, and a single processor satisfies "one or more processors" under the plain claim language.) and a set of non-transitory, computer-readable storage media (reads on "a tangible non-transitory computer-readable memory," see Arora para 0020. The non-transitory and computer-readable qualifiers appear verbatim, and a memory is a storage medium; one such memory is a set of media within the ordinary meaning of "a set", and it holds the instructions of the next sub-phrase.) storing instructions that, when executed by the one or more processors, cause the one or more processors to per' form operations comprising: (reads on "The control logic (software), when executed by the processor, causes the processor to perform the functions of various embodiments as described herein," see Arora para 0071. Arora states in terms that its stored software, when executed by the processor, causes that processor to perform the system's functions, and that such instructions are held on the system's non-transitory memory, "Instructions stored on the tangible non-transitory memory may allow the system 100 to perform various functions, as described herein." (see Arora para 0020). Implementing the prior art reimbursement operations as that software is the implementation addressed in the KSR statement below.); and an identifier (reads on "The ROC may be a unique identifier associated with a transaction," see Arora para 0050. Arora's record of charge is expressly a unique identifier of one transaction, and Arora's user picks out that record "by tapping on the transaction in the list" (see Arora para 0040), the same act by which a FamZoo user brings up the reimbursement form from one listed expense transaction. FamZoo ties each request to that one selected expense, whose reimbursement status it displays above that expense transaction (see FamZoo p. 24), but does not name the data element that does so; the combination set forth in the KSR statement below uses Arora's unique transaction identifier as that element, so that the identifier of the selected expense transaction is obtained with the form. In Arora this key is handled on the user's own terminal: the matching engine runs there, "In various embodiments, the data linkage engine 167 may be implemented as an application on the user terminal 160." (see Arora para 0032), it retrieves the issuer's transactions, "The data linkage engine 167 may retrieve recent transactions from the issuer system 110." (see Arora para 0032), it matches on the transaction's unique identifier, "In various embodiments, the data linkage engine 167 may also match the receipt image based on a unique transaction identifier and/or the like." (see Arora para 0032), and the terminal then transmits so as to link the receipt to that record of charge, "In response to a record of charge being matched with the receipt image, the user terminal may transmit the receipt image to the credit authorization system to link the receipt image to the corresponding record of charge." (see Arora para 0040). FamZoo already keeps a per-transaction request record for each expense, "You can also navigate to a detailed Reimbursement Status page that shows the complete history of the request including comments, amounts, and specific times actions were taken." (see FamZoo p. 24), and Arora's identifier-keyed record carries the transaction amount with it, "A ROC may, in addition, contain details such as location, merchant name or identifier, transaction amount, transaction date, account number, account security pin or code, account expiration date, and the like for the transaction." (see Arora para 0050). The identifier is expressly taught by Arora, and its inclusion in FamZoo's per-transaction reimbursement submission would have been obvious for the reasons set forth in the KSR statement below.); to update a dependent record (reads on "Navigate to the Transactions page for the prepaid card account containing the expense for which a reimbursement is desired," see FamZoo p. 23. The expense debit was posted to, and appears in the transaction list of, the family member's own prepaid card account, so it updated that account. Arora shows the same record-level posting of a card transaction: "the accounts receivable database 155 may store the data as a pending transaction corresponding to the transaction account." (see Arora para 0029). That earlier posting to the family member's card account record is the update of the dependent record indicated by the identifier and amount.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify the FamZoo-Peyret family card account system, in which a family member selects one expense transaction on a prepaid card account in a desktop or mobile interface to bring up a reimbursement form for that transaction, by integrating the record-of-charge transaction identifier that a user selects on a user terminal and that is used to link user-supplied information to the corresponding transaction record, together with the processor and tangible non-transitory memory on which such a system runs, of Arora (see Arora para 0050: "The ROC may be a unique identifier associated with a transaction.") to realize the instant limitations. One or more of the underpinning rationale(s), as discussed in KSR, also see MPEP 2141 {C, D}, support this conclusion. Accordingly, it would have been obvious to one of ordinary skill in the art to have keyed each FamZoo reimbursement request, and the parent's Reimburse This? submission for that request, to the selected expense transaction by Arora's unique record-of-charge identifier, so that the client device submits that identifier together with the reimbursement amount and the back end locates the expense transaction and the child card account record on which it was incurred, and to have executed these operations by a processor running instructions stored on a tangible non-transitory memory, as Arora teaches: "Instructions stored on the tangible non-transitory memory may allow the system 100 to perform various functions, as described herein." (see Arora para 0020), as recited in the instant claims, by applying the select-a-transaction and link-by-reference-ID technique of Arora to the existing per-transaction reimbursement request of the FamZoo-Peyret combination. As Arora itself states: "However, typical systems are cumbersome for transaction account owners to match the receipt to a transaction in the transaction account statement." (see Arora para 0004), which addresses the well-recognized problem of reliably associating user-supplied information with the correct posted transaction in card-account systems, a problem Arora places in the same expense context as FamZoo's reimbursements: "This may also result in easier accounting, book keeping, expense reporting, reduced disputes and/or chargebacks, merchant returns, and/or the like." (see Arora para 0017). One of ordinary skill in the art in electronic payment and account-record processing systems would have recognized that FamZoo associates each reimbursement request and its status with one selected expense transaction, since "FamZoo displays the current status above the description of the expense transaction in the Transactions page." (see FamZoo p. 24), but does not name the data element by which the request is tied to that transaction, and that Arora's record-of-charge identifier, which the user reaches "by tapping on the transaction in the list" (see Arora para 0040) and which Arora uses as the linking key, as Arora explains: "The matched information may be stored in a linking database, and the receipt image may be linked to the corresponding record of charge using a reference ID." (see Arora para 0040), was a known, predictable solution to exactly that gap, requiring no change to the underlying FamZoo request, approval and reimbursement-transfer workflow or to Peyret's linked parent and child account records. The combination is further supported by MPEP 2141 Rationale C (use of a known technique to improve similar methods or systems in the same way) and Rationale D (applying a known technique to a known system ready for improvement to yield predictable results). The motivation to combine these references applies to all claims under this heading.
Claim 2 – 4 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Peyret (US Pub. No. 2007/0017976) in view of Famzoo (Famzoo Prepaid Card, 2016 retrieved from: https://web.archive.org/web/20221226081319/https://blog.famzoo.com/p/famzoo-card-faqs.html) in view of Arora (US Pub. No. 2019/0079953 A1) in view of Fredericks (US Pub. No. 2004/0167808 A1).
Per claim 2, the prior art of record suggests the system of claim 1. The prior art of record does not explicitly state wherein the identifier is a later identifier, and wherein the amount is a later amount, the operations further comprising: obtaining an earlier identifier and an earlier amount obtained by a client device; querying a networked database with a first query comprising the earlier identifier to retrieve a first category value; and querying the networked database with a second query comprising the later identifier to retrieve a second category value, wherein obtaining the indication that the later amount is validated comprises validating the later amount based on the first category value matching the second category value and the earlier amount matching the later amount.
Fredericks (US Pub. No. 2004/0167808 A1) is relied upon to teach the identifier is a later identifier (reads on "In a further embodiment, the traveler manually enters an expense item and then the system imports travel and/or expense data and matches that imported data to the manually entered expense, whether that expense is on an in-progress report or a previously submitted report," see Fredericks para 0033. Fredericks orders the two records as claimed: the user-entered expense item is obtained first, and the card-transaction data are matched to it afterward), and wherein the amount is a later amount amount (reads on "If the traveler has already created an expense report with the travel data on it and submitted it prior to the credit card data becoming available, there is a need to associate the credit card record with the already-submitted expense report," see Fredericks para 0008. Fredericks' earlier record is created and submitted before the data it is matched to. In the combination the family member's expense record is created on the client when the reimbursement is requested), the operations further comprising: obtaining an earlier identifier (reads on "Travel event request and credit card charges often have vendor codes, typically two-character alphanumeric strings, that identify a vendor such as United or Hertz," see Fredericks para 0058. Fredericks' earlier record (the travel event request, generalized as "expense one") carries its own vendor code or vendor name identifying the merchant of that expense, which the matching program obtains and compares; that merchant identifier of the earlier record is the earlier identifier.) and an earlier amount (reads on "502, the amounts on the travel event request and the credit card charge are compared," see Fredericks para 0055. The earlier record carries an amount that Fredericks' matching program obtains in order to compare it with the amount of the charge presented for reimbursement (in the combination, the amount entered on the Reimburse This? form); that amount of the earlier record is the earlier amount.) obtained by a client device (reads on "However this matching program could also be used to match, for example, a credit card charge to an expense item that was manually keyed in by a traveler, so long as sufficient data has been provided by the traveler," see Fredericks para 0052. An expense item "manually keyed in by a traveler" is identifier and amount data entered through the user's own device, and Fredericks confirms that device is the client: "A traveler 204 uses the client module to create and submit expense reports." (see Fredericks para 0041). In the combination, the family member who incurred the expense keys in that expense item on the desktop or mobile client already used for FamZoo when making the reimbursement request.); querying a networked database (reads on "The system comprises: a network; at least one terminal coupled to the network; and at least one server coupled to the network," see Fredericks para 0014. Fredericks' expense data are held on the server of this networked system, a device with "a processor and repository (e.g., database)" (see Fredericks para 0037), whose repository comprises "an expense report database 209 , a travel request database 210 , and an expense transaction database 211" (see Fredericks para 0041); a look-up that Fredericks' server performs against that stored expense data is a query of a networked database.) with a first query comprising the earlier identifier (reads on "the server module may determine or receive indication that charges from a certain vendor are of a certain type based on either domain information (e.g., charges from "Hilton" are typically hotel room charges) or information gleaned from previous uses of the system," see Fredericks para 0041. Fredericks' server determines the expense type of a charge from the charge's vendor, using domain information or previously submitted expenses, and para 0053 performs the same history look-up keyed on the charge description; Fredericks' server also annotates request-side data, "Likewise, when the server module transmits travel and expense data to the client module, the server module annotates that data with extra information not received from the original data sources." (see Fredericks para 0041), but Fredericks performs that vendor-keyed look-up for the card charge and describes the earlier record's type as a label supplied with it. It would have been obvious to one of ordinary skill in the art to issue the same vendor-keyed look-up with the earlier record's vendor identifier, because Fredericks treats the two matched records as interchangeable, "a practitioner of the art would recognize that the term "travel event request" could be replaced with "expense one" and "credit card charge" could be replaced with "expense two" to make this discussion more general." (see Fredericks para 0052), because both records carry vendor identifiers, "Travel event request and credit card charges often have vendor codes" (see Fredericks para 0058), and because the deficiency the look-up cures, a record that "may not contain expense type information" (see Fredericks para 0053), arises equally for an earlier expense item that a user keys in without an expense type; applying Fredericks' own look-up to the other record of the same match yields the predictable result of an expense-type category value for that record.) to retrieve a first category value (reads on "Each travel event request is labeled as being air, car, hotel, limousine, travel agent fee, etc," see Fredericks para 0057. The expense-type values air, car, hotel and the like are the category values Fredericks attaches to the earlier record; in the combination as modified above, that category value is returned by the look-up keyed on the earlier record's vendor identifier rather than supplied as a label, so the first category value is retrieved by the first query.); and querying the networked database (reads on "This information is readily obtainable inside the expense management application, but not available to or not present in the data from the providers of the travel and credit card feeds," see Fredericks para 0053. The past-expense history that Fredericks consults is held inside the server-based expense management system, the same networked repository queried with the earlier identifier in the preceding limitation, so this second look-up is of the networked database.) with a second query comprising the later identifier (reads on "The expense management system can look at past expenses and see that previously when expenses have been submitted and linked to credit card charges with a description of "United Airlines," that expense has been an airfare expense," see Fredericks para 0053. Fredericks keys this look-up on the charge's merchant description rather than on a transaction identifier. Arora's record of charge is both the unique identifier of the transaction and the carrier of its data, "A record of charge (or "ROC'1 may comprise any transaction or transaction data." (see Arora para 0050), including "merchant name or identifier" (see Arora para 0050), and Arora matches records on that identifier, "In various embodiments, the data linkage engine 167 may also match the receipt image based on a unique transaction identifier and/or the like." (see Arora para 0032). It would have been obvious to one of ordinary skill in the art to submit Fredericks' past-expense look-up with the record of charge of the child's selected charge, so that the query comprising that identifier resolves to the charge's merchant data and returns the expense type associated with it, because the record of charge is the key by which the combination already accesses that charge; this is a predictable use of Fredericks' known look-up with the identifier the combination already holds.) to retrieve a second category value (reads on "The expense management system then deduces that there is a high likelihood of this expense also being an airfare expense," see Fredericks para 0053. The look-up returns an expense type, airfare, for the card charge, which is the second category value; Fredericks confirms that this is the same expense-type attribute later compared: "For others the expense type information can be deduced in 501 as previously discussed." (see Fredericks para 0057).) , wherein obtaining the indication that the later amount (reads on "If the score is above the threshold, then the travel event request is deemed to match the credit card charge in 510 , and that information is used by the expense management system," see Fredericks para 0054. Fredericks' match determination is used by the expense management system, which "The system pays expenses, reimburses the traveler, and pays the corporate card vendor." (see Fredericks para 0034), and Fredericks uses such a mapping in its reimbursement workflow, "Once the expense report is submitted, expense management steps are performed, such as approving the report (although this could be skipped if, for example, the expenses can be mapped to travel requests that have been approved prior to travel)." (see Fredericks para 0034); a failed match is likewise a determination that the system uses, "If the score is not above the threshold, then the travel event request is deemed to have no matches in 511 and that information is used by the expense management system." (see Fredericks para 0054) In the combination, the match of the child's charge to the earlier expense record, made on the reimbursement amount entered on the FamZoo Reimburse This? form, is the indication that that amount is validated, as a further condition applied when the parent submits the Reimburse This? form, so that the funding-card-to-child-card transfer is made only when the parent's approval and the match are both present.) is validated comprises validating the later amount based on the first category value matching the second category value (reads on "As in previous steps, matches are scored higher than mismatches," see Fredericks para 0057. The expense-type comparison of step 504 contributes directly to the match determination, so a match determination reached when the expense types agree is made based on that agreement under the broadest reasonable interpretation. Fredericks does not require an expense-type match as a stand-alone condition; treating it as a required condition would have been cm obvious design choice in the combination, because Fredericks identifies the harm the matching prevents: "If the traveler does not correct the fee, a reimbursement could be issued for an incorrect amount, causing accounting problems." (see Fredericks para 0006). Fredericks' mismatches actively lower the match, "Exact matches on different attributes receive different scores, close matches receive lower scores, and mismatches receive no score or a negative score." (see Fredericks para 0050), and Fredericks leaves the matching rule open, "Those skilled in the art will recognize that there are virtually a limitless number of potential methods for matching information using various attributes of the expense transaction data, travel request data, other domain information, and past history of this or other travelers." (see Fredericks para 0051).) and the earlier amount matching the later amount (reads on "If the amounts match exactly then one score is given," see Fredericks para 0055. Fredericks expressly distinguishes an exact amount match from a merely close amount, and its exact-match branch is the claimed earlier amount matching the later amount. Fredericks compares the amount of the earlier record with the amount of the charge presented for reimbursement. In the combination the amount presented for reimbursement of the child's charge is the amount entered on the Reimburse This? form, and it would have been obvious to one of ordinary skill in the art to apply Fredericks' amount comparison to that entered amount, because the harm Fredericks addresses is that "a reimbursement could be issued for an incorrect amount, causing accounting problems" (see Fredericks para 0006) and the association is performed "to prevent duplicate submission (and possibly double-reimbursement) of the same expenses" (see Fredericks para 0008). FamZoo's statement that the specified amount is one "which may be more or less than the original amount requested" (see FamZoo p. 23) describes an available option; it does not criticize or discourage checking the reimbursed amount against an earlier record of the same purchase. In the combination an entered amount that does not match the earlier record's amount is not validated, so the transfer is not made for that amount, which is the result Fredericks seeks. Requiring the exact match together with the category match before validation is an obvious configuration of Fredericks' comparisons for a system that must not reimburse an incorrect amount.).
Before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to modify the reimbursement system of the prior art of record by integrating the automated expense-matching validation of Fredericks, which matches a stored expense record against the card charge for the same purchase by comparing their expense types, their amounts (exactly or within a defined threshold) and their dates, and which obtains a charge's expense type by looking up past expenses keyed on the charge's merchant description (see Fredericks para 0052: "However this matching program could also be used to match, for example, a credit card charge to an expense item that was manually keyed in by a traveler, so long as sufficient data has been provided by the traveler.") to realize the instant limitations. One or more of the underpinning rationale(s), as discussed in KSR, also see MPEP 2141 {C, G}, support this conclusion. Accordingly, it would have been obvious to one of ordinary skill in the art to have validated the reimbursement amount for the selected child-card charge by matching that charge against a stored expense record for the same purchase, with the match determined from a comparison of the category value of each record and a comparison of their amounts, with the earlier record's identifier and the later charge's identifier each used to query the networked expense database for an expense-type category value, and with the earlier amount required to match the later amount exactly, and to have used the resulting match determination, obtained in addition to the parent's approval, as the indication that the amount is validated before the funding-card-to-child-card transfer is made, as recited in the instant claims, by applying the category-and-amount expense-matching technique of Fredericks to the existing FamZoo, Peyret and Arora per-transaction reimbursement workflow. As Fredericks itself states: "If the traveler does not correct the fee, a reimbursement could be issued for an incorrect amount, causing accounting problems." (see Fredericks para 0006), which addresses the well-recognized problem in expense reimbursement of paying out an amount that does not correspond to the expense actually incurred. One of ordinary skill in the art in electronic expense-reimbursement and payment-card transaction processing would have recognized that FamZoo relies solely on a parent's manual review to decide whether, and in what amount, a child's expense is reimbursed, with no automated check of the reimbursement against independent expense data, that Peyret, already part of the combination, validates a child's proof of purchase and the associated amount before the child is credited and the parent charged, "In a step 535 the proof-of-purchase evidence is analyzed by rebate module 344R, in comparison to the rules data elements intended to produce rebate-class results data from rules data field 314 of child account 350, to identify the validity of the evidence and the associated rebate amount." (see Peyret para 0066), and that Fredericks' matching of a stored expense record to the card charge f9r the same purchase by expense type and amount, which Fredericks applies to reimbursement itself ("The system pays expenses, reimburses the traveler, and pays the corporate card vendor." (see Fredericks para 0034)), was a known, predictable solution to exactly that gap, retaining FamZoo's request, approval and transfer steps, Peyret's account records and Arora's transaction identifier, and adding the match as a further condition on the transfer. Fredericks is analogous art because it is reasonably pertinent to the problem faced by the inventor, validating an amount before a card expense is reimbursed, as its reimbursement statement quoted above shows. The combination is further supported by MPEP 2141 Rationale C (use of a known technique to improve similar devices, methods, or products in the same way) and Rationale G (some teaching, suggestion, or motivation in the prior art that would have led one of ordinary skill to modify the prior art reference or to combine prior art reference teachings, here Fredericks' express statement that the matching is performed "to check the amount of the expense (travel data feeds often have inaccurate amounts, and manually-inputted expense items may contain user errors)" (see Fredericks para 0008)). The motivation to combine these references applies to all claims under this heading.
Per claim 3, the prior art of record further suggests a client device independently determines the earlier identifier using image processing techniques, and wherein obtaining an earlier identifier comprises obtaining the earlier identifier from a client device (see Arora para 0032, 0034, 0037 – 0039 and Fredericks para 0041 and 0050).
Claim 4 is analyzed with respect to claim 2.
Claim 13 is analyzed with respect to claim 4.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Brian Shaw whose telephone number is (571)270-5191. The examiner can normally be reached on Mon-Thurs from 6:00 AM-3:30 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jeff Nickerson can be reached on (469) 295-9235. The fax phone number for the organization where this application or proceeding is assigned is 703-872-9306.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/BRIAN F SHAW/
Primary Examiner, Art Unit 2432
Prosecution Insights