Invalidity Analysis — US5960411A (public record)

For attorney review — not a legal opinion, not a validity determination. The eligible corpus contains NO reference that cleanly discloses the target's central inventive feature — placing/completing a purchase order in response to 'only a single action' with a purchaser identifier that the server uses to retrieve previously-stored account/shipping/payment data — so no strong §102 anticipation ground is supported (the three license-management references, per the IS4 charts, are missing the entire purchasing purpose and the single-action trigger, and are further vulnerable to a non-analogous-art challenge). The most defensible candidate grounds are §103 combinations built on the two genuine e-commerce references: WO1995030961A1 (a client-server card selection/ordering system with a stored recipient/customer database, display of item information, order generation, and fulfillment by a distribution center) and WO1996038799A1 (a merchant server that stores customer payment data keyed to the customer, retrieves it, and transmits partial payment information over the Internet for the customer to confirm in a return message). Together these map well to the client-server display/order/retrieve/fulfill architecture and to the 'partial information' dependent claims (23-25), and WO1996038799A1 is a strong stand-alone teaching for the partial-payment/identity display limitations. The dispositive gap common to every ground is the 'single action' / 'without a shopping cart' limitation, which neither commerce reference discloses; a PHOSITA-motivation argument must be articulated without impermissible hindsight from the target's own disclosure, and the patentee's best defenses are the missing single-action element and, for any ground invoking the license-management art, non-analogous art under MPEP § 2141.01(a).

Candidate grounds for attorney evaluation, ranked strongest-first — not a validity determination. Confirm every reference date and quotation before relying on a ground.

Ground 1 — §103 obviousness

Strength: moderate
References: WO1995030961A1, WO1996038799A1
Claims: 1, 9, 11, 12, 13, 14, 15, 16
KSR rationale: (A) — MPEP § 2143

The combination would map to claim 1/11's 'displaying information identifying the item' (WO1995030961A1's terminal 'display means for displaying textual and graphical information representative of the ... card design data'), 'sending ... a request to order the item along with an identifier' and 'retrieving additional information previously stored for the purchaser' (WO1996038799A1's server retrieving the customer's stored credit-card data from its database in response to a communication identifying the customer), 'generating an order' and 'fulfilling the generated order to complete purchase' (WO1995030961A1's distribution center processing and fulfilling the card order). Claim 14 (Internet) and claim 15 (HTML/Web page) read on WO1996038799A1's 'World Wide Web page'; claim 16 (server-to-client confirmation) reads on the order-status/return-message exchanges; claims 12-13 (server uses an identifier to locate additional information the server provides) read on the merchant database keyed to the customer.

Motivation to combine: Both references are in the same field of endeavor — remote client-server ordering of goods/services over a communications network — and address the same problem of letting a customer order from a remote terminal using information a merchant keeps on file. WO1995030961A1 discloses the full ordering/fulfillment loop ('a communications link coupling the customer access terminal to the distribution center to permit communication of the card order to the distribution center for processing of the card order' and a distribution center that 'processes the order, retrieves and prints the selected card images ... and mails the cards'), while WO1996038799A1 supplies the server-side retrieval of previously-stored customer account/payment data keyed to the customer and its transmission over the Internet ('retrieving the credit card number of the customer from the database' and 'transmitting the message to the customer over the non-secure network,' with 'The message comprises a World Wide Web page'). Combining the known card-ordering architecture with the known server-stored-customer-data retrieval yields the predictable result of an Internet order in which the server uses a customer identifier to pull stored data to complete the order (MPEP § 2143 rationale (A)); a PHOSITA would have had a reasonable expectation of success because both use conventional client-server request/response over a network.

Weakest link: Neither reference discloses ordering 'in response to only a single action' or ordering 'without using a shopping cart ordering model' — WO1995030961A1 is expressly a multi-step select-recipient/select-card/enter-message/place-order flow, the antithesis of a single action. This limitation, the heart of the claims, is absent from the combination and cannot be supplied without hindsight from the target patent (MPEP § 2143.01).

Patentee's likely counterarguments:

• The single-action ordering limitation is missing from both references, and articulating a reason to collapse the disclosed multi-step ordering into one action draws impermissibly on the target's own disclosure (hindsight, MPEP § 2145).
• WO1995030961A1's principle of operation is a deliberately multi-step personalization/selection workflow; modifying it to a single action would change its principle of operation and arguably render it unsatisfactory for its intended purpose (MPEP § 2143.01).
• The 'whereby the item is ordered without using a shopping cart ordering model' clause has no counterpart in either reference.

Ground 2 — §103 obviousness

Strength: moderate
References: WO1996038799A1
Claims: 23, 24, 25, 26
KSR rationale: (C) — MPEP § 2143

WO1996038799A1 discloses 'extracting a portion of the credit card number, said portion being substantially smaller than the complete credit card number' and 'constructing a message containing the portion of the credit card number' transmitted as 'a World Wide Web page' — directly reading on claim 25 ('displaying partial payment information supplied by the server system'). The customer-identification and account-lookup teaching reads on claim 23 ('partial information ... as to the identity of a user'), and the concept of server-supplied stored shipping/address data would render obvious claims 24 and 26 (partial shipping information / a moniker identifying a shipping address) as predictable variants of the same partial-data-display technique. These dependents, however, incorporate claim 11's independent limitations, so this ground reaches them only in combination with a reference supplying the single-action ordering step.

Motivation to combine: As applied to the partial-information dependent limitations, WO1996038799A1 itself teaches the very technique claimed: a merchant server retrieving stored customer data and displaying only a PORTION of it to the customer for confirmation. Using this known technique of displaying partial server-supplied customer/payment information in a network ordering interface improves such an interface in the same predictable way (MPEP § 2143 rationale (C)); a PHOSITA had a reasonable expectation of success because the reference already performs exactly this over the Internet.

Weakest link: WO1996038799A1 alone does not supply claim 11's base ordering method (display of an ordering action and a request to order in response to a single action); this ground only completes the partial-information dependent limitations and depends on a separate showing for the independent claim.

Patentee's likely counterarguments:

• WO1996038799A1 is a credit-card-number confidentiality technique, not an ordering method; the dependent claims cannot stand alone without the anticipation/obviousness of independent claim 11, which this reference does not establish.
• Claims 24 and 26 (partial shipping information / shipping-address moniker) are not expressly disclosed — the reference speaks only of credit-card numbers, so mapping shipping information requires an inference the patentee will contest as unsupported.

Ground 3 — §103 obviousness

Strength: weak
References: Conditional purchase orders, WO1996038799A1
Claims: 1, 11, 12, 14
KSR rationale: (A) — MPEP § 2143

The CPO reference's buyer-issues-order-and-is-bound model could be argued to approach an order placed with reduced buyer steps, and its fulfillment-by-sellers teaching maps loosely to 'fulfilling the generated order.' WO1996038799A1 supplies the identifier-keyed server retrieval of stored purchaser information (claims 12) and the Internet channel (claim 14).

Motivation to combine: 'Conditional purchase orders' discloses a buyer-initiated electronic purchase mechanism ('Individual buyers issue CPOs, which are evaluated and fulfilled by sellers') with binding of the buyer once conditions are met, and contemplates commerce protocols and anonymity; WO1996038799A1 supplies server-stored customer data retrieval over the Internet. A PHOSITA in electronic commerce would combine a streamlined buyer-issued order mechanism with server-side stored-account retrieval to yield a predictable network purchase transaction (MPEP § 2143 rationale (A)).

Weakest link: The provided text of 'Conditional purchase orders' is a sparse abstract/introduction that does not disclose a client-side display of an item, a single-action trigger, a purchaser identifier sent with the request, or the absence of a shopping cart; the ground rests on generic commerce concepts and would require substantial unsupported inference.

Patentee's likely counterarguments:

• The CPO reference as provided contains no single-action ordering, no client-side item display, and no purchaser-identifier-to-server retrieval — multiple independent-claim limitations are simply absent.
• The CPO model (conditional, negotiated, seller-evaluated offers) operates on a fundamentally different principle than a fixed-price immediate single-action purchase, undercutting any predictable-combination rationale (MPEP § 2143.01).

Ground 4 — §103 obviousness

Strength: weak
References: Automating the small purchase solicitation cycle for non-EDI trading partners using Internet technologies, WO1996038799A1
Claims: 11, 14, 15
KSR rationale: (F) — MPEP § 2143

The procurement-automation reference supplies the general teaching of conducting purchase/solicitation transactions over Internet technologies (claims 14 Internet, 15 HTML/Web documents), and WO1996038799A1 supplies server-side stored-customer-data handling; together they could be argued to render obvious an Internet ordering method under claim 11.

Motivation to combine: The 'Automating the small purchase solicitation cycle' paper teaches using Internet technologies to automate procurement/purchase transactions with non-EDI partners; WO1996038799A1 teaches conducting the customer-data portion of a purchase over the Internet via Web pages. Market forces toward Internet-based purchasing would prompt a PHOSITA to combine these known Internet procurement techniques to reach a Web-based item-ordering method (MPEP § 2143 rationale (F)).

Weakest link: As provided, this reference is an abstract about automating solicitation/bidding for small purchases and discloses none of claim 11's specific limitations — no client display of an ordering action and no single-action request to order; the ground is essentially a general 'Internet commerce was known' argument that does not reach the claimed single-action feature.

Patentee's likely counterarguments:

• The reference concerns EDI/non-EDI solicitation-and-bid procurement, not consumer single-action item ordering; it discloses neither a single action nor ordering without a shopping cart.
• Only the abstract is available; asserting the paper discloses the claimed display-and-single-action steps would be unverified and speculative (MPEP § 2131 / § 2143.01).

Ground 5 — §103 obviousness

Strength: weak
References: WO1995030961A1, WO1996038799A1, US5204897A
Claims: 6, 9, 10
KSR rationale: (A) — MPEP § 2143

WO1995030961A1's customer access terminal/distribution center and stored recipient database map to the client, order fulfillment, and data-storage elements; WO1996038799A1's identifier-keyed retrieval maps to the receiving/order-placement components; US5204897A supplies the generic request-with-identifier-and-server-lookup pattern for the receiving component.

Motivation to combine: For the system claims requiring both a shopping-cart ordering component and a separate single-action ordering component (claim 6) or a server with a shopping-cart component plus receiving/order-placement/fulfillment components (claim 9), WO1995030961A1 and WO1996038799A1 supply the ordering-terminal/server, database, receiving, order-placement, and fulfillment structures, and US5204897A supplies a generic client-server request/lookup-by-identifier mechanism ('sending from one of said nodes to said processor a request by a user ... said request identifying the user' and 'accessing said store ... to obtain information ... in response to said request'). A PHOSITA could assemble these known client-server components to yield a predictable ordering server (MPEP § 2143 rationale (A)).

Weakest link: None of the references discloses the required 'shopping cart ordering component' co-existing with a 'single-action ordering component,' and neither commerce reference discloses the single-action trigger; US5204897A is a software-license system whose inclusion invites a non-analogous-art challenge.

Patentee's likely counterarguments:

• US5204897A is directed to software license usage authorization, a different field of endeavor and not reasonably pertinent to single-action consumer purchasing, and is therefore non-analogous art under MPEP § 2141.01(a).
• No reference discloses a shopping-cart ordering component paired with a single-action ordering component; the claimed dual-component arrangement is absent from the combination (MPEP § 2141.02).
• The single-action trigger and shopping-cart-independent ordering remain missing across all cited references.

Unverified leads (no established date — not usable as grounds)

These references had no establishable date, so they were withheld from the grounds analysis — an undated reference cannot anchor a §102/§103 ground. Undated web results are often post-priority commentary describing the target’s own commercialized feature; treat these strictly as leads to date manually.

• ESSAYS ON DIGITAL EXPERIENCE (non-patent literature)
• Who’s Afraid of amazon.com v. barnesandnoble.com? (non-patent literature)
• World wide web business catalogs in business-to-business procurement (non-patent literature)
• REST in Practice (non-patent literature)
• ONLINE ORDERING AND PAYMENT SYSTEM WITH SMS NOTIFICATION FOR NINA CLOTHING ACCESSORIES (non-patent literature)
• Canteen Food Ordering and Managing System (non-patent literature)

Element-by-element mapping of the strongest prior-art references against the target’s independent claims. A single absent element defeats §102 anticipation for that reference (it may still contribute to a §103 combination). Quoted reference passages are verified verbatim against the fetched reference text; any unverified quote is flagged in the Priority-Date Discipline section. For attorney review.

US4937863A — Software licensing management system vs. claim 1

Verdict: missing element(s) — no §102.

US4937863A is a software license management system that determines whether a requested use of a licensed program falls within license limits; it is unrelated to purchasing goods. Only two generic data-processing concepts arguably map: a 'request receiving means for receiving a usage request' (element 3, but it receives a license-usage request, not an order request, and there is no 'single-action ordering component') and a 'licensing unit retrieval means ... for retrieving the contents of said licensing unit storage field' keyed to a program identifier (element 4, but the retrieved data is license unit values keyed to a program, not purchaser account/shipping/payment information keyed to a purchaser identifier). The core purchase-transaction limitations are entirely absent: there is no client-side displaying of an item (element 1), no single action that sends an order request with a purchaser identifier (element 2), no generation of an order to purchase an item (element 5), no order fulfillment to complete a purchase (element 6), and no teaching directed to ordering without a shopping cart model (element 7). Because multiple limitations are absent from this single reference, it would not anticipate claim 1 under §102 (MPEP § 2131); its relevance, if any, would be limited to a generic request/retrieve teaching in a §103 analysis.

US4937863A — Software licensing management system vs. claim 6

Verdict: missing element(s) — no §102.

US4937863A is a software license-management system directed to metering and authorizing use of licensed software programs; it is not a commerce/ordering system and does not map to claim 6. Only element (4) finds any loose analogue: the reference discloses a request message that identifies a licensed program used to retrieve stored data ('request receiving means for receiving a usage request identifying a licensed software program' and retrieving the entry 'whose program identification field identifies the licensed software program identified in said usage request'), but this is a program identifier for license lookup, not a customer identifier included so a server can complete a purchase order. Every other core limitation — a customer identifier, a display component for item information, a single-action ordering component that sends an order request, server fulfillment to complete a purchase, and a shopping-cart ordering component — is entirely absent from the reference's text. Because multiple limitations arranged as in the claim are missing, this single reference would not anticipate claim 6 under §102 (MPEP § 2131); at most it could be argued as a component in a §103 combination, which is outside the scope of this anticipation chart.

US4937863A — Software licensing management system vs. claim 9

Verdict: missing element(s) — no §102.

US4937863A is a software license management system directed to determining whether usage of a licensed program is within the scope of a license — it is not an e-commerce order-generation server. At an abstract structural level it discloses a data storage means holding a plurality of entries (element 3, but for licensed programs rather than 'users') and a request-receiving means that retrieves a stored entry keyed to an identifier in the request (partial support for elements 4 and 6, but the identified subject is a software program and the request is a 'usage request' to run software, not a request to 'order an item' or an 'indication of one of the plurality of users'). Critically, the reference contains NO disclosure of a shopping cart ordering component (element 1), a single-action ordering component (element 2), a request sent 'in response to only a single action being performed' (element 5), use of the retrieved information 'to place an order... for the item' (element 7), or an order fulfillment component that 'completes a purchase of the item' (element 8). Because multiple limitations — including the entire purchasing/ordering purpose of the claim and the single-action trigger — are wholly absent from this single reference, it would NOT anticipate claim 9 under §102 (MPEP § 2131); the partially-mapped storage/retrieval elements could at most be argued in a §103 combination, which is outside the scope of this anticipation chart.

US4937863A — Software licensing management system vs. claim 11

Verdict: missing element(s) — no §102.

US4937863A is directed to a software license management system that determines, in response to a 'usage request to use said licensed software program,' whether usage falls within the scope of a license by comparing licensing unit values against usage allocation values. It concerns granting/releasing permission to run licensed software — not commerce or the purchasing of items. None of claim 11's elements find any support in the reference's available text: there is no disclosure of displaying information identifying an item for purchase, no display of an indication of a single ordering action, no client-to-server request to order an item, no reference to a shopping cart model (or ordering independently of one), and no fulfillment of an order to complete a purchase. The reference's 'usage request' is a machine-generated license verification query, not an item order triggered by a user's single action, and its 'licensed software program' is the requestor rather than a merchandise item being purchased. Because every limitation of claim 11 is absent, this reference does not anticipate claim 11 under §102 (MPEP § 2131); its subject matter is remote enough that it would also be a weak contributor to any §103 combination in this technical field.

US5204897A — Management interface for license management system vs. claim 1

Verdict: missing element(s) — no §102.

US5204897A discloses a software license-management system in a client-server (node/processor) architecture, and it maps only loosely onto two of claim 1's structural elements: a client node sends a request identifying the user and item to a server that receives it (element 3, partial) and the server accesses a stored authorization to retrieve previously stored information for the identified user (element 4, partial). However, the reference is directed to granting or refusing permission to USE licensed software, not to placing a commercial purchase order. It contains no disclosure of displaying information identifying a purchasable item (element 1), of a request triggered by 'only a single action' to ORDER an item with a purchaser identifier (element 2), of generating a purchase order (element 5), of fulfilling an order to complete a purchase (element 6), or of ordering 'without using a shopping cart ordering model' (element 7). Because multiple limitations — including the core purchase-ordering, single-action, and fulfillment elements — are entirely absent from this single reference, it would not anticipate claim 1 under §102 (MPEP § 2131); the request/retrieve mechanism could at most be argued as one input to a §103 combination, which is outside the scope of anticipation.

US5204897A — Management interface for license management system vs. claim 6

Verdict: missing element(s) — no §102.

US5204897A is directed to a software license management system in which a user node sends a request (identifying the user and software item) to a license server that checks a stored product-use-authorization database and returns a grant or refusal. Only two elements of claim 6 map even partially: the notion of a request that 'identif[ies] the user' loosely corresponds to the 'identifier that identifies a customer' (element 1) and the server's use of that identity to look up stored license information corresponds in part to the server 'locat[ing] additional information' (element 4). However, this reference is not an item-ordering/e-commerce system and discloses none of the core commerce limitations: there is no display component showing information identifying an item for sale (element 2), no single-action ordering component that sends an order in response to only a single action (element 3), no fulfillment to complete a purchase of the item (element 5), and — dispositively — no shopping cart ordering component that adds an item to a shopping cart (element 6). Because multiple limitations are absent from this single reference, it would not anticipate claim 6 under §102 (MPEP § 2131); at most it might be argued as one input to a §103 combination, which is outside the scope of this anticipation chart.

US5204897A — Management interface for license management system vs. claim 9

Verdict: missing element(s) — no §102.

US5204897A discloses a distributed license-management server that maintains a store of license documents (mapping loosely to a 'data storage medium'), receives a request from a user that identifies the user and product (mapping loosely to a 'receiving component' with a user indication), and accesses the store to obtain information for the request (mapping loosely to an 'order placement component' that 'retrieves...information'). However, this reference is directed to granting or refusing permission to USE licensed software, not to placing purchase orders. It does not disclose the core commercial-ordering limitations of claim 9: no shopping cart ordering component, no single-action ordering component, no request 'sent in response to only a single action being performed,' no placing of an order for an item using retrieved user information (the system produces a 'grant or refusal' of a usage request rather than an order), and no order fulfillment component that completes a purchase. Because at least five limitations are absent — including the distinguishing single-action, order-placement, and order-fulfillment elements — this single reference would not anticipate claim 9 under §102 (MPEP § 2131); at most certain generic server/database/request-handling elements map partially, which is relevant only to a potential §103 analysis, not §102.

US5204897A — Management interface for license management system vs. claim 11

Verdict: missing element(s) — no §102.

This reference is a software license management system that is directed to an entirely different problem than the target claim. It discloses a client node sending a request to a license server to obtain permission to use a licensed software item (claims 3-4: 'sending from one of said nodes to said processor a request by a user of one of said software items to obtain permission to use said software item; said request identifying the user and said software item'), which maps only loosely and partially to element (3)'s notion of sending a request to a server system — but the request is to obtain a usage permission grant, not to order or purchase an item. Critically, the reference contains no disclosure of (1) displaying information identifying an item for ordering, (2) displaying an indication of a single action to order the item, (4) ordering independently of a shopping-cart model, or (5) fulfilling the order to complete a purchase. Because at least four claim limitations are absent from this single reference and the arrangement-as-in-the-claim requirement is not met, this reference would NOT anticipate claim 11 under §102 (MPEP § 2131). At most it might be argued in a §103 combination directed to client-server request messaging, which is outside the scope of this single-reference anticipation chart. For attorney review — not a legal opinion, not a validity determination.

US5260999A — Filters in license management system vs. claim 1

Verdict: missing element(s) — no §102.

US5260999A is directed to a software license management system, not to placing purchase orders for items. At a high level of abstraction, it discloses a client/server request-response architecture in which a user sends a request that 'includ[es] an identification of the user' to a license server, which 'access[es] said store' to retrieve previously stored license-authorization information and returns a grant or refusal. That maps only partially onto the claim's 'sending a request... along with an identifier,' 'receiving the request,' and 'retrieving additional information previously stored' elements — and even then the retrieved information is a license authorization for a software product, not purchaser data used to complete a purchase. The reference is entirely silent on a client displaying information identifying an item for sale, on a 'single action' triggering the request, on generating an order to purchase an item, on fulfilling that order to complete a purchase, and on the 'without using a shopping cart ordering model' limitation. Because at minimum elements (1), (5), (6) and (7) are absent from this single reference, it does not anticipate claim 1 under §102 (MPEP § 2131); at most it could serve as a general client-server request-retrieval teaching in a §103 analysis, which is outside this anticipation chart. All partial-disclosure mappings above rely on verbatim claim language from the reference as provided; no inherency of the missing purchasing/ordering steps is established (they are not necessarily present).

US5260999A — Filters in license management system vs. claim 6

Verdict: missing element(s) — no §102.

US5260999A is a software license management system in which a user node sends a request (including 'an identification of the user and said software item') to a license server, which accesses a store of license authorizations to grant or refuse permission to use a licensed software product. Only two elements map even partially: the request's 'identification of the user' loosely reads on an identifier identifying a customer, and the request-plus-server-lookup structure loosely resembles a request including an identifier so the server can locate additional information. However, the reference is directed to authorizing software usage, not commercial purchasing, and it discloses NONE of the ordering-specific limitations: there is no display component displaying information identifying an item, no single-action ordering component triggered by only a single action, no fulfillment/completion of a purchase, and — dispositively — no shopping cart ordering component responsive to an add-to-shopping-cart action. Because multiple limitations are entirely absent from this single reference, it would not anticipate claim 6 under §102/MPEP § 2131; a §102 rejection cannot be cured by combining references. This is candidate prior-art analysis for attorney review, not a legal opinion or validity determination.

A reference is §102 prior art only if its effective date is BEFORE the target’s priority date (1997-09-12). This filter is deterministic: references dated on or after that date are excluded from every ground; references with no establishable date are flagged for manual dating and are never silently treated as prior art. For attorney review — confirm each date against the reference itself.

Qualified prior art (8)

• Conditional purchase orders — 1997-04-01T00:00:00.000Z — dated 1997-04-01T00:00:00.000Z (publication), before the target's priority date 1997-09-12 — qualifies as prior art

• Automating the small purchase solicitation cycle for non-EDI trading partners using Internet technologies — 1997-01-01T00:00:00.000Z — dated 1997-01-01T00:00:00.000Z (publication), before the target's priority date 1997-09-12 — qualifies as prior art

• US4937863A — 1990-06-26 — dated 1990-06-26 (publication), before the target's priority date 1997-09-12 — qualifies as prior art

• US5204897A — 1993-04-20 — dated 1993-04-20 (publication), before the target's priority date 1997-09-12 — qualifies as prior art

• US5260999A — 1993-11-09 — dated 1993-11-09 (publication), before the target's priority date 1997-09-12 — qualifies as prior art

• WO1995030961A1 — 1995-11-16 — dated 1995-11-16 (publication), before the target's priority date 1997-09-12 — qualifies as prior art

• WO1996038799A1 — 1996-12-05 — dated 1996-12-05 (publication), before the target's priority date 1997-09-12 — qualifies as prior art

• US5627940A — 1997-05-06 — dated 1997-05-06 (publication), before the target's priority date 1997-09-12 — qualifies as prior art

Excluded — not prior art (6)

• US8230089B2 — 2010-09-30 — dated 2010-09-30 (publication), on or after the target's priority date 1997-09-12 — NOT prior art; excluded from grounds

• US20110087533A1 — 2011-04-14 — dated 2011-04-14 (publication), on or after the target's priority date 1997-09-12 — NOT prior art; excluded from grounds

• US10410255B2 — 2013-10-03 — dated 2013-10-03 (publication), on or after the target's priority date 1997-09-12 — NOT prior art; excluded from grounds

• US12093268B2 — 2020-08-27 — dated 2020-08-27 (publication), on or after the target's priority date 1997-09-12 — NOT prior art; excluded from grounds

• TW201432595A — 2014-08-16 — dated 2014-08-16 (publication), on or after the target's priority date 1997-09-12 — NOT prior art; excluded from grounds

• US8069083B2 — 2009-02-12 — dated 2009-02-12 (publication), on or after the target's priority date 1997-09-12 — NOT prior art; excluded from grounds

Undated — verify manually (6)

• ESSAYS ON DIGITAL EXPERIENCE — no date could be established for this reference — confirm it predates the target's priority date before relying on it

• Who’s Afraid of amazon.com v. barnesandnoble.com? — no date could be established for this reference — confirm it predates the target's priority date before relying on it

• World wide web business catalogs in business-to-business procurement — no date could be established for this reference — confirm it predates the target's priority date before relying on it

• REST in Practice — no date could be established for this reference — confirm it predates the target's priority date before relying on it

• ONLINE ORDERING AND PAYMENT SYSTEM WITH SMS NOTIFICATION FOR NINA CLOTHING ACCESSORIES — no date could be established for this reference — confirm it predates the target's priority date before relying on it

• Canteen Food Ordering and Managing System — no date could be established for this reference — confirm it predates the target's priority date before relying on it

Consistency checks

Automated checks run over the grounds before assembly — heuristics for attorney review, not legal conclusions.

• ⚠ Unverified reference quotation in claim chart (US4937863A — Software licensing management system vs. claim 6): "request receiving means for receiving a usage request identifying a licensed software program; ... retrieving the con…" does not appear verbatim in the fetched reference text. Correct the quote or treat the disclosure as unverified before relying on it.