US 7257833

I'll search for authoritative information on this specific patent number.

Let me check specifically for any 2026 litigation or CAFC activity on this patent.

Let me confirm the independent claim set and check for any IPR/PGR proceedings.

US Patent 7,257,833 — Analyst Summary

Caveat on scope of search: My tooling searched the open web (Google Patents, Justia, FreePatentsOnline, PTAB petitions, CAFC opinions/orders). I could not access USPTO PatentCenter/assignment APIs or a live CAFC docket system directly, so the litigation and post-grant portions below reflect what is publicly indexed, not a certification of the full docket record.

---

Bibliographic Data

Note on assignee history: assignment records show several iPolicy Networks, Inc. records in 2002 (including a re-record correcting the fourth conveying party's name from "Shan" to "Shah"), a 2011 assignment to iPolicy Networks Private Ltd., and a 2011 assignment to Tech Mahindra Limited by merger.

---

Abstract (as issued)

"Enforcing a plurality of different policies on a stream of packets is disclosed. In lieu of running separate algorithms for each policy, the system exploits the commonalities of all of the policies. The conditions corresponding to the compiled rules are arranged in a condition tree and processed in a pipelined architecture that allows the results of the various stages to be carried forward into subsequent stages of processing. The rules for which all conditions have been satisfied can be identified by one stage of processing in one pass of condition tree traversal and are passed to subsequent stages. A rule table corresponding to an individual policy type can then be readily examined to determine partial or complete satisfaction of the rule of that policy type, without requiring a re-examination of the conditions underlying the rule. Additionally, corresponding actions can be taken where rule satisfaction is determined."

---

Independent Claims — Plain-Language Overview

I identified three independent claims in the publicly indexed claim set: claim 1 (method), claim 9 (apparatus, means-plus-function), and claim 17 (apparatus, structural/functional modules). I could not independently verify the total number of claims, so treat the three-independents figure as high-confidence but the total count as unconfirmed.

Claim 1 — Method of enforcing multiple policy types on a packet stream
A method in a packet-switched network where:

1. A packet is received and an extension is appended to it.
2. Session information about the packet is determined and written into that extension.
3. The packet is forwarded to a packet policy rule engine module.
4. That module determines whether the packet matches a common condition shared by a first policy rule (of a first policy type) and a second policy rule (of a different second policy type).
5. If so, an association between the packet and that common condition is created and the extension is updated accordingly.
6. Key limitation: communication between modules using the extension occurs without use of shared memory.

In short: appended per-packet metadata replaces shared-memory state, letting one condition check satisfy rules belonging to multiple different policy types.

Claim 9 — Apparatus (means-plus-function)
The same operation claimed for a machine, expressed in means-plus-function format: means for receiving the packet; means for appending the extension; means for determining and updating session information; means for forwarding to the policy rule engine module; means for determining whether the packet matches a common condition across first and second policy rules of differing policy types; and means for associating the packet with that common condition (with the extension-based, no-shared-memory communication limitation).

Claim 17 — Apparatus (module-based)
An apparatus described as cooperating functional modules forming a pipeline:

• an extension builder module that receives the packet, appends the extension, and forwards to a session manager;
• a session manager module that determines session information, updates the extension, and forwards to an application decode engine;
• an application decode engine module that determines whether the packet corresponds to an application rule, updates the extension with application information, and forwards to the packet policy rule engine; and
• a packet policy rule engine module that determines the cross-policy-type common condition, creates the association, and updates the extension — again with the no-shared-memory limitation on inter-module communication via the extension.

Dependent claims cited in the public record indicate the policy types are typically firewall and quality-of-service, and more generally drawn from firewall, QoS, and intrusion detection (e.g., claims 3, 4, 11, 12, 18, 19). Other dependents add rule-tree traversal for determining rule applicability (claims 5–6), and module-specific realizations of the extension-builder/session-manager functions (claims 7–8, 15–16).

---

Litigation / CAFC 2026 Status

No CAFC 2026 appeal or docket activity tying US 7,257,833 to a case number was found. Targeted searches for "7257833" combined with Federal Circuit / 2026 / IPR / PTAB returned no hits; a search for cross-references between this patent and 2026 CAFC opinions likewise returned nothing.

Uncertainty disclosure: Because I could not query PACER/CourtListener dockets or the PTAB API directly, I cannot affirmatively state that no 2026 district-court or PTAB proceeding exists — only that none surfaced in indexed web results. The patent is listed on Google Patents as Expired – Fee Related with an adjusted expiration of Jan. 25, 2024, which would generally make it a less likely candidate for active 2026 enforcement, but that legal-status field is expressly an assumption and not a legal conclusion.

Where this patent does appear in the record: It is cited as prior art (category "I") in the European search report for EP 2760158 A4 ("Policy processing method and network device," Huawei-origin family WO 2014085952A1), and it appears as a cited reference in later firewall/policy-enforcement patents (e.g., US 11,431,677). This is consistent with its role as an early foundational reference in the "mixed-orchestration / one-pass policy matching" art.

---

If you need higher assurance

To close the gaps I flagged, the authoritative next steps would be: (1) USPTO PatentCenter / Assignment for application 10/052,745 to confirm the full assignment chain and any terminal disclaimer; (2) the USPTO Patent Public Search claim listing to confirm the exact claim count and every independent claim; and (3) PACER/CourtListener docket and PTAB API queries under the patent number and assignees (Tech Mahindra, iPolicy Networks) for any 2026 activity. If you can supply those source documents, I will incorporate them and revise the litigation section accordingly.

I'll research litigation involving US patent 7257833 across patent litigation databases.

Let me dig into specific litigation databases.

Let me search more targeted litigation sources and the patent's assignee history.

Litigation Search: US Patent 7,257,833

Bottom line

No litigation involving US Patent 7,257,833 was identified in my searches. I could not locate any filed lawsuit — district court, ITC, or Federal Circuit appeal — in which US 7,257,833 was asserted as a patent-in-suit or otherwise adjudicated. I am reporting this as a negative finding based on the searches I was able to run, subject to the caveats below.

Patent identification (to avoid number confusion)

I confirmed the patent literally matches the number you gave — US 7,257,833 B1, "Architecture for an integrated policy enforcement system":

Note on the assignment chain (relevant to who could have asserted it): iPolicy Networks, Inc. → iPolicy Networks Private Ltd. (2011-02-07) → Tech Mahindra Limited (2011-02-14, via merger). The patent is now expired, which materially limits the possibility of current infringement litigation (though it would not have precluded past suits filed before expiration).

Sources searched and what they showed

• General web searches for "7257833" combined with "litigation," "lawsuit," "docket," "case," and "court" returned no case naming this patent. Results were dominated by (a) the patent's own Google Patents/Justia/PDF pages, (b) a Brazilian corporate-registry document that coincidentally contains the unrelated string "7257833" as a registration number, and (c) unrelated PTAB proceedings (e.g., IPR2021-01413, IPR2019-00635, CBM2013-00021) involving entirely different patents such as US 10,621,228; US 5,966,440; US 8,767,824; US 7,792,256. None of these concern US 7,257,833.
• Unified Patents litigation/PTAB portal and Docket Alarm results that surfaced referenced other patents and other parties, not this patent.
• I did not obtain a direct hit on the Google Patents "Litigation" tab, a PACER docket, or a CAFC docket for US 7,257,833.

Important caveats — please read before relying on this

1. I could not complete an exhaustive search. I was cut off by a step/tool limit before exhausting the specific databases you named. A negative result here is suggestive, not conclusive.
2. Non-practicing-entity (NPE) assertion is unlikely but not impossible. iPolicy Networks appears to have been an operating company (it marketed the "ipEnforcer 5000®" product per the specification), which typically produces defensive/portfolio patents rather than assertion campaigns. Its successor, Tech Mahindra, is a large IT services firm — also not a known patent-assertion entity. This is consistent with, but does not prove, the absence of litigation.
3. Related-family patents may have their own histories. This patent shares a specification family with US 7,120,144 ("Universal Application Decode Engine"), US 7,058,821 ("System and Method for Detection of Intrusion Attacks…"), US 7,139,837, US 7,203,744, and US 7,321,556 (rule compiler / rule engine patents by the same inventors/assignee). If you are assessing litigation exposure for this family, those should be searched separately — but note that litigation on a sibling patent would not be litigation on US 7,257,833 itself, and I did not find sibling-patent suits either.

Recommended next steps to get a definitive answer

To confirm the negative finding with authoritative sources, I would recommend checking directly:

• Unified Patents Litigation Portal — https://portal.unifiedpatents.com/litigation/caselist (search by patent number 7257833)
• PACER Case Locator — https://pcl.uscourts.gov (party search for "iPolicy Networks" and "Tech Mahindra")
• USPTO Patent Center / Assignment records for US 10/052,745 — to confirm the assignment chain and flag any recorded security interests or licenses that often accompany litigation
• Free Law Project / CourtListener RECAP and Justia Dockets — keyword searches for the patent number
• Lexis CourtLink / Westlaw KeyCite on "US PAT 7257833" — the tool the USPTO itself uses for its litigation search reports

If you want, I can run a second, more targeted pass against those specific portals (patent-number queries on the Unified Patents litigation caselist and CourtListener) to strengthen or overturn this negative finding.

I'll research whether any AIA trial proceedings exist on US 7,257,833.

Proceedings overview

Zero AIA trial proceedings on file. The USPTO Open Data Portal structured block returns no IPR, PGR, or CBM for US 7,257,833, and targeted web searches (Google Patents, PTAB E2E document hits, Docket Alarm, general docket chatter) surfaced no petition ever filed against this patent. The breakdown by status is therefore empty: 0 active / 0 claims invalidated / 0 claims sustained / 0 settled / 0 institution denied. The defensive posture this gives a defendant is unusual for an asserted networking patent — there is no PTAB record to cite, but also no IPR estoppel and no claim-cancellation ammunition. The patent's own status, however, is the bigger story: it is Expired – Fee Related (adjusted expiration 2024-01-25), so any 2026 assertion is a backward-looking damages play only, and the validity fight — if one is ever joined — would be a first-instance fight you would have to start yourself.

(No proceedings to report)

I found no proceeding number, petitioner, or Final Written Decision to populate the per-proceeding template. Consistent with the constraints, I am not inventing one. Two search hits looked superficially relevant and were checked and rejected as false positives:

• A PTAB exhibit captioned "Denying Institution PTAB IPR2017-00649 … 7 833" — the trailing "833" is a different patent (a number ending in …,833), not US 7,257,833. (Docket-sheet hit, Samsung v. … , PGR2026-00001 exhibit list: https://gaeflexstaging-dot-docketupdate.appspot.com/cases/PTAB/PGR2026-00001/Samsung_Electronics_Co._Ltd/11-07-2025-Petitioner/Exhibit-1019-EX1019___Denying_Institution_PTAB_IPR2017_00649_7_833/)
• A Florida docket referencing PayRange's U.S. Patent No. 10,719,833 — a different patent, different field (mobile payments). (https://www.docketalarm.com/cases/Florida_Southern_District_Court/1--20-cv-24342/)

A third "7257833" hit is a trademark registration number (RD Riggs Distler), not a patent proceeding.

Strategic summary

Which claims are canceled vs. sustained vs. untested. Because no AIA trial ever reached a Final Written Decision, no claim of US 7,257,833 has been canceled, and no claim has been adjudicated sustained by the PTAB. Under 35 U.S.C. § 318(b)-(c), the only way a patent claim is canceled via IPR is an FWD that finds it unpatentable (or a disclaimer/amendment) — none exists here. Every claim — the independent claims and their dependents (e.g., the packet-extension, rule-tree, and pipelined-policy claims described in the specification and illustrated in Table 1.0 / FIGS. 9A-10) — is UNTESTED at the PTAB. That cuts both ways for a defendant: the claims retain their full issued scope, but they also carry no hardened, validated status. There is no "claims 1-5 canceled" argument available because there is nothing to cite.

Estoppel landscape. § 315(e)(2) applies only to a petitioner that obtains an FWD — and there has been none, so no party is estopped from raising any prior-art ground against this patent in district court or before the Office. Concretely: any § 102/§ 103 ground you can find based on patents or printed publications is still fully available to you (subject to §§ 315(b)/325(b) time bars and the fact that the patent's 2001 priority date limits the qualifying-art universe). There is also no § 325(e) PGR estoppel and no CBM estoppel. You are starting from a clean slate.

Pattern signals. There is no petitioner pattern — no repeat filer, no serial petitions, no joinder, and no defensive aggregator (no Unified Patents, no RPX IPR) in the chain. The ownership chain is the ordinary corporate one: invented at iPolicy Networks, Inc. (Fremont, CA) → assigned to iPolicy Networks Private Ltd. (2011-02-07) → Tech Mahindra Limited via merger (2011-02-14), which is the current listed assignee. That is a practicing-company / IT-services lineage, not an NPE, and iPolicy/Tech Mahindra does not appear to have run an IPR-assertion campaign on this family — which is consistent with the total absence of PTAB activity. Related iPolicy enforcement patents in the same family (e.g., US 7,058,821, US 7,120,144, US 7,139,837, US 7,203,744, US 7,321,556) likewise show no IPR activity in my searches.

One framing caveat the prompt flags and I want to be explicit about: the absence of PTAB activity is weak evidence in either direction here. This is a 2001-priority, 2007-issued patent that is now expired (adjusted expiration 2024-01-25) and is held by a large operating company, not a litigation monetizer. Expired patents with no live assertion campaigns rarely attract IPRs — so "no IPRs" here signals "not actively asserted," not "immune to challenge."

Recommended next steps

• Treat this as a no-PTAB-record patent, and plan the validity defense from scratch if you are threatened. There is no FWD to link to and no canceled claim to quote.
• Lead with expiration. The patent is recorded Expired – Fee Related with an adjusted expiration of 2024-01-25. If you receive a demand letter in 2026 asserting ongoing or future infringement, that is facially inconsistent with the term — flag it immediately. Any viable case would be limited to past damages within the § 286 six-year lookback (i.e., from late 2019/2020 forward) and cannot support injunctive relief or forward-looking royalties. Confirm the exact expiration computation (filing 2002-01-17; priority 2001-01-17; any PTA/terminal disclaimer) against the face of the patent and the assignment record.
• If you decide to institute a validity challenge, note the practical gate: IPR (§§ 311-319) is available for any patent and requires only patents/printed publications on § 102/§ 103 grounds, with a 12-month statutory trial deadline from institution and a § 315(b) one-year bar from service of an infringement complaint. PGR is not available — PGR reaches only patents subject to first-inventor-to-file (effective on/after 2018-03-16, i.e., issuing on/after 2013-03-16), and this patent predates that. CBM is unavailable — its program sunset for new petitions (2020-09-16) and the claims are a network-security enforcement architecture, not a financial-services business method. So your only AIA route is an IPR, or an ex parte reexamination (§ 302 et seq.), which is untimed, anonymous, and often the better tool against an expired patent where the goal is invalidating claims rather than staying litigation.
• Preserve prior-art rights now. Because there is no estoppel and no PTAB record, you are not boxed in — but if you file an IPR and get an FWD, § 315(e)(2) will foreclose grounds you raised or reasonably could have raised, so assemble the full § 102/§ 103 picture (including references cited during original prosecution) before choosing grounds, rather than iterating.
• Verify the negative independently before relying on it. Google Patents, Docket Alarm, and USPTO PTAB E2E document searches returned nothing, and the ODP ingest reports no AIA proceedings; if the stakes are high, run the patent number directly through PTAB E2E / the Patent Trial and Appeal Board's "Patent Trial and Appeal Board End-to-End" search and the PTAB Decisions site to confirm, since a very recent filing could fall outside the ODP ingest window.

Caveats on sourcing. My conclusion rests on (1) the structured ODP block stating no AIA proceedings, and (2) web searches that produced no proceeding number, petitioner, FWD, or appeal tied to US 7,257,833. I could not locate a PTAB FWD, a CAFC docket, or a settlement to cite because none appears to exist. If you have a specific proceeding number you believe exists, provide it and I will pull the record — but I will not manufacture one.

I'll research the assignment chain for US 7,257,833. Let me start with targeted searches.

Let me try more targeted queries for the assignment records and the iPolicy corporate history.

Let me dig into the acquisition history and try to retrieve the assignment reel/frame records.

Assignment Record Reconstruction — US 7,257,833 B1

Important sourcing note up front. I reached my tool/step limit before I could query the USPTO Assignment Center interface directly (assignmentcenter.uspto.gov is a JavaScript application that does not expose individual records to plain web search). The assignment events and dates below are drawn from the Google Patents "Legal Events" chronology for US 7,257,833, which mirrors the USPTO assignment record. Only one reel/frame pair was textually recoverable (012930/0993); I did not recover the reel/frame numbers for the two 2011 records and I did not recover any correspondent-of-record data. I have marked those fields "not captured" rather than guessing. Everything else is grounded in the sources cited.

---

Inventors

All four are listed as assignors to iPolicy Networks, Inc. in the 2002-05-29 record (Reel 012930/Frame 0993), which is the standard evidence of employment-at-filing for a startup portfolio.

Unusual patterns: None detected. This is a founder-led portfolio: Pankaj Parekh is publicly identified as iPolicy's founder and was still with the company through its 2003 recapitalization (SiliconIndia profile, "The Policy Man Returns," June 2004), so there is no signal of the "all inventors depart within 12 months → fire-sale" pattern. Sandeep Gupta, Vijay Mamtani, Puneet Tutliani and Proneet Biswas appear as co-inventors on the siblings (US 7,139,837; US 7,203,744), i.e., a stable in-house team, not a one-off sale vehicle.

---

Original assignee

iPolicy Networks, Inc. (47467 Fremont Boulevard, Fremont, CA 94538) — named on the face of the patent.

• Product embodying the claims: Yes. The specification itself names the ipEnforcer 5000®; it was a commercial "Intrusion Prevention Firewall" appliance. The Tolly Group benchmark #202144 (January 2002) independently validated the ipEnforcer 5000 at 2 Gbit/s full-duplex with firewall + IDS + URL filtering running concurrently — precisely the "single pass / pipelined policy enforcement" that claim 1 describes. The product family later expanded to the iPolicy 2000 / 3000 / 4000 / 6000 series (iPolicy press release, Aug 30, 2004).
• Primary line of business: Integrated network security appliances for carriers and enterprises (firewall, IDS/IPS, VPN, QoS, load balancing, URL filtering).
• Corporate history: Officially formed February 2000 by the merger of TunnelNet Inc. (US) and Duet Technologies (India — Prabhu Goel's company) per Light Reading (June 25, 2001); CB Insights dates the founding to 1997 and reports ~$69M raised, with investors including Morgan Stanley Venture Partners, Greylock Partners, Technology Crossover Ventures, Clearstone Venture Partners, Keynote Ventures, WK Technology Fund, IGNITE Group, and Tech Mahindra.
• Current status: Acquired. iPolicy's business was absorbed by Tech Mahindra; the US entity no longer operates under the iPolicy name. Contradiction to flag: the Tolly Group note states "the company was acquired by Tech Mahindra in early 2007," whereas the recorded US assignment of this patent did not occur until February 2011 (via the Indian entity, see below), and CB Insights lists Tech Mahindra only as an investor. The most likely reconciliation is that Tech Mahindra bought the business/assets circa 2007 while the patent title was papered through the Indian affiliate and the 2008 Delhi High Court amalgamation scheme (iPolicy Networks Ltd. + Tech Mahindra (R&D Services) Ltd. → Tech Mahindra Ltd.). This discrepancy is unresolved and should be verified against the Assignment Center abstracts.

---

Assignment timeline

Dates below are the recording dates surfaced by the Google Patents Legal Events feed. Execution dates are not captured for any link.

• executed [not captured] / recorded 2002-05-29 — Reel 012930 / Frame 0993

  • Conveyance: Assignment ("Assignment of Assignors' Interest — see document for details")
  • Assignor: Pranav Shan (later corrected); Vimal Vaidya; Sandeep Gupta; Pankaj Parekh
  • Assignee: iPolicy Networks, Inc.
  • Correspondent: not captured — could not retrieve; the Assignment Center record would name the filing attorney (worth re-checking).
  • Context: initial formation/employment assignment — inventors convey application rights to the operating company before grant.

• executed [not captured] / recorded 2002-08-27 — Reel/Frame not captured (document itself re-references previously-recorded Reel 012930 / Frame 0993)

  • Conveyance: Correction / Re-recordation — "Re-record to correct last conveying party's name"
  • Assignor: Pranav Shah; Vimal Vaidya; Sandeep Gupta; Pankaj S. Parekh
  • Assignee: iPolicy Networks, Inc.
  • Correspondent: not captured
  • Context: correction only — fixes "SHAN, PRANAV" → "SHAH, PRANAV" and adds the middle initial to Parekh.

• executed [not captured] / recorded 2002-09-30 — Reel/Frame not captured (again re-references Reel 012930 / Frame 0993)

  • Conveyance: Correction / Re-recordation — "Re-record to correct the 4th conveying party's name"
  • Assignor: Pranav Shah; Vimal Vaidya; Sandeep Gupta; Pankaj S. Parekh
  • Assignee: iPolicy Networks, Inc.
  • Correspondent: not captured
  • Context: correction only — a second attempted fix of the same recorded instrument; three recordings all keyed to the same Reel 012930/0993.

• executed [not captured] / recorded 2011-02-07 — Reel/Frame not captured

  • Conveyance: Assignment (Assignment of Assignors' Interest)
  • Assignor: iPolicy Networks, Inc.
  • Assignee: iPolicy Networks Private Ltd.
  • Correspondent: not captured
  • Context: internal reorganization — US parent transfers title to its Indian affiliate, part of the years-long restructuring around the Tech Mahindra relationship.

• executed [not captured] / recorded 2011-02-14 — Reel/Frame not captured

  • Conveyance: Merger
  • Assignor: iPolicy Networks Private Ltd.
  • Assignee: Tech Mahindra Limited
  • Correspondent: not captured
  • Context: statutory amalgamation — matches the Delhi High Court Scheme of Amalgamation (iPolicy Networks Ltd. and Tech Mahindra (R&D Services) Ltd. into Tech Mahindra Ltd.); title vests in the transferee by operation of the merger.

Non-assignment legal events (for completeness): 2007-08-14 patent granted; 2024-01-25 adjusted expiration; status Expired – Fee Related (expiration adjusted to 2024-01-25).

Family note: siblings US 7,120,144; US 7,058,821; US 7,139,837; US 7,203,744; US 7,321,556 share the same inventors/assignee and almost certainly the same iPolicy → iPolicy Networks Private Ltd. → Tech Mahindra chain, but their reel/frame entries were not verified here.

---

Timeline diagram

timeline
    title Ownership of US 7257833
    2000 : iPolicy Networks formed
    2001 : Provisional filed 17 Jan
    2002 : Nonprovisional filed 17 Jan
         : Inventors assign to iPolicy Networks Inc
         : Two name corrections re-recorded
    2007 : Patent issued 14 Aug
    2011 : Title to iPolicy Networks Private Ltd
         : Merged into Tech Mahindra Limited
    2024 : Patent expired fee related

---

NPE / troll-pattern signals

1. Shell-entity transfer — NOT PRESENT. The chain terminates at Tech Mahindra Limited, a publicly listed Indian IT-services major (NSE/BSE), not an "IP/Licensing/Holdings/Ventures" LLC. The intermediate iPolicy Networks Private Ltd. is a corporate affiliate/operating subsidiary, not a single-purpose Delaware/Texas entity (Reels 2011-02-07 and 2011-02-14; assignment chain per Google Patents legal events).

2. Known asserter in the chain — NOT PRESENT. No assignee in the chain (iPolicy Networks, Inc.; iPolicy Networks Private Ltd.; Tech Mahindra Ltd.) matches any public NPE/asserter list I am aware of — none of Acacia, Marathon, Intellectual Ventures, IPNav, Wi-LAN, Conversant/Mosaid, Vringo, Pendrell, MPHJ, Round Rock, etc. The assignees are/were operating companies.

3. Repeat correspondent across the chain — UNCLEAR / not verifiable here. I could not retrieve the correspondent-of-record for any link (the Google Patents feed does not surface correspondents, and the Assignment Center only exposes them in its JS UI). There is an internal recurrence signal — three recordings in 2002 all keyed to Reel 012930/0993 — but that only shows the same instrument being corrected twice, not a repeat NPE lawyer. Do not treat as a finding until the correspondents are pulled.

4. Cascading transfers — NOT PRESENT. Only two post-issuance transfers exist, and while they are 7 days apart (2011-02-07 → 2011-02-14), they are a parent→affiliate assignment followed by a statutory merger into a listed public company — a classic internal reorganization, not chained anonymous LLCs.

5. Pre-litigation transfer — NOT PRESENT. No infringement suit naming this patent was identified in the litigation pass, so no assignment can sit within 6 months of a first filing.

6. Bankruptcy fire-sale — NOT PRESENT / unclear. iPolicy was recapitalized (Prabhu Goel's 2003 intervention; Parekh reportedly sold his house to fund the company) and later sold/merged into Tech Mahindra. No Chapter 7/11 or court-supervised patent sale is evidenced. This is a strategic/venture-workout transfer, not a bankruptcy sale.

7. Privateering — NOT PRESENT. No SEC filing, EFF/Patent Progress article, or asserter-directory entry indicates Tech Mahindra (or iPolicy) funded an NPE to assert this portfolio.

8. Defensive aggregator — NOT PRESENT. The chain does not terminate at RPX, AST, LOT Network, Unified Patents, or OIN. However, the practical effect is the same: the patent is expired (fee-related, 2024-01-25) and, as far as searches show, never asserted.

---

Verdict

Defensive / non-asserting.

The chain is short, clean and entirely corporate: inventors → iPolicy Networks, Inc. (Reel 012930/Frame 0993, recorded 2002-05-29, plus two name-correction re-recordings in 2002) → iPolicy Networks Private Ltd. (recorded 2011-02-07) → Tech Mahindra Limited by merger (recorded 2011-02-14). Every assignee is an operating company; none is an NPE or on an asserter list, and no suit naming US 7,257,833 was found. With the patent now expired for fee reasons (2024-01-25), the portfolio is commercially neutralized. Caveat: I could not independently verify the 2011 reel/frame numbers or any correspondent-of-record, so this verdict rests on the event/dates chronology rather than full abstracts — if the correspondents matter for your NPE screen, they still need to be pulled.

Verify at: https://assignmentcenter.uspto.gov/ (search "7257833") — or the legacy mirror https://assignment.uspto.gov/patent/index.html. Recommended cross-checks: Unified Patents litigation portal, CourtListener/RECAP, and Tech Mahindra's annual reports (the Delhi High Court amalgamation should be reflected in the FY2008–FY2011 filings).

I'll research the prior art citations for US Patent 7,257,833, focusing on the specific references cited on its face and in its prosecution history.

Let me get the specific cited references from the patent's front page.

I've found the core cited references. Let me verify the complete "References Cited" list from the patent front page and confirm details of each reference.

Prior Art Analysis — US Patent 7,257,833 B1

Status of this search: I confirmed the exact patent (US 7,257,833 B1, "Architecture for an integrated policy enforcement system," App. 10/052,745), not a similar number, via the patent's front-page image (patentimages.storage.googleapis.com/.../US7257833.pdf), Justia, and FreePatentsOnline. I hit my tool/step ceiling before I could load the USPTO Patent Public Search or PatentCenter file wrapper directly, so the reference list below is drawn from those three sources, which agree with each other. No foreign patent documents and no non-patent literature ("Other References") appear in the sources I retrieved — but I flag that I could not open the raw USPTO IFW to certify that absence.

---

1. The complete face-of-patent citation list

The "[56] References Cited" section of US 7,257,833 lists exactly two prior-art references — both U.S. Patent Documents, and both marked "cited by examiner":

This matches the Justia "Referenced Cited" table verbatim (https://patents.justia.com/patent/7257833), and the OCR of the granted PDF reads: "6,075,798 A * 6/2000 Lyons et al. ...... 370/474"; "6,587,466 B1 7/2003 Bhattacharya et al. . 370/395.21"; "* cited by examiner."*

⚠️ Verification caveat: I could not pull the full title/abstract text of either reference within my search budget. The two entries above are reliably transcribed (number, date, inventor, class, examiner-cited status), but the subject-matter descriptions below are inferred from classification and context and should be confirmed against each reference's own specification. I will not assert their titles as fact.

---

2. Per-reference analysis

Reference 1 — US 6,075,798 A (Lyons et al.)

• Full citation: US 6,075,798 A, "Lyons et al.," issued June 2000 (justia: 2000-06-13). US Class 370/474.

• Date: Issued June 2000 — i.e., more than one year before the Jan. 17, 2002 filing date (and before the Jan. 17, 2001 provisional), placing it squarely in § 102(b) territory as a printed publication/patent.

• Brief description (tentative): A multiplex-communications/switching-area patent (US class 370/474). The examiner's citation in a policy-enforcement case is consistent with it being relied upon for packet-level data handling / interface or header-processing structure — i.e., the "plumbing" side of the disclosure (receiving a packet, maintaining per-packet state), not for cross-policy rule matching.

• Potential § 102 anticipation: Realistically cited against the packet-receipt / packet-forwarding steps. It could, at most, be argued against:

  • Claim 1 — only the "receiving a packet in a packet-switched network" and possibly the "forwarding the packet" steps.
  • Claim 9 — the "means for receiving a packet" element.
  • Claim 17 — the extension-builder's "receive a packet … and forward" function.

  It is very unlikely to anticipate any independent claim as a whole, because none of the two references is expected to disclose the claimed combination: (a) appending a per-packet extension carrying session information, and (b) a packet policy rule engine that finds a common condition shared by a first policy rule of one policy type and a second policy rule of a different policy type, with (c) communication "without use of shared memory."

Reference 2 — US 6,587,466 B1 (Bhattacharya et al.)

• Full citation: US 6,587,466 B1, "Bhattacharya et al.," issued July 2003 (justia: 2003-07-01). US Class 370/395.21.
• Date: Issued after the Jan. 17, 2002 filing date of US 7,257,833, so it cannot be § 102(a)/(b) art by its issue date; it is potentially available only as § 102(e) art (a U.S. patent granted on an application filed before the applicant's inventive date). Its class (370/395.21, an ATM/network-switching subclass) confirms it is an early-filed switching/forwarding application.
• Brief description (tentative): An ATM/network-switching reference (class 370/395.21). Again, the examiner's use is consistent with relying on it for packet-switching/forwarding mechanics or data-structure handling, not for integrated multi-policy rule evaluation.
• Potential § 102 anticipation: Same posture as Reference 1 — plausible only for isolated limitations (packet reception, forwarding, per-packet state/queueing), and not for the distinguishing limitations of claims 1, 9, 17, or 22. As § 102(e) art it would more plausibly have supported a § 103 combination with another reference than a standalone § 102 anticipation.

---

3. Bottom line on the cited art

• The entire examiner-cited prior-art set is two patents, both in networking/switching classes (370/…), neither of which is directed to integrated, cross-policy-type rule evaluation.
• The novelty-defining limitations of the independent claims — the packet extension carrying session info, the "common condition" spanning two different policy types, and especially inter-module communication via the extension "without use of shared memory" — are not evidently disclosed by either reference.
• Consequently, my assessment is that neither cited reference anticipates (under § 102) any of the independent claims as a whole. They were almost certainly relied upon (and distinguished from) at the component level, and the application was allowed over them. This is consistent with the patent issuing without the examiner having found a clean § 102 reference.

Important: a rigorous § 102 conclusion requires a limitation-by-limitation comparison against the actual text and figures of US 6,075,798 and US 6,587,466. Because I could not retrieve their full disclosures, the anticipation statements above are element-level assessments, not certified anticipation findings.

---

4. Contradiction flagged with the previously generated summary

The earlier summary section stated there are three independent claims (1, 9, 17). The full claim listing retrieved from Justia shows a fourth independent claim — claim 22 ("A program storage device readable by a machine, embodying a program of instructions…"). So the correct independent-claim picture is 1, 9, 17, and 22 (method; means-plus-function apparatus; module-based apparatus; and Beauregard-style program-storage-device claim). This materially broadens the § 102 surface: each independent claim is a separate anticipation target. Total claims run to at least 22.

This does not change the prior-art conclusion, but the previously generated "three independents" figure should be corrected to four.

---

5. References that are NOT § 102 prior art for US 7,257,833 (but are easy to confuse)

• Sibling/family patents incorporated by reference in the specification:

  • US 7,120,144 ("Universal Application Decode Engine," App. 09/956,394, filed Sep. 18, 2001).
  • US 7,058,821 ("System and Method for Detection of Intrusion Attacks…," App. 10/052,328, filed Jan. 17, 2002 — same day as 7,257,833).
  • Also in the same iPolicy/Parekh family: US 7,203,744 and US 7,321,556 (rule compiler/rule engine).

  Why they are not prior art: they are commonly owned by the same assignee with overlapping inventorship, and the copending one (10/052,328) was filed the same day. Even where a copending application could theoretically be § 102(e) art, the § 103(c) common-ownership exception and/or the provisional priority (Jan. 17, 2001) defeat a prior-art characterization. The provisional 60/262,275 is the priority document, not prior art.

• Forward citations (patents citing 7,257,833) are the opposite direction and are therefore not prior art against it. Notable ones surfaced:

  • US 11,489,720 B1 (VMware) — cites US 7,257,833 in its family-cites.
  • US 10,972,413 — lists "7257833 … Parekh et al." in its referenced-cited table.
  • KR 10-2014-0098671 A family and EP 2,760,158 A4 (Huawei-origin, WO 2014/085952) both cite US 7,257,833 as a reference; in the EP 2,760,158 A4 search report it is cited as category [I] alongside the sibling US 7,058,821 [I] (data.epo.org/gpi/EP2760158A4).

  These are useful market/family context and show 7,257,833 functioning as a foundational "one-pass, mixed-policy matching" reference — but they are not § 102 art.

---

6. Recommended next steps to harden this analysis

1. USPTO Patent Public Search / PatentCenter for App. 10/052,745 → open the Image File Wrapper to read the examiner's actual § 102/§ 103 rejections and the applicant's remarks; this reveals which reference was used against which claim and whether any reference was withdrawn.
2. Retrieve the full text of US 6,075,798 and US 6,587,466 (title, abstract, claims, filing/priority dates) to convert my element-level assessment into a proper limitation-by-limitation § 102 comparison — in particular to test whether either discloses a packet extension or cross-policy-type common condition.
3. Confirm the absence of foreign/NPL references on the face (none appeared in the sources I could reach).

If you can supply the IFW or the two references' full texts, I will revise the § 102 mapping accordingly.

I'll research the prior art landscape for this patent before building the § 103 analysis.

Obviousness Analysis — US 7,257,833 B1 under 35 U.S.C. § 103

Caveat up front (important): I was unable to retrieve the patent's own "References Cited (42)" list — my tooling hit its step limit before I could pull the citation table from the Google Patents / Justia page. The # Prior Art section that this task says to build on is not in the text supplied to me, so I am reconstructing the prior-art landscape from (a) the patent's own admitted prior art in its Background, (b) the well-known contemporaneous art in this field, and (c) references I could confirm in indexed results. Where I am not fully confident of a bibliographic detail (e.g., an exact patent number), I say so rather than filling it in. Treat all reference teachings below as candidate grounds to be verified against the actual file wrapper and cited-art list, not as a certified record.

---

1. Legal framework applied

The application has an effective priority date of January 17, 2001 (Prov. 60/262,275) and was filed January 17, 2002, so it is governed by pre-AIA § 103(a). The analysis therefore uses the Graham v. John Deere factors — scope and content of the prior art, differences between the prior art and the claims, level of ordinary skill, and secondary considerations — as refined by KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007) (for the proposition that combinations of known elements to achieve predictable results are obvious, and that a "motivation to combine" may be found in design incentives, market pressure, and the finite number of identified, predictable solutions).

Level of ordinary skill: a person with a B.S. in EE/CS plus ~2–5 years in network equipment design (packet classification, firewalls, QoS, or network-processor programming), or equivalent. This is a mature, fast-moving engineering art where combining known packet-processing building blocks was routine.

The critical date is effectively January 17, 2001 (one year before the U.S. filing date). References published or in public use before that date are § 102(b) art; § 102(e) art must have been filed before that date.

---

2. Elements to be mapped (from the independent claims)

From the previously generated claim overview, the three independents break down as:

Dependents add: policy types = FW and QoS (claims 3, 4, 11, 12, 18, 19), rule-tree traversal for applicability (claims 5–6), and module-specific realizations (claims 7–8, 15–16).

Two limitations carry the patentable weight and must be attacked directly:

1. Cross-policy "common condition" matching — one condition check serving rules of different policy types.
2. "Without the use of shared memory" — the extension appended to the packet is the inter-module transport, replacing shared state.

Everything else (receive, parse, session tracking, application decode, per-policy action) was squarely in the art.

---

3. Candidate prior art references and what they teach

(a) Admitted prior art in the patent's own Background — usable as § 102(b) art

The specification itself concedes the state of the art at column-level ("Description of the Related Art"):

• "FIREWALL™ from Checkpoint Software Technologies LTD" and ISS intrusion detection systems as standalone policy engines. Google Patents full text: https://patents.google.com/patent/US7257833/en (Background; also reflected in the "Definitions" list: FW, LB, QoS, IDS).
• Switches integrating "Firewall (FW), Load Balancing (LB) or Quality of Service (QoS) capabilities."
• Routers integrating "additional IP service functionalities" for policy decisions.

This admission establishes that each individual policy type (FW, QoS, LB, IDS) was independently known, and that integrating several of them into one device was an express design goal. That is half of the motivation-to-combine case handed over by the applicant.

(b) US 5,835,726 (Shwed et al.) — Check Point Software

"System and method for controlling access to network resources" (issued Nov. 10, 1998). I confirmed this reference is treated as core, well-known firewall prior art in the field (it appears on a defendant's prior-art identification list in the Keysight/Centripetal matter: see docket-alarm-hosted identification-of-prior-art document surfaced in results).

Teaches: a single inspection engine that applies a set of access-control rules to packets, with per-connection state tables (stateful inspection) so that later packets in a connection are evaluated using information derived from earlier packets, and multiple security functions (inspection, logging, NAT, encryption) layered in one box. This maps to the session-manager function and to the notion of one engine enforcing many rules — but it does not teach the packet-extension transport or the cross-policy common-condition merging.

(c) Multi-dimensional packet classification / decision-tree literature

• T.V. Lakshman and D. Stiliadis, "High-Speed Policy-Based Packet Forwarding Using Efficient Multi-Dimensional Range Matching," SIGCOMM 1998 — packet classification in a small number of memory accesses; supports the single-pass, multi-field rule matching idea.
• P. Gupta and N. McKeown, "Packet Classification on Multiple Fields," SIGCOMM 1999 (and "Classifying Packets with Hierarchical Intelligent Cuttings," IEEE Micro 2000) — explicit decision-tree / hierarchical-cut classification that shares prefix tests across many rules so a condition is evaluated once and reused for many rules.

Teaches: the rule-tree / condition-tree structure and the evaluate-once, reuse-for-many-rules principle that the patent's claim 5–6 dependents and the "common condition" limitation rely on.

(d) Network-processor pipeline art (1999–2000)

The contemporaneous NPU generation — Intel IXP1200 (1999), Motorola C-Port C-5 (1999), Agere/Lucent PayloadPlus (2000) — is built on exactly this pattern: a pipelin
e of stages that pass a packet plus a per-packet descriptor/metadata ("context") from stage to stage so each stage reuses earlier-derived fields instead of re-parsing. I am not asserting a specific patent number here — I could not verify one within tool limits — but this class of art is the natural primary reference for combining (i) packet + (ii) carried-forward metadata + (iii) off-the-shelf/multi-stage hardware.

(e) QoS / bandwidth allocation

US 6,041,039 ("System and method for determining network bandwidth availability using priority level feedback") appeared in results and is a real QoS/bandwidth reference, but it is ATM ABR/NBR-oriented and therefore a weak mapping to the claim's "QoS policy" element. A better QoS ground would be a packet-based QoS/scheduling reference (e.g., the fair-queuing/priority-scheduling art of the same era); I flag this as needing substitution during a real challenge.

(f) The related-family applications are not prior art

The specification incorporates App. 09/956,394 (now US 7,120,144, "Universal Application Decode Engine," filed Sept. 18, 2001) and App. 10/052,328 (now US 7,058,821, filed Jan. 17, 2002). Both were filed after the '833 January 17, 2001 priority date, so they are not § 102(e) prior art against the '833. Any obviousness ground must rely on genuinely earlier art, not on the inventors' own later-filed siblings.

---

4. Proposed obviousness combinations

Ground 1 — Shwed '726 + packet-classification decision-tree art + an NPU pipeline reference

The combination: Shwed supplies a single rule-driven inspection engine enforcing multiple access rules with per-connection state. The Gupta/McKeown (or Lakshman/Stiliadis) classification art supplies compiling many expressions into a shared decision/condition tree in which a condition is tested once and its result carried for all rules depending on it — i.e., the recited "common condition" of first- and second-policy-type rules. The NPU-pipeline art supplies the appended per-packet metadata ("extension") carried between pipeline stages and the multi-stage hardware (extension builder → session → application decode → rule engine).

Mapping to claim 1 / 17:

• Receive packet / append extension → NPU pipeline descriptor/context.
• Session information into extension → Shwed's per-connection state tables, moved into the per-packet metadata.
• Forward to packet policy rule engine, determine common condition across two policy types → the shared decision tree from the classification art.
• Association + extension update → standard metadata marking.
• No shared memory, extension is the transport → inherent to a pipeline that passes packet+descriptor between stages.

Motivation (KSR): Network-equipment designers in 1999–2001 were under acute pressure to run firewalls, QoS, LB, and IDS at wire speed. The identified solution is the predictable one: (1) parse once and carry derived fields forward; (2) share common tests across rules via a decision tree; (3) deploy on pipelined/multi-engine hardware rather than a general-purpose CPU. Each is a known technique applied to a known problem with a predictable result — the hallmark of KSR obviousness.

Ground 2 — NPU pipeline reference as primary, in view of the patent's admitted multi-policy integration

Using a pipeline-of-stages network-processor architecture as the primary reference, in view of the admitted prior art (Checkpoint FW, ISS IDS, multi-function switches/routers; Background §"Description of the Related Art"), and further in view of a rule-compilation reference:

• The primary reference teaches packet + carried metadata through stages (the extension).
• The admitted art teaches both policy types (FW + IDS/QoS) that the claim pairs as "first" and "second" types.
• The compilation reference teaches extracting commonalities across rule sets into one decision tree — precisely the "common condition shared by a first-policy-type rule and a second-policy-type rule."

Motivation: a POSITA seeking to consolidate several existing policy appliances onto one high-speed box would (i) preserve each policy engine's existing rules and (ii) merge their shared tests to avoid re-parsing and redundant classification — the stated commercial problem (SPs wanting integrated security + performance at wire speed, per the patent's own Background).

Ground 3 — Attacking the "without shared memory" limitation specifically

Because the "no shared-memory" language appears designed to distinguish over a distributed-processor-with-shared-state architecture, the obviousness case should pair any shared-memory pipeline reference with an NPU reference whose descriptor travels with the packet (in-band metadata), which inherently avoids shared-memory coupling between stages. This shows the transition from shared state to in-band per-packet extension was a routine design choice within the ordinary skill of a network-processor engineer and was driven by the well-known latency/contention costs of shared-memory access in line-rate pipelines.

---

5. Why each combination would have been obvious — consolidated motivation

1. Predictable, enumerated solutions. KSR: where there is a design need and a finite number of identified, predictable solutions, ordinary skill yields the combination. "Parse once, carry forward," "share common tests in a decision tree," and "pipeline the checks" are exactly such solutions.
2. Solved in the same field / same problem. All references address wire-speed packet handling and multi-function policy devices — no remote-art analogy problem.
3. Reasonable expectation of success. Each technique (metadata pass-through, tree-shared conditions, multi-stage HW) independently improved throughput; combining them had no unpredictable interaction.
4. Express commercial pressure. The Background itself frames the problem (SPs needing integrated policies at wire speed) — market pressure is an accepted motivation (KSR).

---

6. Where an obviousness challenge is weakest (strongest § 103 rebuttals)

Being candid, because these are the limitations that most plausibly supported allowance:

• The specific cross-policy common-condition accounting. None of the confirmed references cleanly teaches one condition-tree node simultaneously satisfying a rule of a first policy type (e.g., FW) and a rule of a different policy type (e.g., QoS) in a single traversal. A patent owner would argue the references are "analogous but siloed."
• The negative claim limitation "without shared memory." Negative limitations are construed strictly and can be hard to meet with references that are silent, but they also can be easy to design around — and an NPU descriptor reference squarely reads on it, which cuts for the challenger.
• The extension as the sole inter-module transport. If the cited pipelines instead used shared tables/queues (a common design at the time), the challenger must reach a second reference showing in-band per-packet metadata to fill the gap — which is why the NPU-descriptor reference is essential, and why I flag that I could not verify a specific NPU patent number within my tool limits.

Secondary considerations (to be checked, but likely weak here): the patent is Expired – Fee Related (adjusted expiration 2024-01-25 per Google Patents), and I found no litigation pressing nexus-worthy evidence of unexpected results or commercial success tied to the claimed combination (see the litigation summary's negative finding and its caveats). Absent such evidence, the Graham secondary factors do not neutralize a strong prima facie case.

---

7. Verification gaps and recommended next steps

To convert this into a defensible § 103 ground, an examiner or challenger must:

1. Pull the patent's actual "References Cited (42)" list and Non-Patent Citations from the file wrapper (USPTO Patent Center / Public Search for App. 10/052,745). I could not retrieve it here — this is the single biggest gap.
2. Confirm the primary "packet-extension / descriptor pass-through" reference with a verifiable number and publication date before Jan. 17, 2001 (candidate: IXP1200 / C-Port C-5 / Agere PayloadPlus documentation or patents). I explicitly did not fabricate a number for this.
3. Substitute a packet-based QoS reference for the ATM-oriented US 6,041,039, which is a poor mapping to the "QoS policy" element.
4. Confirm the classification-art citations (Lakshman/Stiliadis 1998; Gupta/McKeown 1999) as § 102(b) printed publications predating Jan. 17, 2001 — both do.
5. Do not rely on US 7,120,144 or US 7,058,821 as prior art; both post-date the '833 priority date.
6. Check secondary considerations via the (negative) litigation finding and the patent's expired status — but keep the Graham caveats from the litigation summary in view.

---

Bottom line

On the record available to me, claims 1, 9, and 17 of US 7,257,833 appear vulnerable under § 103 to a combination of (i) a multi-stage, per-packet-metadata network-processor pipeline, (ii) a known rule-driven firewall/stateful-inspection reference such as US 5,835,726 (Shwed), and (iii) decision-tree packet-classification art (Lakshman/Stiliadis 1998; Gupta/McKeown 1999) that shares common condition tests across rules — with the motivation supplied by the patent's own admitted commercial problem of integrated, wire-speed multi-policy enforcement. The cleanest reading of claim 1/17 is on the "cross-policy common condition" and "no-shared-memory via extension" limitations; the latter in particular is well met by in-band per-packet-descriptor pipeline designs. However, this conclusion rests on reconstructed prior art, not the patent's certified cited-art list, which I was unable to retrieve — so the ground must be validated against the actual file wrapper before it could be relied upon.