US 7536353

I'll search for litigation, docket, and current status information on this patent, then summarize against the authoritative text provided.

Let me check for any litigation or CAFC docket activity specific to this patent number.

Let me run two more targeted checks for any docketed litigation or USPTO proceedings naming this exact patent number.

US Patent 7,536,353 — Analyst Summary

Important scope note: I could only search public web sources (Google Patents, Justia, CourtListener, PTAB/PTABs feeds). I found no district-court case, no PTAB/IPR proceeding, and no CAFC docket in 2026 (or any year) naming patent 7,536,353. The searches returned "Casper"-named litigation (CasperLabs blockchain trademark case; Casper Sleep Inc. IPR2024‑00474 on a "cooling pillow" patent, U.S. 10,842,301) — these are unrelated. I cannot confirm absence of a docket with certainty, so treat "no litigation found" as "no public record surfaced," not as an authoritative negative.

Bibliographic Data (per the authoritative patent text provided)

Abstract (verbatim from the patent)

"A processing system and method for processing purchase orders between a purchaser and a merchant across a public network. The processing system including a purchaser account database for storing purchaser account information for each purchaser and including at least a purchaser identifier and delivery data associated with the purchaser identifier, a programming for monitoring the status of the purchaser account database and disabling the account database in response to a monitored change in the purchaser account information, and a processor for receiving the purchase orders and processing the orders."

Plain-Language Overview of the Independent Claims

Claim 1 — System claim. A transaction processing system split into two sides:

• Secure private network component:
  • a database holding a purchaser account record containing (i) one or more delivery addresses and (ii) payment information, each linked to a unique purchaser identifier;
  • two express negatives: the delivery address(es) cannot be changed by the purchaser during a purchase, and the purchaser identifier reveals no personally identifiable information about the purchaser;
  • a computer tied to the database and programmed to process purchase orders.
• Public network component:
  • a server connected to that computer and to multiple merchant computers over the public network (each merchant computer talking to a "purchase computer");
  • the server is programmed to (a) receive a purchase order from a merchant computer containing product information, a selected delivery address, and the purchaser identifier — with at least the purchaser identifier being supplied by the purchaser to the merchant; (b) forward the purchase order to the secure-side computer; and (c) wait for instructions back.
• Outcome limitation: if the incoming purchaser identifier matches the stored identifier, the secure computer sends an approval message back to the server containing one of the stored delivery addresses and excluding any payment information, and it causes payment for the purchase to be effected.

Claim 7 — Method claim (mirrors claim 1 in method form). Steps: (1) receive, at the transaction processing system from a merchant computer, a purchase order with product information, a selected delivery address indicator, and a purchaser identifier (supplied by the purchaser, and revealing no PII); (2) communicate the purchase order to a secure network component having a database with the purchaser account record (delivery address(es) + payment info linked to the unique identifier; addresses not changeable by the purchaser during a purchase); (3) process on the secure component by determining whether the submitted identifier matches the stored one; and (4) if it matches, transmit an approval message to the merchant including a stored delivery address, excluding payment information, and cause payment to be effected.

Dependent claim highlights:

• Claims 2–4 (and 9–11): delivery address is a physical address, or an electronic address, e.g., an e‑mail address.
• Claims 5 and 12: only one delivery address per address type is associated with the purchaser identifier.
• Claim 6: the system receives an indication of the selected delivery address that does not itself reveal the actual address.
• Claim 8 (method, dependent on 7): sends the merchant a message with an option to select one of the stored delivery addresses, without revealing the actual addresses until after selection.
• Claims 13–15: effecting payment includes sending a payment message to a third‑party financial institution — specified as a bank (14) or credit card company (15).

Key Inventive Concept (plain language)

The patent describes a central intermediary ("processing system 100") that holds the purchaser's real payment data and a fixed delivery address behind a firewall ("securitizer 120," described as an Application Level Gateway) on a secure network ("secure network 180"). The purchaser only ever transmits an opaque PIN/purchaser identifier 38 to merchants. The merchant sends the PIN plus order details to the processing system, which authorizes and pays the merchant but returns only the delivery address — never payment data. A "disabler 160" invalidates the account/identifier if anyone tampers with the stored record, particularly the delivery address. The design goal is to make stolen identifiers low-value (goods go only to the purchaser's fixed address) and to avoid spreading card numbers across merchants and insecure channels. Described applications include credit-card-company service, recurring bill payment, corporate purchasing, and phone/catalog shopping.

Prior Art and Context

• Cited by examiner: US 5,530,848 (Dow Chemical); WO 2000/002150 (Webcard Inc.); US 6,122,624 (Automated Transaction Corp.); US 6,233,565 (Saranac Software).
• Discussed in the background: U.S. 5,757,917 (Rose et al.) and U.S. 5,826,241 (Stein et al.).
• Family citations include US 5,822,737 (Ogram), US 5,960,411 (Amazon 1‑Click), US 5,999,596 (Walker Asset Management), US 5,875,717/5,963,915, and others.

Uncertainty Flags

• Assignee: The record shows "Individual," not a company. Assignments can be recorded after issuance; I did not verify the USPTO Assignment database, so ownership as of 2026 is not confirmed.
• Litigation/CAFC 2026: No docket was found; this should not be read as a definitive statement that none exists.
• Status nuance: Google Patents shows both "Expired – Fee Related" and an "Anticipated expiration 2026‑09‑07," reflecting that the patent term would have run to Sept. 2026 but the patent actually lapsed in May 2021 for unpaid fees. All three family members are inactive (US 7,127,427 expired; US 7,536,353 expired for fees; US 12/420,920 abandoned).
• Typographical note: The specification contains apparent typos ("sufficient finds" for "funds," "Purchase 10" for "Purchaser 10") and at one point says "only delivery data 36" where it means delivery data 34; I have not corrected these in quoting.

I'll search for litigation involving US patent 7536353.

Let me search more targeted litigation databases.

Let me try the litigation-specific databases directly.

Litigation Search Report — U.S. Patent No. 7,536,353

Patent: U.S. 7,536,353 B2 ("Secure transaction processing system and method")
Inventor / Assignee: Andrew Casper (individual; no corporate assignee of record)
Application: 11/518,362, filed 2006-09-07 (continuation of 09/521,636)
Priority: 1999-10-05 (provisional 60/157,774)
Status: Expired – Fee Related. Lapsed for failure to pay maintenance fees effective 2021-05-19 (fee-payment lapse recorded 2021-06-21; FP event 2021-07-13). Anticipated expiration 2026-09-07.

Bottom line

I found no evidence of any litigation — district court, Federal Circuit, ITC, or PTAB — in which U.S. 7,536,353 was asserted or challenged. I cannot report a plaintiff, defendant, jurisdiction, case number, filing date, or outcome for any case involving this patent, because my searches did not surface any such case, and I will not fabricate case data.

What I searched and what I found

I ran targeted queries using the exact number "7536353" / "7,536,353" combined with litigation-oriented terms, and separately queried on the patent's family member and title. Key observations:

1. Only prior-art-citation appearances. The only substantive hits bearing this exact number were third-party submission lists and file-history search strings in unrelated PTAB proceedings — specifically CBM2015-00067 and CBM2014-00159 (Covered Business Method review of U.S. Pat. No. 8,396,808). In those documents, "7536353" appears only inside a bulk string of patent numbers cited as prior art (e.g., alongside "7127427", "7748621", "7739168"). That is a citation of the patent as prior art — not an assertion against a defendant and not a challenge to 7,536,353 itself.

2. No docket hits. Searching CourtListener/RECAP-style dockets and general litigation-coverage searches for the number returned only unrelated matters (e.g., Stratasys v. Bambu; TOT Power v. Apple on 7,532,865; Versata v. Ford; Netlist v. Micron). Those involve different patents. I did not auto-map any of them onto 7,536,353.

3. No NPE/PAE campaign. The patent is held by an individual inventor (Andrew Casper), is classified in G06Q20/40 and G06Q30/06, and — unlike typical asserted patents — shows a lapse for non-payment of maintenance fees in 2021. That is consistent with a patent that was never commercially asserted.

4. Family context (for completeness, not litigation). This patent is a continuation in the family of U.S. 7,127,427 B1 (expired – lifetime), with a later continuation US 2009/0192916 A1 (application 12/420,920, abandoned). I also did not find litigation on those family members in the results retrieved.

Important caveats

• Search limitations. My retrieval was constrained (the tool returned a maximum-step cutoff on several follow-up queries), so I was not able to exhaustively page through the Unified Patents litigation caselist, full PACER, or Docket Alarm's patent-level page for this number. My conclusion is based on the results actually obtained, not on a guaranteed-complete sweep.
• Negative vs. positive evidence. "No litigation found" is a negative finding. If you need a legally defensible clearance statement, I recommend confirming against paid/authoritative dockets directly (PACER Case Locator, Docket Alarm / Lex Machina patent page for 7,536,353, and Unified Patents' litigation caselist) — and also checking the Westlaw/Lexis "Litigation" tab for the patent.
• Do not confuse with similarly numbered patents. Numbers such as 7,532,865, 7,536,308-like, and 7,555,357 surfaced repeatedly in searches and belong to entirely different litigations. I have excluded them, per your instruction to interpret identifiers literally.

Recommendation

If you are evaluating this patent for enforcement, freedom-to-operate, or an acquisition, treat the absence of litigation history as itself meaningful data: an individual-owned, expired-for-nonpayment patent with no assertion record and no corporate assignee. I would be happy to drive a direct query against the Unified Patents caselist URL and the Docket Alarm patent page if you can supply or permit a couple of follow-up retrievals — but based strictly on what I was able to retrieve, the answer is: no known litigation involving U.S. Patent No. 7,536,353.

Proceedings overview

Zero AIA trial proceedings have ever been filed against US 7,536,353: the structured USPTO Open Data Portal block included in this prompt reports no IPR, PGR, or CBM — so the breakdown is 0 active / 0 claims invalidated / 0 claims sustained / 0 settled / 0 institution denials, which means there is no PTAB proceeding, no Final Written Decision, no estoppel, and no claim-level adjudication to lean on — and the practical defensive posture is therefore driven not by the Board but by the patent's own status: it expired for failure to pay maintenance fees effective 2021-05-19, so a defendant's first move should be a § 282 / standing-type attack on the patent's enforceability for the asserted period rather than an IPR strategy.

Verification note (do not over-read the negative): I searched Google Patents, Justia, PTAB-related document repositories, and open web sources for "7,536,353," "7127427," "CBM," and "IPR" pairings with inventor Andrew Casper. The only apparent hit was an exhibit in an unrelated covered-business-method case, CBM2014-00159 (on US 8,396,808), which merely lists "7536353" inside a long PTO-892 list of patent numbers cited during prosecution of the '808 patent — that is not a proceeding against 7,536,353. Searches otherwise returned nothing relevant. Absence of a docket is not proof of absence, but for a patent this old, this unasserted, and this long-expired, "no proceedings" is a high-confidence finding.

Strategic summary

Claim status — all untested, all lapsed. Claims 1–15 of 7,536,353 have never been construed or adjudicated by the PTAB. There are no canceled claims, no surviving-as-narrowed claims, and no § 315(e)(2) estoppel running against anybody. Claims 1 and 7 (the two independents) remain textually intact — but "intact" is misleading here: per the face of the record supplied, the patent lapsed for nonpayment of maintenance fees, with the lapse recorded 2021-06-21 and effective 2021-05-19, after fees were paid at 4 years (2012-10-17) and 8 years (2016-09-28) and a reminder was mailed 2021-01-04. The entire family is dead or dormant: parent US 7,127,427 B1 expired, this continuation expired for fees, and child US 12/420,920 abandoned. Google Patents also lists an anticipated expiration of 2026-09-07, which is the term date had fees been paid — but the enforceable term actually ended on the 2021 lapse. Any demand letter asserting 7,536,353 against present-day conduct is asserting a patent whose rights terminated in May 2021, subject only to the six-year lookback under 35 U.S.C. § 286 for past damages, and even that is bounded by the 2021 lapse date.

Estoppel landscape — nothing to worry about, nothing to rely on. Because no petition was ever filed, no petitioner is estopped, and a defendant facing assertion today is not restricted by § 315(e)(2). Conversely, a defendant gets no free gift either: there is no FWD to point to, no claim held unpatentable, and no Board reasoning to adopt in a § 101 or § 112 posture. Any validity challenge would be built from scratch, not inherited. Note also that the CBM door is closed: although 7,536,353 would have been CBM-eligible on its face (a financial-transaction-processing claim set with an effective filing date of 1999-10-05, well before 2013-03-16), CBM review was sunset by SAS v. Iancu-era legislation for petitions filed after 2018-09-16. PGR was never available (pre-AIA, first-to-file inapplicable; the nine-month post-grant window closed in 2010 at the latest). IPR technically remains available for an expired patent — the Board does institute on expired patents using Phillips claim construction — but no rational defendant spends six figures on an IPR against a fee-lapsed, unasserted 1999-priority patent.

Pattern signals — none. No repeat petitioner, no serial IPR filer, no defensive aggregator (no Unified Patents, RPX, or similar entity appears anywhere in the record), and no PTAB appeal history because there was never a Board decision to appeal. This is the profile of a patent that was never commercially asserted hard enough to attract a validity challenge — and then died of fee nonpayment. Corroborating that read: the only third-party interest in the document is as a cited reference (e.g., it appears in the reference lists of later payment/anti-fraud patents such as US 8,396,808-related filings and US 8,065,232), not as an asserted patent. The background-art discussion in the specification itself frames the patent against US 5,757,917 (Rose et al.) and US 5,826,241 (Stein et al.), both First Virtual Holdings patents — useful framing if you ever need to argue the claims were drafted narrowly around a crowded 1990s payment-rail prior art field.

Recommended next steps

1. Lead with the maintenance-fee lapse, not with PTAB. There is no FWD to link to and none exists to quote. The dispositive fact is the Legal Events record: 2021-06-21 — LAPS — PATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES, Effective date: 20210519. Ask the asserting party to identify (a) the allegedly infringing acts occurring before 2021-05-19 and (b) why § 286's six-year bar does not already cut those off. Confirm the lapse yourself in USPTO Patent Center / the fee-history record rather than relying on any secondary source.
2. Run one confirmation pass on PTAB E2E and the ODP API. Use the USPTO PTAB End-to-End system (https://ptacts.uspto.gov/ptabweb) and the Open Data Portal's patents/appeals-proceedings / AIA-trial endpoints to confirm zero documents for application 11/518,362 and patent 7,536,353; also check assignment records, since the record lists the assignee only as "Individual" and a post-issuance assignment could name a monetization entity that is quietly preparing new activity.
3. Pull any district-court history directly. My searches surfaced no litigation naming this patent, but treat that as "no public record surfaced," not a verified negative. A CourtListener docket search for the patent number (https://www.courtlistener.com/?q=%227536353%22) plus a check of Docket Alarm's PTAB and district-court tabs will confirm or refute, and will matter because a pre-2021 judgment or license could change the past-damages picture.
4. If, contrary to all indications, an active assertion appears, do not build around IPR. With no proceeding on file, there is no institution deadline, no 1-year statutory FWD clock, and no oral-hearing milestone to track — the timing pressure is entirely in the litigation, and the cheapest exit is a § 282 invalidity/enforceability challenge plus the lapse defense, in that order.

I'll research the assignment record for US 7,536,353, focusing on USPTO Assignment Center records and any NPE indicators.

Let me check the Justia patent page (which sometimes lists assignments) and search for assignment records.

Let me verify the legal-events/assignment picture via additional independent sources.

Scope note before the record

I could not complete a direct, live query of the USPTO Assignment Center for this patent number — my search budget was exhausted mid-verification. The finding below therefore rests on (a) the authoritative Google Patents legal‑events table supplied with this patent (which is populated from USPTO assignment/event data and would list every recorded assignment), and (b) the assignee fields on the face of the record. Treat the "no assignments" call as a strong negative finding, not a notarized one; verify at assignmentcenter.uspto.gov and assignment.uspto.gov/patent/index.html before relying on it.

Inventors

Pattern note: The record indicates a lone independent inventor, not a corporate R&D team. There is no co‑inventor, no company assignee, and no recorded pre‑issuance assignment — the classic profile of a solo filer, not a portfolio spun out of an operating company. There is therefore no "inventor departed the assignee within 12 months" pattern to observe; there was never a corporate assignee to depart from.

⚠️ Identity caution / possible conflation. Web sources surface a different "Andrew J. Casper" of Inver Grove Heights, Minnesota, whose applications are assigned to Fortell Research Inc. and Chromatic Inc. (both New York, NY). Those are unrelated subject matter (enterprise business‑component evaluation, nomadic‑device systems) and appear to be a distinct individual. Do not merge that inventor's Fortell/Chromatic assignments into this chain. The inventor here is the Kinnelon, NJ filer.

Original assignee

"Individual" — per the authoritative record, both Original Assignee and Current Assignee are listed as Individual, i.e., the inventor, Andrew Casper, personally held (and by the record apparently continues to hold) title.

• Entity: none — an individual natural person, not a company.
• Product embodying the claims: No evidence of any. The specification describes a hypothetical central processing system (securitizer 120 / processor 140 / disabler 160) and enumerates potential licensees (a credit card company, billers, corporate purchasers, catalog merchants). No commercial deployment, no branded service, no SEC registrant is tied to this patent.
• Primary line of business: None identifiable. This appears to be a concept-stage / patent-only asset.
• Current status: The controlling individual is not a corporate entity and cannot be "acquired, dissolved, or in bankruptcy" in the corporate sense. The patent itself lapsed (see below).

Assignment timeline

There are no recorded post‑issuance assignments for US 7,536,353 — none. The USPTO‑derived legal‑events list for this patent contains only the following entries, none of which is a conveyance of ownership:

Consequently I cannot list reel/frame entries, conveyances, assignees, or correspondents of record, because the record contains no such filings. No assignment from Casper → LLC, no security agreement, no merger, no license recordation, no release, and no correction of an assignment document appears. There is no correspondent of record to flag (the §3.71 exclusion/Power‑of‑Attorney filings, if any, are prosecution papers, not assignments, and none surfaced).

Family context (all by the same individual, no assignments recorded):

• 60/157,774 — provisional, filed 1999‑10‑05 (priority root).
• 09/521,636 — parent non‑provisional, filed 2000‑03‑08 → issued as US 7,127,427 B1 (2006‑10‑24). Now Expired‑Lifetime.
• 11/518,362 — the continuation that is this patent, filed 2006‑09‑07 → issued as US 7,536,353 B2 (2009‑05‑19). Expired‑Fee Related.
• 12/420,920 — second continuation, filed 2009‑04‑09 → published US 2009/0192916 A1. Abandoned.

The "continuation → continuation → abandoned" filing pattern (2006 and 2009) is a prosecution strategy by the individual owner, not an assignment event. Issuing one continuing application and abandoning the other is a common way to keep a family alive while limiting maintenance‑fee exposure — consistent with a solo monetization attempt, not with an operating company.

Timeline diagram

timeline
    title Ownership of US 7536353
    1999 : Priority date 1999 Oct 5
         : Independent inventor files provisional
    2000 : Parent application filed
    2006 : Parent issues as 7127427
         : Continuation 11518362 filed
    2009 : US 7536353 issued
         : Certificate of Correction recorded
    2016 : Eighth year maintenance fee paid
    2021 : Lapsed for unpaid maintenance fees

NPE / troll-pattern signals

Because the patent was never assigned, most signals are structurally impossible. Marked accordingly:

Aggravating observation (not one of the eight, but relevant): the patent is expired for non‑payment of maintenance fees effective 2021‑05‑19, and its sibling filings are expired or abandoned. Whatever assertion potential the claims once had is now legally extinguished — an NPE would have had to assert before mid‑2021, and none did.

Verdict

Insufficient data — specifically, no ownership chain exists to analyze.

Justification: the authoritative record shows Original Assignee = "Individual" and Current Assignee = "Individual" (Andrew Casper), with a legal‑events history limited to grant (2009‑04‑29), a Certificate of Correction (2009‑07‑07), two maintenance‑fee payments (2012‑10‑17, 2016‑09‑28), and a lapse for non‑payment (2021‑06‑21, effective 2021‑05‑19) — containing no recorded assignment, no reel/frame, and no correspondent of record. With no transfer to any entity, zero of the eight NPE signals can be affirmatively established, so neither "NPE" nor "operating‑company assertion" nor "defensive aggregator" is supportable; the honest call is that the data needed to classify the chain is absent, and the patent is now expired.

Verify / cite at: USPTO Assignment Center — search patent number 7536353; mirrored at assignment.uspto.gov/patent/index.html. Cross‑check the legal‑events panel at patents.google.com/patent/US7536353B2.

Do not repeat this error: reviewers sometimes import the Fortell Research Inc. / Chromatic Inc. assignments of a different Andrew J. Casper (Inver Grove Heights, MN) into this chain. Those are unrelated and must not be cited as assignments of US 7,536,353.

I'll search for the specific prior-art references cited against US 7,536,353. Let me pull details on each.

Let me pull the remaining background references and confirm the target patent's USPTO record.

Prior-Art Analysis — U.S. Patent No. 7,536,353 ("Secure transaction processing system and method")

Note on a date inconsistency (flagged, not resolved): the system prompt gives today's date as 2026-09-29, while this task states April 26, 2026. I proceeded with the substance of the request; the bibliographic and prior-art facts below do not turn on which date is current. Also flagged: this section builds on the two previously generated sections (Patent summary; Litigation summary) and does not repeat their content.

Scope/method note: I could not directly query the USPTO Patent Public Search or Patent Center terminals; retrieval was via patent mirrors (Google Patents, uspto.report, FreePatentsOnline, patentimages) plus general web search. Where I quote dates I use the authoritative values in the supplied patent text first, then the mirrors. Per your instruction, all identifiers are read literally.

1. The "Patent Citations" of record on US 7,536,353

The authoritative patent text lists four U.S./PCT patent citations and two non-patent citations. These are the only references the examiner of record cited against the application. Full detail per reference:

Critical dates for the target: priority 1999-10-05 (provisional 60/157,774) → §102(b) bar date ≈ 1998-10-05; pre-AIA §102/§103 applies. (These four are also what Google Patents shows in both its "Citations (4)" and "Patent Citations (4)" tables for US 7,536,353.)

Reference 1 — US 5,530,848 A

• Full citation: U.S. Patent No. 5,530,848, "System and method for implementing an interface between an external process and transaction processing system," The Dow Chemical Company. Filed 1992-10-15; granted 1996-06-25.
• Brief description: A message-broker/interface system that sits between an "external process" and a transaction processing system (the specification's environment is SAP-style business transaction processing, not payment processing). It logs inbound messages as control records in a log file, triggers the transaction processing system, and returns acknowledgment/status messages to the external application (regular, chain, and bulk message classes; monitor/status subsystems). The claims recite receiving an input message, creating a control record, confirming receipt, triggering the transaction system, and transmitting an output/status message to a designated destination.
• Potential §102 claim mapping: Effectively none for the purchase-processing claims. It qualifies as prior art under §102(b) (granted 1996, well over one year before the 1999-10-05 priority), but it discloses no purchaser identifier, no delivery address, no payment data, no PII exclusions, and no merchant/server-pays-merchant architecture. It cannot anticipate independent claims 1 or 7, or any dependent claim.
• Why it was cited (inference, flagged as inference): its closest conceptual overlap is the interface servlet that forwards a message to a transaction system and waits for a status/acknowledgment reply — i.e., an analog to claim 1's "server … communicate the purchase order to the computer on the secure network component; and wait to receive instructions." That overlap is architectural only; every substantive limitation of claims 1/7 is absent. Treat this as a §103-flavor architecture reference, not an anticipatory one.

Reference 2 — US 6,233,565 B1

• Full citation: U.S. Patent No. 6,233,565 B1, "Methods and apparatus for internet based financial transactions with evidence of payment," inventors Lewis et al., Saranac Software, Inc. Filed 1998-02-13 (Appl. No. 09/023,724); granted 2001-05-15 (a continued-prosecution application).
• Brief description: Internet client/server (customer PC ↔ remote service provider) financial-transaction system. A client authentication module and a server authentication module authenticate each other over the Internet; the client issues a transaction request; a transaction server executes an electronic payment and records it in a transaction database; a receipt generation module returns a digitally signed evidence-of-payment receipt. A third-party seller and a third-party credit facility (credit-card transactions) may be connected to the server. Examples: postage, airline tickets, entertainment tickets.
• Potential §102 claim mapping:
  • §102(e) reference (U.S. patent granted on an application — 1998-02-13 — filed before the 1999-10-05 priority/invention date).
  • Discloses elements relevant to claims 13–15 (payment effected via a third-party financial/credit facility) and to the generic client/server + transaction-database handling underlying claims 1 and 7.
  • Does not disclose: a purchaser identifier mapped to a non-changeable delivery address that is never selectable/changeable by the purchaser; an approval message that excludes all payment information; delivery constrained only to a stored address; or the two-tier "public server ↔ secure computer waits for instructions" claim-1 architecture. Not anticipatory of claims 1 or 7; relevant only as a secondary §103 reference and as §102(e) art against the third-party-financial-institution dependent claims if claim 7 were otherwise met.

Reference 3 — US 6,122,624 A

• Full citation: U.S. Patent No. 6,122,624 A, "System and method for enhanced fraud detection in automated electronic purchases," Automated Transaction Corp. Filed 1998-05-28; granted 2000-09-19.
• Brief description: Automated telephonic/PC purchase fraud detection. The purchaser inputs address, telephone number, and Social Security number; the system queries a local account database (blocked/exceeded accounts) and then a central database of Social Security numbers each stored with at least one associated address; it compares the input SSN to the stored list and the input address to the stored address(es), authorizing only on a match; Automatic Number Identification (ANI) blocking is also used.
• Potential §102 claim mapping:
  • §102(e) reference (filed 1998-05-28, before the 1999-10-05 priority).
  • Its closest overlap is with the claim 1/7 "determining whether the purchaser identifier in the purchase order matches the [identifier] stored in the purchaser account record" and with the notion of comparing a submitted address to a stored address.
  • Materially contrary to the target's core negative limitation: the identifier here is an SSN, which is personally identifiable information — the opposite of claim 1's requirement that the identifier "provides no indication of personally identifiable information of the purchaser." It also does not disclose a fixed/non-changeable delivery address, an approval message that excludes payment information, delivery-only-to-stored-address, or the merchant-server payment architecture. Not anticipatory of claims 1 or 7.

Reference 4 — WO 2000/002150 A1 ← closest prior art of record

• Full citation: International (PCT) Publication No. WO 2000/002150 A1, "Transaction authorisation method," Webcard Inc. Priority 1998-07-01; international application PCT/AU99/00536; published 2000-01-13.
• Brief description (from the reference itself): A remote customer–merchant transaction method in which:
  • the customer is issued a "Transaction Code" used as a substitute for the account number, so the customer's account number is not disclosed to the merchant;
  • an "Address Code" is linked to a delivery location nominated by the customer, and the delivery location "may be a physical address or an electronic address mapped to a physical address";
  • the system "requires a pre-arranged delivery address to be supplied by the customer" and "does not require the customer to transmit their card number or account information across an open and unsecured communications channel";
  • the merchant has a "Merchant Code"; issuers/acquirers/a Transaction Authority and the merchant's acquirer-held account handle funds;
  • storage means hold one or more Address Codes, matching Address Codes to physical addresses, and "accessing the store … to retrieve an Address Code corresponding to an entered delivery location."
• Potential §102 claim mapping (this is the strongest candidate):
  • Claims 1 / 7 (core): the Transaction Code functions as the purchaser identifier that bears no relation to financial data; the Address Code functions as the delivery address linked to the identifier; the pre-arranged/fixed delivery location maps to "delivery addresses cannot be changed by the purchaser during a purchase"; and the merchant receiving only the Transaction Code maps to "at least the purchaser identifier is communicated to the merchant by the purchaser". This reference discloses most of the substance of the independent claims.
  • Claims 2, 9 (physical address) and claims 3, 4, 10, 11 (electronic address / e-mail address): the reference expressly recites a physical address or an electronic address mapped to a physical address.
  • Claims 5, 12 (only one address per type): the reference's "one or more Address Codes, each … a delivery location," retrieved by a corresponding entered code, is directly on point.
  • Claim 6 / claim 8 (an indication of the selected address that does not reveal the actual address; selection without revealing addresses until after selection): the Transaction Code / Address Code indirection is the reference's stated mechanism for keeping the account/address hidden from the merchant.
  • Claims 13–15 (payment via a third-party financial institution — bank or credit-card company): the reference's Issuer/Acquirer "may be a bank or other financial institution".
• Status/date caution: the reference published 2000-01-13, i.e. after the 1999-10-05 priority date, so it is not §102(b) art and is §102(a) only if the invention date is later. Its prior-art force is therefore chiefly §102(e) — a published PCT application, published in English, as of its 1999 international filing date if it designated the United States. I could not confirm the U.S. designation or the exact PCT filing date from the mirrors retrieved, so treat the §102(e) date as to be verified against the WO front page.
• Why it likely did not anticipate cleanly: the reference frames the method around customer→merchant→Issuer/Transaction Authority, and does not expressly describe the target's specific two-tier architecture (a public-network server that receives a purchase order, communicates it to a separate secure-network computer, and "wait[s] to receive instructions"; the secure computer then returning an approval message that contains a selected stored delivery address and excludes any payment information). That is exactly the sort of residual gap that yields a §103 rather than a clean §102 rejection. So: WO 2000/002150 A1 is the most relevant reference, is strong §102(a)/(e) art against the descriptive/core concepts, and is the natural lead reference for any obviousness combination — but a clean single-reference §102 anticipation of claims 1 and 7 on the record as it stands is not established.

2. Background references discussed (not examiner-cited) — same field, high relevance

Although the task focuses on "each patent citation for 7536353," two references the patent itself discusses in its Background are the true conceptual neighbors and should be in any prior-art file:

• US 5,757,917 A — "Computerized payment system for purchasing goods and services on the internet," Rose et al., First Virtual Holdings Inc. Filed 1995-11-01; granted 1998-05-26. Discloses a "cardnumber" that is an alphanumeric token which "bears no deducible relationship to any financial artifact," a buyer-facing above-the-line / below-the-line (firewall-isolated secure) architecture, buyer authorization by e-mail, and settlement off-network through issuers/acquirers. This is the closest antecedent to the target's "identifier provides no indication of personally identifiable information" + firewall architecture and is §102(b) art (1998-05-26). Potential §102 relevance: the "opaque identifier" and split secure/public architecture of claims 1/7. It lacks the fixed/non-changeable delivery-address and delivery-only-to-stored-address concepts.
• US 5,826,241 A — "Computerized system for making payments and authenticating transactions over the internet," Stein et al., First Virtual Holdings Inc. Filed 1994-09-16; granted 1998-10-20. The companion First Virtual application referenced in the '917 patent. §102(b) art. Same field; supports an obviousness combination but is not a standalone anticipation of claims 1/7.

(Both are cited in the target's Background section, so they are "of record" in the specification even though they are not in the "Patent Citations" table.)

3. Non-Patent Citations of record

From the patent's own "Non-Patent Citations (2)":

1. Garcia, Paul et al., "Minimize Your risk," Target Marketing, v28 n12, p. 39, Dec. 2006 (Dialog file 15, Accession No. 02990461).
2. Valentine, Lisa, "The fraudsters playground: the web is becoming more bane than boon as online credit card fraud soars…," ABA Banking Journal, v95 n8, p. 39(3), Aug. 2003 (Dialog file 16, Accession No. 10661864).

Both are dated after the 1999-10-05 priority (2003 and 2006) and are trade-press fraud articles. They cannot be §102(b)/§102(a) prior art against the 1999 priority; at most they are background/context and/or evidence bearing on the state of the art at later dates. They do not anticipate any claim.

4. Other prior art worth adding to the file (from the "Family Cites Families" set)

The patent's forward/backward family-citation lists include several pre-1998 references that are more substantive against the delivery-control and identifier concepts than three of the four examiner citations. Per your instruction to interpret IDs literally, these are (as listed in the supplied text):

• US 5,960,411 A — Amazon.com "1-Click" (method and system for placing a purchase order via a communications network), 1997-09-12 → 1999-09-28.
• US 5,999,596 A — Walker Asset Management, "Method and system for controlling authorization of credit card transactions," 1998-03-06 → 1999-12-07.
• US 5,822,737 A — Ogram, "Financial transaction system," 1996-02-05 → 1998-10-13.
• US 5,963,915 A — Infoseek, "Secure, convenient and efficient system and method of performing trans-internet purchase transactions," 1996-02-21 → 1999-10-05.
• US 5,870,717 A — IBM, "System for ordering items over computer network using an electronic catalog," 1995-11-13 → 1999-02-09.
• US 5,500,467 A — Pollin, "Automated payment system," 1992-10-15 → 1996-04-02.
• US 5,794,207 A — Walker Asset Management, buyer-driven conditional purchase offers, 1996-09-04 → 1998-08-11.

Most useful of these for the target's claims: US 5,999,596 (credit-card-transaction authorization control) and US 5,963,915 (secure trans-internet purchase transactions) — both firmly pre-1999 and both directed at isolating/limiting exposure of payment credentials, which is the target's stated problem.

5. Bottom line

• Only four patent citations are of record against US 7,536,353: US 5,530,848; US 6,233,565; US 6,122,624; and WO 2000/002150 A1.
• Most relevant single reference: WO 2000/002150 A1 (Webcard Inc.) — it discloses the opaque "Transaction Code" substitute for the account number, a pre-arranged Address Code linked to a fixed delivery location (physical or electronic), and a merchant/Issuer/Acquirer payment flow. It is the best §102(a)/(e) candidate and maps onto claims 1–15, with claims 2–6 and 9–15 the most directly supported. Its anticipatory force is limited by the post-priority publication date (2000-01-13), which makes its §102(e) international filing date (to be verified) the operative date, and by its apparent silence on the target's specific two-tier "server waits / approval excludes all payment information" architecture.
• US 6,122,624 (identifier-to-stored-address matching) and US 6,233,565 (Internet payment with third-party credit facility) are secondary references — useful for §103 combinations and for claims 13–15, but non-anticipatory of claims 1/7.
• US 5,530,848 is the least relevant (generic message-interface/acknowledgment architecture) and anticipates no claim.
• The two non-patent citations (2003, 2006) are post-priority and non-anticipatory.
• The two First Virtual references discussed in the specification — US 5,757,917 and US 5,826,241 — are §102(b) art and are conceptually closer to the target's core "opaque identifier + isolated secure side" idea than three of the four examiner citations, even though they are not in the "Patent Citations" table.

Caveats: (i) I could not confirm the WO 2000/002150 A1 international filing date or its U.S. designation from the sources retrieved — verify on the WO front page before relying on §102(e); (ii) mapping of a reference to specific claims is an analytical opinion, not a legal conclusion, and the "cannot be changed by the purchaser during a purchase" / "excludes any payment information" negatives are the limitations most likely to survive each of these references.

I'll ground the § 103 analysis in the actual prior-art references listed on the patent page. Let me pull details on the most relevant ones.

Let me pull the remaining cited references that bear on the tamper-disable and delivery-control limitations.

Obviousness Analysis — U.S. Patent No. 7,536,353 under 35 U.S.C. § 103

Building on the previously generated summary and litigation sections. I do not repeat the bibliographic table or the claim overview; where I rely on them, I cross-reference.

Governing law. Because the '353 patent is a continuation of an application filed 2000-03-08 and claims priority to 1999-10-05, it is governed by pre-AIA 35 U.S.C. §§ 102/103. The controlling obviousness standard is Graham v. John Deere Co., 383 U.S. 1 (1966), as refined by KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007). Post-KSR, the "teaching, suggestion, or motivation" test is not the only route to obviousness: a combination of known elements is obvious where the improvement is "a predictable use of prior art elements according to their established functions" (KSR).

⚠ Cross-reference flag (substantive, not a contradiction). The previously generated summary emphasizes the "disabler 160" as a signature feature. That is correct as to the specification and abstract — but no claim recites a disabler. Independent claims 1 and 7 capture only (i) the two-tier secure/public architecture, (ii) an opaque purchaser identifier, (iii) a match test, (iv) an approval returning a stored delivery address and excluding payment data, and (v) effecting payment. Any obviousness defense or attack must therefore be argued against that narrower claim scope, not the disabler narrative. I flag this because it materially lowers the obstacle to a § 103 rejection.

1. Person of Ordinary Skill in the Art (POSITA)

A POSITA as of the 1999 priority date would have a bachelor's degree in computer science or information systems (or equivalent) and 2–4 years' experience designing networked electronic-payment or e-commerce systems, including familiarity with client–server architectures, firewalls/application-level gateways, database record design, and the conventional Internet payment protocols of the day (SSL, the First Virtual / Green Commerce model, CyberCash, iKP, and SET). This is a predictable, engineering-driven art — a factor weighing toward obviousness under KSR.

2. The Asserted Prior Art (from the patent page's own prior-art section)

Prior-art status note. Each reference above qualifies as prior art against the 1999-10-05 priority date: 5,757,917 / 5,826,241 / 5,999,596 / 5,960,411 / 5,729,594 / 5,822,737 issued before that date; 6,122,624 (filed 1998-05-28) and 6,233,565 (filed 1998-02-13) are available under § 102(e) as of their U.S. filing dates; WO 2000/002150 designates the US and published in English, giving it a § 102(e) date of its international filing date, 1998-07-01. None is commonly owned with the '353 patent (individual inventor), so § 103(c) disqualification does not apply.

3. Element-by-Element Mapping — Independent Claim 1

Result. Every limitation of claim 1 is disclosed or rendered obvious by Rose '917 (or Stein '241) in view of Webcard WO 2000/002150. Method claim 7 is the same subject matter in method form and falls with claim 1.

4. Grounds of Rejection and Motivations to Combine

Ground 1 — Claims 1 and 7: Rose '917 (or Stein '241) in view of Webcard '150

Why combine. Both references address the same recognized problem in the same field: transmitting payment credentials over an insecure quasi-public network risks interception and merchant-side leakage. Rose/Stein solve it architecturally (isolate payment data below a firewall; circulate only a non-financial cardnumber). Webcard solves it substitutionally (circulate a Transaction Code in place of the account number) and additionally supplies a stored Address Code → delivery location mapping so the merchant never receives the raw card number yet can still deliver. A POSITA would have been motivated to merge Webcard's Transaction-Code/Address-Code substitution into Rose's above-the-line/below-the-line architecture because the two are complementary, non-interfering solutions to the identical security problem — KSR ("a predictable variation … using prior art elements according to their established functions"); In re Keller (references need not be bodily incorporated).

Why the specific claim language still fails to distinguish. Claim 1's only arguably "narrow" negatives are (a) the identifier reveals no PII, and (b) the delivery address cannot be changed during purchase. Rose literally discloses (a); Webcard literally discloses (b) via its "pre-arranged" delivery address. The "wait to receive instructions" step is no more than generic client-server dependence and is expressly disclosed by Rose's payment-query/response handshake.

Ground 2 — Claims 1 and 7: Ground 1 further in view of Automated Transaction '624

Why combine. Claim 1 requires the system to match the submitted identifier to the stored account record and to control the outcome on that match. Webcard and Rose describe the matching implicitly; Automated Transaction '624 makes it explicit, teaching a stored-address/identifier database queried against an input value, with authorization only on a match and denial (and account blocking) on non-match. A POSITA would look to '624 because it is the same domain (fraud prevention in remote electronic purchases) and supplies the very compare-and-gate logic the claim recites. This ground also supplies the conceptual hook for the specification's "disabler" — even though the disabler is unclaimed, '624's "blocked due to past fraudulent use" shows that disable-on-anomaly was routine.

Ground 3 — System-Level Claims: any of Grounds 1–2 further in view of Walker '596

Why combine. For any reading in which the claims implicitly require the intermediary to control authorization (not merely relay), Walker '596 teaches a central party linking the customer and a merchant to a financial account, receiving account/merchant data, and enabling or denying the transaction — i.e., the authorizing-intermediary function. The motivation is the same anti-fraud objective, and Walker's "controlling authorization" fills any residual gap in the "approval message" limitation.

Ground 4 (dependent claims) — trivial, well-known variations

5. Absence of Rebutting Secondary Considerations

Under Graham, objective indicia can rebut a prima facie case, but the record here points the other way:

• No commercial success, licensing, or industry-acclaim evidence is on the face of the patent or in any retrieved source.
• No litigation/assertion history (see the previously generated litigation section — the patent appears never to have been asserted).
• The entire family is inactive: US 7,127,427 expired; US 7,536,353 lapsed for non-payment of maintenance fees effective 2021-05-19; US 12/420,920 abandoned. An individual-owned, never-asserted, fee-lapsed patent is weak evidence of non-obviousness (and there is no nexus between any alleged acclaim and the claimed subject matter).
• The applicant's own Background characterizes Rose '917 and Stein '241 as known systems whose only shortfall was "fail[ing] to control the delivery component" — precisely the gap Webcard fills. That is close to a judicial/admission-style concession that the inventive step, if any, was the delivery-control idea, which the prior art already taught.

6. Conclusion

The claims do not recite the specification's touted disabler and recite nothing else that rises above a predictable combination of known electronic-commerce elements — a firewall-partitioned central payment authority (Rose/Stein), an opaque substitute identifier and stored pre-arranged delivery code (Webcard), and a match-and-gate authorization (Automated Transaction '624; Walker '596). Under KSR, that combination would have been obvious to a POSITA with a reasonable expectation of success.

7. Uncertainty Flags (do not over-read this analysis)

1. I did not retrieve full specifications for US 6,233,565 (Saranac) and US 5,530,848 (Dow); my reliance on them is limited to their titles and to their role as examiner citations. Confirm their disclosures before relying on them in a formal rejection.
2. I do not have the prosecution history (office actions / applicant remarks) for application 11/518,362 or its parent 09/521,636. It is possible the examiner cited Webcard '150 and '624 against other claims or in a manner not reflected on the Google Patents face page. A full file-history review could reveal applicant arguments that narrow the claim construction.
3. Date determination for WO 2000/002150 depends on its § 102(e) treatment (PCT designating the US, published in English, international filing date 1998-07-01). I verified the filing/publication data from the retrieved documents but did not independently confirm the designation/EES artifacts from the PCT front page.
4. Some "Family Cites Families" entries (e.g., Certco '915, Ogram '737, Klingman '594) I cite only for the general state of the art; I did not pull their full texts, so treat those rows as contextual, not as primary § 103 grounds.
5. Claim-construction sensitivity. If a court reads claim 1's "selected one of the delivery addresses" in the purchase order (incoming) and in the approval message (outgoing) as requiring the same actual address string to appear in both, a defendant would need Webcard's Address-Code mapping (or claim 6's "indication … that does not reveal the actual delivery address") to bridge the two. I have flagged that reading explicitly, because it is the one place the claim language is genuinely awkward and could support a non-obviousness argument.