US 7107613

I'll search for authoritative information on US 7,107,613, focusing on USPTO records and any CAFC 2026 activity.

Let me verify whether 7107613 appears as a patent-in-suit in any litigation, including CAFC 2026 dockets.

Patent Summary — US 7,107,613

Source of record: https://patents.google.com/patent/US7107613/en (full text supplied; preferred over search results). I also searched for USPTO/CAFC docket activity on this number.

Bibliographic data

Abstract (verbatim, per the patent text)

"According to one embodiment, the number of tunnels on a network may be reduced. A set of tunnels are selected which exchange data packets between a first security device and a second security device. Each tunnel in the set of tunnels specify a dimensional range for data packets that are subject to that tunnel. A super tunnel is determined to replace the set of tunnels, so that a dimensional range of the data packets that are made subject to the super tunnel encompass a dimensional range of the data packets that were made subject to the set of tunnels. A determination is made as to whether the super tunnel excludes data packets that are permitted by the first security device and the second security device, but not subject to any one of the tunnels other than tunnels in the set of tunnels. In response to determining that the tunnel excludes data packets that are permitted by the first security device and the second security device, but not subject to any one of the tunnels in the set of tunnels, the super tunnel is implemented between the first security device and the second security device."

Plain-language overview of the independent claims

• Claim 1 — Method. Select a set of tunnels between a first and second security device (e.g., firewalls), where each tunnel covers a "dimensional range" of packets (source/destination address, port, protocol). Compute a "super tunnel" whose dimensional range encompasses those of the set. Determine that the super tunnel would, if implemented, tunnel data packets that are subject only to tunnels in the set; and, on that basis, implement the super tunnel between the two devices, thereby reducing the total number of tunnels implementing the security policy.
• Claim 10 — Method (two-device validation). Identify a super tunnel that services all packets permissible by selected entries in a crypto-access control list (CACL) of a first security device. Verify on the first device that the super tunnel can be implemented (a) without affecting clear (non-tunneled) traffic and (b) without affecting packets controlled by entries other than the selected ones. Then locate the corresponding selected entries in the peer CACL on a second security device and repeat both checks there. If both devices pass, implement the tunnel to service packets permitted on both.
• Claim 13 — Computer system. A system with storage holding a first CACL (first security device) and a second CACL stored as its "peer," plus a processor programmed to: identify select entries in the first CACL; derive a single entry to service those packets; confirm the single entry does not service other packets permitted by the first device; identify corresponding entries in the peer CACL on the second device; confirm the same on the second device; and configure both CACLs to implement the single entry.
• Claim 16 — Computer-readable storage medium. Media carrying instructions for the same select-tunnels / determine-super-tunnel steps recited in claim 1. (Note: the supplied text truncates this claim mid-sentence — "...encompasses a dimensional range of the data packet" — so the full wording of claim 16 and of claims 17–34 is not available to me.)

Dependent claims visible in the text: 2–9 (depend from claim 1, covering ACL vs. CACL selection, single-entry substitution, source/destination/service range criteria, clear-traffic and other-tunnel checks, and peer-CACL identification); 11–12 (depend from claim 10); 14–15 (depend from claim 13).

Litigation / CAFC 2026 check

• No CAFC 2026 docket or Federal Circuit proceeding naming US 7,107,613 as the patent-in-suit was found in my searches of CAFC 2026 materials and general litigation databases.
• The number 7107613 does surface in litigation-related documents, but only as cited prior art in the file histories of other patents — e.g., IPR exhibits in Palo Alto Networks/Centripetal Networks and Cisco/Centripetal/Keysight matters concerning U.S. Patents 9,100,912; 9,565,213; and 9,917,856. In those papers it appears in examiner "References Cited" listings as "7107613 B1, 2006-09-12, Chen et al." It is not the challenged or asserted patent there.
• Consistent with that, the Google Patents record lists the patent as Expired – Fee Related (adjusted expiration 2024-10-08), which is generally incompatible with active 2026 infringement assertion.

Uncertainty notes

1. Claim drafting discrepancy. Claim 1 literally requires "determining that the super tunnel would ... tunnel data packets that are subject only to tunnels in the set of tunnels," whereas the Abstract frames the condition negatively (that the super tunnel excludes packets not subject to that set, i.e., clear traffic and other-tunnel traffic). I have reported both exactly as written and have not "corrected" either. This literal affirmative phrasing in claim 1 is notable and appears to conflict with the Abstract and with the specification's stated criteria (FIGS. 2A–2C and steps 410/420).
2. Truncated claim set. The authoritative text provided stops partway through claim 16; claims 17–34 (and possibly additional independent claims) are not visible to me, so my independent-claim overview is limited to claims 1, 10, 13, and 16.
3. Docket coverage. My litigation check relies on web-search coverage of USPTO/PTAB/CAFC materials; it is not a substitute for a direct PACER/CM-ECF or Docket Navigator query. I state with reasonable confidence that I found no live 2026 Federal Circuit appeal on this patent, but I cannot rule out an unfiled or unindexed action.

I'll research litigation involving US patent 7107613. Let me run several targeted searches.

Let me dig deeper with more targeted searches on litigation databases.

Summary

Based on my searches of patent-litigation sources (including the Unified Patents portal, Google Patents litigation data, Justia Dockets, Docket Alarm/PTAB records, CourtListener, and general web sources), I found no known litigation involving U.S. Patent No. 7,107,613.

To be precise about my confidence: I cannot prove a universal negative from web searches alone, but every targeted query for the literal number "7107613" / "7,107,613" returned only non-litigation or coincidental matches, and none of the standard litigation trackers associate any case with this patent.

What the searches actually returned for "7107613"

Key factual observations about the patent itself

• Patent: US 7,107,613 B1, "Method and apparatus for reducing the number of tunnels used to implement a security policy on a network."
• Assignee/owner: Cisco Technology, Inc. (original assignee; no recorded reassignment to a litigation-oriented entity appears in the record).
• Inventors: Shigang Chen, Partha Bhattacharya, Susan Hinrichs.
• Priority/filing date: March 27, 2002; granted September 12, 2006.
• Legal status: Expired – Fee Related (adjusted expiration October 8, 2024), per the Google Patents legal-status listing.

The fact that the patent was allowed to expire for failure to pay maintenance fees, and that I can find no assignment to an NPE or assertion campaign, is consistent with there having been no litigation over this patent.

Conclusion

No litigation is known involving U.S. Patent No. 7,107,613. It does not appear as an asserted patent in any district-court, ITC, or PTAB proceeding I could locate. Its only appearances in legal/patent databases are as a prior-art citation in the file histories of unrelated patents (notably in the Cisco/Centripetal Networks IPR exhibits).

Caveats: (1) I could not complete direct queries against PACER, Docket Navigator, or Lex Machina, which are paywalled and not fully indexed by open web search — a truly exhaustive litigation check would require those. (2) Negative findings from web search are subject to indexing gaps. If you need a court-record-certified "no litigation" statement, that would require a PACER/Docket Navigator search run directly. I did not fabricate any case names, numbers, or outcomes; where a search hit merely contained the digit string "7107613," I have identified it explicitly as a non-litigation coincidence rather than misreporting it as a case.

I'll research this patent's PTAB history. Let me start with the canonical check plus targeted web searches.

Let me run additional targeted searches to confirm whether any AIA trial was ever filed against this patent.

PTAB / AIA Trial Analysis — U.S. Patent No. 7,107,613

Patent: U.S. 7,107,613 B1 — "Method and apparatus for reducing the number of tunnels used to implement a security policy on a network"
Inventor(s): Shigang Chen; Partha Bhattacharya; Susan Hinrichs
Assignee: Cisco Technology, Inc. (original and current assignee, per USPTO assignment records)
Priority / Filing date: 2002-03-27 · Granted: 2006-09-12
Recorded status: Expired – Fee Related (adjusted expiration 2024-10-08)

Proceedings overview

Total AIA trial proceedings on file: 0. The USPTO Open Data Portal (ODP) returns no IPR, PGR, or CBM proceedings for U.S. 7,107,613 as of the most recent ingest, and my web searches surfaced no PTAB trial, no Federal Circuit appeal, and no ex parte reexamination docket naming this patent as the subject patent. Because there are no proceedings, there is no claims-invalidated / claims-sustained / settled / institution-denied breakdown to report — every claim (1–34) is untested at the PTAB. Bottom-line defensive posture for a defendant: this patent has never been challenged at the PTAB and has never been narrowed by an AIA trial — but that cuts both ways. There is no FWD to cite for invalidity, and the patent is recorded as expired, which is the far more consequential fact (see "Recommended next steps").

⚠️ Note on scope: I could not exhaustively sweep every global docket in the steps available. The ODP block is the canonical AIA-proceedings list and it is empty; web search corroborates. If you have a specific litigation docket that prompted this query, run a PACER/Docket Alarm check on the patent number to rule out district-court assertions — but on the PTAB record, the answer is "nothing filed."

Proceedings

None. No AIA trial proceeding has ever been filed against U.S. 7,107,613.

No proceeding number, petitioner, panel, institution decision, FWD, settlement, or appeal exists to report for this patent. I will not manufacture entries to fill this section. The only occurrences of "7107613" in PTAB-related materials are as cited prior art inside other parties' petitions — i.e., the patent's disclosure was used against other patents, not the reverse. Examples surfaced:

• Cited as an IDS/prior-art reference in the Centripetal Networks IPR family (e.g., IPR2021-01152, IPR2021-01520, IPR2021-01521, IPR2022-01151, IPR2022-01199) — Palo Alto Networks / Keysight / Cisco petitions concerning Centripetal patents, including U.S. 9,917,856 and U.S. 10,091,246.
• Cited in the file history of U.S. 9,565,213 (IPR2018-01512).

These are unrelated proceedings about other patents. They confer no estoppel here and have no bearing on the validity or enforceability of 7,107,613.

Strategic summary

Claim status. All claims of U.S. 7,107,613 — independent claims 1, 10, and 13, and all dependents (through claim 34) — are UNTESTED. None has been canceled, none has been confirmed, and none has had claim construction or patentability reviewed by the Board. There is no surviving-claim carve-out to rely on and no canceled-claim safe harbor to exploit.

Estoppel landscape. Because no IPR/PGR/CBM was ever instituted, § 315(e)(2) estoppel does not exist for anyone with respect to this patent. A defendant today is free to raise any § 102/§ 103 ground in a civil action without worrying that a prior petitioner already spent the ground. Conversely — and this is the key asymmetry — because no petition was ever filed, there is also no IPR on-ramp: a defendant who wants PTAB relief would have to file the first petition, and would confront the § 311(b) ground limits (patents and printed publications only) and the one-year § 315(b) bar clocked from service of any complaint.

Pattern signals. There is no pattern: no repeat petitioner, no patent-owner PTAB-appeal history connected to this patent, no defensive aggregator (Unified Patents, RPX, etc.) involvement. Note that Cisco — an operating company and the assignee, not a troll — appears here on the patent-owner side, and the patent's own subject matter (internally computing equivalent crypto-access-control-list "super tunnel" entries to collapse VPN tunnels) suggests it was prosecuted/used as a Cisco product/implementation patent rather than a licensing asset. The patent's appearance in third-party IPRs is purely as a prior-art citation, which is consistent with a well-known, foundational networking disclosure — not with an assertion campaign.

Expiration is the dominant fact. The structured record lists this patent as Expired – Fee Related, adjusted expiration 2024-10-08. If that date holds, the patent term has run; an expired patent cannot be infringed prospectively, and damages exposure would be limited to past infringement within the 35 U.S.C. § 286 six-year lookback — which here would reach back only to roughly 2020-09 and would have to predate expiration. Verify the expiration basis independently (term expiration vs. maintenance-fee lapse) on USPTO Patent Center before relying on it, since "expired" can also mean the patent was in force through its full term — either way, no live term appears to remain as of 2026-09-20.

Recommended next steps

1. Lead with expiration, not validity. Before investing in prior art, confirm the expiration status and date on USPTO Patent Center (application 10/109,387). If the patent is expired, there is no prospective infringement and any demand letter asserting current infringement is facially defective. This is a cheaper and stronger defense than an invalidity fight.
2. There is no FWD to link or quote. Unlike a patent that has been through an IPR, there is no Final Written Decision to hand an adversary. Do not represent to a court or opponent that any claim has been canceled or upheld — nothing has been adjudicated.
3. If you must develop invalidity (e.g., for a past-damages window), you are the first mover. With no prior IPR, there is no § 315(e)(2) estoppel and no Board claim construction on the record. The claims are 2002-priority networking/VPN tunneling claims, so the prior-art universe (IPSec/VPN tunnel configuration and ACL/CACL aggregation art from the late 1990s) is likely rich, but none of it has been Board-tested.
4. PTAB timing, if a petition is contemplated. No trial is pending, so there is no institution deadline or FWD due date to track. For a hypothetical first petition: institution decision due within 6 months of a complete petition's filing (§ 314(b)); any instituted trial must reach FWD within 12 months of institution (§ 316(a)(11)), extendable ~6 months for good cause.
5. Rule out a parallel district-court track. The PTAB record is empty; run a litigation check (PACER / Docket Alarm) on U.S. 7,107,613 to confirm the absence of assertions. The absence of any PTAB activity on a 2002 patent asserted in 2026 would itself be unusual and worth understanding before responding to a demand.

Sources: structured "PTAB proceedings on file" block (USPTO ODP, canonical, no AIA proceedings); Google Patents — US7107613B1 (bibliographic/assignment/expiration data and full text); web-search corroboration of third-party IPR petitions citing 7,107,613 as prior art only (Centripetal Networks IPR family — e.g., IPR2021-01152, IPR2021-01520/01521, IPR2022-01151/01199 — and IPR2018-01512). No PTAB FWD or CAFC opinion naming 7,107,613 as the subject patent was found; none is cited because none exists.

I'll start by verifying the assignment record against the primary sources and cross-references.

Ownership & Assignment Analysis — US 7107613 B1

Patent: "Method and apparatus for reducing the number of tunnels used to implement a security policy on a network"
App. No.: US 10/109,387 · Filed: 2002-03-27 · Issued: 2006-09-12 · Original assignee: Cisco Technology, Inc.
Legal status (Google Patents): Expired – Fee Related, adjusted expiration 2024-10-08

Data-quality note up front. The Assignment Center record for this patent was not directly retrievable by the tools available to me in this working session (patents.google.com serves the bibliographic/legal-events summary, not the reel/frame, and my live searches for the underlying reel/frame and correspondent returned no result). I am therefore reporting the assignment chain as reflected in the Google Patents legal-events data embedded in the authoritative patent text and will not invent a reel/frame or a correspondent name. Where the rubric asks for reel/frame and correspondent, I say so explicitly rather than fabricate. Verify at USPTO Assignment Center (search by patent number 7107613) and at https://assignment.uspto.gov/patent/index.html.

Inventors

Unusual-pattern note: None observed. All three inventors executed an assignment to Cisco Technology, Inc. recorded contemporaneously with the 2002-03-27 filing, i.e., the classic "hired-to-invent" employee assignment executed at filing — not the post-filing mass-departure pattern that can precede a portfolio sale. I have no dated evidence of any inventor leaving Cisco within 12 months of filing, and I will not infer one. (Shigang Chen is now an academic at the University of Florida, but that move is unconnected to this record and I cannot date it from the sources reviewed.)

Original assignee

Cisco Technology, Inc. (a Cisco Systems holding/IP entity; parent Cisco Systems, Inc.).

• Primary line of business: Networking hardware and software — routers, switches, security appliances (PIX/ASA firewalls, VPN concentrators), and IOS/IOS-XR system software.
• Did they ship a product embodying the claims? Yes, plausibly and with documentation from the patent itself: the specification's implementation-architecture section (§4.0 / FIG. 5) names Cisco Secure Policy Manager (CSPM) as the commercially available network-management system that executes the tunnel-reduction logic, and the described mechanics — access control lists, crypto-maps, crypto-access control lists, IPSEC tunnels — are the Cisco IOS/PIX configuration primitives that were shipping at the 2002 priority date. Cisco likewise successfully demonstrated in the later Arista ITC/DI investigations that asserted Cisco patents were embodied in shipping products (USITC Pub. 4909).
• Current status: Operating. Cisco Systems, Inc. remains a public, going-concern networking vendor. No bankruptcy; the 2024 expiration is a routine failure-to-pay-maintenance-fee lapse, not a distress event.

Assignment timeline

One — and only one — assignment is reflected in the legal-events data for this patent.

• 2002-03-27 (executed) / recorded 2002-03-27 — Reel/frame not retrieved (see data-quality note; the Google Patents legal-events entry does not expose it)
  • Conveyance: Assignment of Assignors' Interest ("ASSIGNMENT OF ASSIGNORS INTEREST; SEE DOCUMENT FOR DETAILS")
  • Assignor: HINRICHS, SUSAN; BHATTACHARYA, PARTHA; CHEN, SHIGANG (all three named inventors)
  • Assignee: CISCO TECHNOLOGY, INC., California corporation, 170 West Tasman Drive, San Jose, CA 95134
  • Correspondent: not retrievable from the sources available; no correspondent is recorded in the Google Patents legal-events summary. I will not guess a name.
  • Context: Contemporaneous employee-to-employer assignment at filing — plain acquisition of title by the operating company. Not a fire-sale, not an internal reorg, not a transfer-to-asserter.

No post-issuance assignments were found. Between the 2002 recordation, the 2006 grant, and the 2024 fee lapse, the only other events in Google Patents are third-party citations of this patent as prior art (e.g., by Cisco's own later applications). There is no record of a transfer to Cisco Systems, Inc. for this patent (the Cisco Technology → Cisco Systems 2014 re-papering that surfaced in the Arista matter, e.g., for U.S. 7,340,597, does not appear on this patent's record). Consistent with the rubric: this usually means the original assignee still owns the patent — and here the patent simply expired in 2024 while still in Cisco's hands.

Timeline diagram

timeline
    title Ownership of US 7107613
    2002 : Filed 27 March
         : Inventors assign to Cisco Technology Inc
    2006 : Patent issued 12 September
    2024 : Expired unpaid maintenance fees

(No inter-entity transfers occurred between 2002 and 2024, so the diagram is intentionally sparse. Reel/frame omitted because it was not retrievable; see note.)

NPE / troll-pattern signals

1. Shell-entity transfer — not present. The single recorded assignee is Cisco Technology, Inc., a public operating company's IP-holding subsidiary. No "IP / Holdings / Licensing / Ventures" suffix, no Delaware/Texas single-purpose LLC, no registered-agent service address appears anywhere in the chain (the recorded address is Cisco's 170 West Tasman Drive campus).

2. Known asserter in the chain — not present. No assignee matches any public NPE list (Acacia, Marathon, IV, IPNav, Wi-LAN, Mosaid/Conversant, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, Document Generation Corp, Spangenberg entities, or any Unified Patents / RPX high-frequency plaintiff). Cisco is a defendant-facing operating company, not an asserter on those lists.

3. Repeat correspondent across the chain — unclear / not applicable. The chain has exactly one link, and no correspondent of record was retrievable, so recurrence cannot be assessed. There is nothing to flag here.

4. Cascading transfers — not present. One assignment total, executed and recorded the same day (2002-03-27); no chained LLCs, no transfers within 24 months, no shared principals.

5. Pre-litigation transfer — not present. The sole assignment is contemporaneous with the original filing, ~4.5 years before the 2006 grant, and I found no infringement suit naming this patent. There is no evidence of a chain arranged to enable assertion.

6. Bankruptcy fire-sale — not present. Cisco has not filed Chapter 7/11; the 2024 lapse is an unpaid-fee expiration, not a sale in proceedings.

7. Privateering — not present. No transfer from the operating company to an NPE. (Cisco has asserted its own patents against competitors, e.g., Cisco Systems, Inc. v. Arista Networks and the Arista ITC DI matter — but that is operating-company enforcement of a different asserted set, and I found no indication this patent was part of it.)

8. Defensive aggregator (anti-NPE) — not present. The chain never terminates at RPX, AST, LOT Network, Unified Patents, or OIN; it never leaves Cisco.

Verdict

Insufficient data — the chain contains only the original assignment (inventors → Cisco Technology, Inc., executed/recorded 2002-03-27), which is the rubric's literal definition of this category, and no reel/frame or correspondent could be retrieved to complete the record.

Justification: There is exactly one recorded conveyance — the three inventors' assignment to Cisco Technology, Inc. at the 2002-03-27 filing — and no post-issuance transfer of any kind before the patent expired for unpaid fees on 2024-10-08. Every NPE/troll signal above is affirmatively not present or not applicable; this is a captive operating-company portfolio patent that never left Cisco, so there is no NPE pattern to report. The only open item is procedural: I could not pull the reel/frame or correspondent of record, which is why the verdict is framed as a data-availability call rather than a substantive "defensive/non-asserting" call (which the rubric reserves for chains terminating at a defensive aggregator).

Verification link: USPTO Assignment Center — search patent 7107613 (alternate index: https://assignment.uspto.gov/patent/index.html).

I'll research the prior art citations for US Patent 7107613. Let me search multiple sources.

Let me get the full citation lists from Justia and FreePatentsOnline.

Let me try to retrieve the complete "References Cited" list from additional sources.

1. Patent identified (interpreted literally)

I searched specifically for 7107613. I did not substitute any look‑alike number (e.g., the Japanese "特許 7107613," the WO 9527613 publication, or the "7107613" supply‑part code that surfaced in unrelated results). Note that the "WO 9527613" and JP "特許 7107613" hits are different identifiers and are not this patent.

2. Important limitation on this answer (stated up front, per operating rules)

• The authoritative full text supplied for US 7107613 does not include the front‑page "References Cited" section — the fetched document goes straight from the abstract/description to the claims.
• The reference list below is drawn from a secondary copy of the patent's front matter (Justia: https://patents.justia.com/patent/7107613), which returned a partial list. USPTO front pages typically carry the complete "U.S. Patent Documents / Foreign Patent Documents / Other Publications" set; that full set can only be confirmed from the official USPTO PatentCenter file wrapper (https://patentcenter.uspto.gov) or the printed front page. I was not able to retrieve the complete list, and the Justia extract appears truncated (the NPL entry for Ioannidis is itself cut off mid‑sentence).
• Where I could not verify a reference's title or filing date from any retrieved source, I say so explicitly rather than filling it in from memory.

3. References cited on the face of US 7107613 (as retrievable)

U.S. Patent Documents

Literal‑reading caveat: items 3–5 carry publication dates later than the 2002‑03‑27 filing date. Under 35 U.S.C. § 102 they cannot be § 102(a)/(b) printed publications as of those dates; they could only operate as § 102(e) art via an earlier effective filing date. I could not verify their filing dates, so I make no assertion either way.

Other Publications (Non‑Patent Literature)

4. Anticipation analysis against the actual claim set

The claim set as supplied is 34 claims, of which only claims 1–16 are reproduced in the fetched text (the copy truncates mid‑way through claim 16). A § 102 anticipation requires a single reference to disclose every element, arranged as in the claim.

Independent claim 1 requires, in substance: (a) selecting a set of tunnels between first/second security devices, each specifying a dimensional range; (b) determining a super tunnel whose dimensional range encompasses the ranges of the set; (c) determining that the super tunnel would tunnel data packets subject only to tunnels in the set (i.e., that it does not capture clear traffic or traffic of non‑selected tunnels); and (d) implementing the super tunnel, thereby reducing the tunnel count.

Independent claim 10 adds the two‑endpoint test — the same admissibility checks must be satisfied on the first security device and its CACL peer on the second security device. Independent claim 13 recites the computer system performing the single‑entry substitution and configuring both CACLs.

Applying that framework to the cited art:

• None of references 1–7 discloses the "super tunnel"/"super rule" construct. The minimum‑super‑network and minimum‑super‑service derivations (longest‑common‑prefix supernets; FTP(21)+HTTP(80) → "all TCP"; TCP+UDP → "all IP") are the distinctive heart of claims 1, 4, 5, 10 and 11, and no cited reference computes a covering rule over a set of tunnels.
• None discloses the two exclusion conditions of claims 6, 7, 8, 9, 14 and 15 — i.e., verifying that (i) clear traffic is untouched and (ii) traffic bound for non‑selected tunnels (with first‑match CACL ordering, per spec §4.0/FIG. 4, step 420) is untouched, on both endpoints.
• Ioannidis (2000) is the nearest reference and would be the strongest § 102(b)/§ 103 candidate for the general "server configures distributed enforcement points" architecture of claim 13, but it fails the tunnel‑reduction and exclusion limitations, so it does not anticipate any of claims 1–16.
• Guttman (1997) supplies only the policy‑mapping background (relevant at most to the "determining" steps as a § 103 combination), not anticipation.
• References 1 (Ylonen) and 2 (Cheng) predate or are contemporaneous with the filing and relate to tunneling/security generally; they supply the tunneling backdrop of spec §2.0 but not the claimed reduction method.

Bottom line: On the references retrievable for US 7107613, there is no reference that, standing alone, anticipates claims 1–16 under 35 U.S.C. § 102. The two non‑patent items (Ioannidis 2000; Guttman 1997) are § 102(b) prior art and are properly characterized as background/§ 103 material. The three published applications (2002/0178361, 2003/0135753, 2003/0140142) post‑date the filing and their § 102(e) status is unverified.

5. What I could not verify (explicit)

1. The complete "References Cited" list on the front page of US 7107613 — the authoritative full text you supplied omits it, and the secondary source returned a truncated list.
2. The titles and filing dates of US 6,738,909 B1 (Cheng et al.) and the three published applications (Genty; Batra; Marples) — retrieved snippets gave only numbers, dates, and first‑named inventors. I have deliberately not supplied titles from memory.
3. Whether the post‑filing published applications were cited under § 102(e) or for another reason.

To close those gaps, the definitive source is the official record: USPTO PatentCenter (Application 10/109,387) and the printed front page of US 7107613 B1 at https://patents.google.com/patent/US7107613/en (section "References Cited"), plus the file wrapper's examiner search/art listing.

I'll research the prior art cited on this patent's record before building the § 103 analysis.

Let me pull the specific prior-art references of record and examine their disclosures.

Obviousness Analysis — U.S. Patent No. 7,107,613 B1

Method and apparatus for reducing the number of tunnels used to implement a security policy on a network
Inventors: Shigang Chen, Partha Bhattacharya, Susan Hinrichs · Assignee: Cisco Technology, Inc.
App. No. 10/109,387 · Filed 2002‑03‑27 · Granted 2006‑09‑12 · Status: Expired – Fee Related
Source of record: https://patents.google.com/patent/[US7107613](/patent/US7107613)/en

Scope/grounding note. The Google Patents page supplied to me contains a Prior art keywords field ("tunnels, tunnel, data packets, security device, super"), a Prior art date of 2002‑03‑27, and the examiner's classifications (H04L63/029 – firewall traversal/tunnelling; H04L63/20 – network security policies; H04L63/164 – network‑layer IPsec), but it does not itself reproduce the list of cited references. I therefore supplemented the record with the "Referenced Cited" listing for this patent (https://patents.justia.com/patent/7107613). Where I could not retrieve and read the full text of a reference in this session, I say so explicitly rather than attributing disclosures to it.

1. The claimed subject matter (what must be rendered obvious)

The patent has six independent claims — 1 and 10 (methods), 13 (computer system), 16 (computer‑readable medium), 17 (means‑plus‑function apparatus), 25 and 33 (processor/CRM apparatus). They reduce to a common core:

1. Select a set of tunnels between two security devices (each entry = a "dimensional range": source address, destination address, source port, destination port, protocol — see FIG. 1/2.0 System Description).
2. Determine a "super tunnel" whose dimensional range encompasses the ranges of the selected tunnels — preferably a minimum super rule: minimum super network of sources, of destinations, and minimum super service (spec, 3.0 Methodology, step 330).
3. Verify non‑interference: the super tunnel must not capture (a) clear traffic, or (b) traffic designated for tunnels other than those being replaced — and must pass this test at both endpoints (peer CACL), steps 340/350 and FIG. 4 steps 410/420.
4. Implement the single entry in place of the set.

Two features deserve emphasis because they shape the obviousness discussion:

• The "minimum super network" is computed as the longest common prefix of the constituent addresses, zeros appended (Network 1/Network 2 example: 10101010.11111111.00000001.00000000 + 10101010.11111110.00000010.00000000 → 10101010.111111110.00000000.00000000 255.254.0.0, reproduced literally as printed). That is textbook CIDR route aggregation/supernetting.
• The patent's own background concedes the goal and even the manual practice: "There are some important practical values in minimizing the number of tunnels… networks can scale more easily when fewer tunnels exist… Removing unnecessary tunnels is usually performed manually by administrators of a network." That is an admission of a known problem, a known desirability, and a known (manual) solution — the classic posture for an "automating a known manual process" obviousness attack (cf. KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007)).

Note on claim breadth. Claim 1 recites "determining that the super tunnel would, if implemented, tunnel data packets that are subject only to tunnels in the set of tunnels." Read literally, that is nearly tautological for any encompassing tunnel and is broader than the specification's stated permissiveness criterion (non‑interference with clear traffic and with other tunnels). Likewise the closing "wherein implementing the super tunnel reduces the number of tunnels" is a result/functional recitation of limited patentable weight. The narrower operating limitations live in claims 6–9, 10–12, 14 and 15. A § 103 attack should therefore target claim 1 (and apparatus claims 13, 17, 25, 33) first, then the dependents.

2. The prior art of record

Because the application was filed 2002‑03‑27, pre‑AIA 35 U.S.C. § 103(a) governs. A published application is prior art under § 102(e) as of its filing date, so Genty/Batra/Marples are usable only if their underlying filings predate 2002‑03‑27 — I have not confirmed those dates and they should not be relied upon without verification.

The classifications assigned (network‑layer IPsec; security‑policy management) confirm that the examiner treated IETF IPsec architecture and policy‑management art as the relevant field, which makes the foundational IPsec RFCs — RFC 2401 (Security Architecture for the Internet Protocol), defining the Security Policy Database with source/destination/port/protocol selectors and Security Associations; RFC 2407 (IPsec DOI); RFC 2408 (ISAKMP); RFC 2409 (IKE) — and CIDR aggregation (RFC 1519 / RFC 4632) fair game as analogous prior art.

3. Grounds of rejection

Ground A — RFC 2401 + CIDR supernetting + a policy‑management system (Ioannidis; Guttman)

Targets: claims 1–9, 16, 25–32.

• RFC 2401 supplies the "dimensional range" framework verbatim: SPD selectors of source/destination address, source/destination port, and protocol, matched against a policy that directs a packet into a tunnel (SA) or lets it pass as clear traffic. This is exactly the patent's FIG. 2A/2C model of address‑range rectangles plus clear traffic.
• CIDR supernetting supplies the "minimum super network/super service" computation: longest‑common‑prefix aggregation of address ranges, and widening port ranges (the patent's own worked example is the CIDR algorithm, and its FTP/HTTP → "all TCP" and "all TCP + all UDP → all IP" examples are ordinary port‑range generalization).
• Ioannidis and Guttman supply the management‑plane aspect: central specification of a global policy and its translation into per‑device, locally enforced rules, with the designers' acknowledged concern that a derived local rule must preserve the semantics of the global policy.

Rationale/motivation (articulable, per KSR/In re Kahn): The IPsec device's tunnel capacity is finite and is a documented scalability bottleneck (the patent itself says so). Route aggregation was a decades‑old, routine optimization for the same class of data — prefix‑based packet classification — and one of ordinary skill would have recognized that the ACL/CACL entries feeding tunnels are themselves prefix/port‑range expressions amenable to the identical aggregation. The only remaining step is a verification that the widened rule does not swallow traffic that is meant to match a different rule — which is precisely the "first‑match, ordered rule list" semantics already embodied in any ACL engine, and precisely the type of global‑vs‑local semantic check Guttman addresses.

Ground B — Ylonen US 6,438,612 + RFC 2401 (+Ioannidis)

Targets: claims 1, 3, 4, 8, 9, 13–16.

Ylonen (https://patents.google.com/patent/US6438612) discloses establishing security associations/tunnels between the same pair of physical computing devices to carry traffic for a plurality of virtual routers, with selector data stored in the SA to direct traffic to the correct virtual router. It expressly confronts the scaling problem of a large number of virtual networks sharing one physical path and of limited address space — the same class of pressure the '613 patent addresses. Combined with RFC 2401's selector/SA model and Ioannidis's central policy distribution, this renders obvious: (i) recognizing a set of tunnels between two devices as a consolidation candidate, and (ii) replacing them with a single tunnel carrying an encompassing selector. Claims 8–9 (peer entry sets at both ends; verify clear traffic at both ends) are met by the ordinary requirement that an SA's selectors be mirrored at both endpoints so the peers agree on what is tunneled.

Ground C — Guttman "Filtering Postures" + Ioannidis + RFC 2401

Targets: claims 7, 10–12, 14, 15 (the two‑endpoint clear‑traffic / other‑tunnel tests).

Guttman's "postures" work concerns deriving locally enforceable filters from a global policy while retaining the intended semantics of the global specification. Ioannidis describes a distributed firewall in which a central policy is compiled into per‑host/per‑device enforcement. Together they teach the claimed architecture of FIG. 5 (policy server 510 + repository 530 configuring a plurality of firewalls) and the two‑sided permissibility check of FIG. 3 steps 340/350 and FIG. 4 steps 410/420. The specific set arithmetic the patent recites (Traffic(i) = I1*Oi + …, Tunneled(i) = Traffic(i)*(Ci1+…+Cim), Clear(i) = Traffic(i) − Tunneled(i)) is simply the ordinary intersection/union/difference of ACLs — a predictable application of known set operations to known ACL data structures.

Ground D — Ordered first‑match CACL processing (background art)

Targets: the ordering limitation in the FIG. 4/step 420 discussion and dependent claims.

The patent treats "selection of tunnel traffic is a first‑match process" and the rule that a super tunnel need only be compared against later CACLs as an implementation detail. First‑match, top‑down ACL evaluation is the universal, long‑established behavior of firewall/router ACL engines. This is not a point of novelty and, standing alone, is strong § 103 art against any claim that purports to rely on it.

4. Claim‑chart sketch (Ground A — representative)

5. Motivation to combine — stated jointly

A POSITA at the 2002 priority date would have had four independent reasons to arrive at the claimed subject matter, none requiring hindsight:

1. Capacity pressure — the number of IPsec tunnels a device supports is finite (high‑end firewalls ~1,000; low‑end only a few, per the patent's background). Recognizing the aggregation opportunity is the direct response to that pressure.
2. Adjacent, well‑known optimization — supernetting/route aggregation was standard practice for compressing prefix‑based forwarding and filtering data; applying it to the address/port ranges that populate ACLs and crypto‑ACLs is a combination of familiar elements according to known methods (KSR).
3. Management economics — fewer entries and tunnels mean simpler administration and rekeying; the patent admits this was already understood and done manually.
4. Existing policy‑management architecture — central policy compilers that push device‑specific rules (Guttman; Ioannidis) already existed; adding a "does the derived rule change the treatment of other permitted traffic?" check is ordinary semantic‑equivalence verification, not a new mechanism.

The predictable result of these known techniques is exactly the claimed outcome, which satisfies the KSR "predictable variation / obvious to try" standard.

6. Anticipated counter‑arguments and their weaknesses

• "Ylonen teaches away — one SA per virtual network." Weak. Ylonen separates SAs because different virtual networks carry different security requirements. The '613 claims expressly presuppose the same tunnel action across merged entries (spec: "Embodiments of the invention assume that CACL entries that are candidates for a super tunnel specify the same tunnel action"; FIGS. 2A–2C assume identical actions). Thus the reference's rationale for separation is inapplicable to the claims' own premise; there is no teaching away from merging same‑action tunnels.
• "The prior art does not expressly recite the two‑endpoint check." This is the strongest non‑obviousness argument. But it is a verification step whose necessity flows directly from the nature of IPsec SAs (both peers must agree on the selectors — RFC 2401) and from the global‑to‑local semantic preservation discussed by Guttman. It is a predictable, routine engineering check, not an unpredictable result.
• "Minimum super rule" optimization. The specification itself says only that it is "advantageous" and "best to minimize" — an optimization of a known technique, routinely deemed obvious.
• Secondary considerations. No evidence of unexpected results, licensing, or industry praise appears on the face of the document; long‑felt need and failure of others are arguably undercut by the patent's own admission that administrators were already removing tunnels manually.

7. Confidence and caveats

• High confidence: US 6,438,612 (Ylonen) is valid prior art and discloses multiple tunnels/security associations between the same pair of physical devices with selector‑based demultiplexing (verified at https://patents.google.com/patent/US6438612).
• High confidence: Ioannidis (2000) and Guttman (1997) are prior printed publications of record (https://patents.justia.com/patent/7107613) in the distributed‑firewall / policy‑enforcement field.
• Moderate confidence: RFC 2401/2407/2408/2409 and CIDR aggregation (RFC 1519/4632) are proper analogous art given the assigned classifications (H04L63/029, H04L63/20, H04L63/164).
• Low confidence / unverified: I could not verify the disclosures of US 6,738,909 (Cheng), US 2002/0178361 (Genty), US 2003/0135753 (Batra), or US 2003/0140142 (Marples) in this session, nor confirm the filing dates needed to establish their pre‑2002‑03‑27 prior‑art status under § 102(e). Any rejection resting on those four references should be re‑verified against their full texts and filing dates before being asserted.
• I have quoted identifiers and the bit‑pattern of the super‑network example exactly as printed, without correction.

Bottom line: Independent claims 1, 10, 13, 16, 17, 25 and 33 are, on this record, vulnerable to a § 103(a) rejection built on RFC 2401 (IPsec selector/SA model) in view of CIDR supernetting and a policy‑management reference (Ioannidis and/or Guttman), with Ylonen US 6,438,612 supplying the express teaching of multiple tunnels between the same device pair and the selector‑based reason to consolidate. The strongest residual defense is the conjunctive two‑endpoint non‑interference check of claims 6–9, 10, 14 and 15 — but that check reads as a routine semantic‑preservation verification that a POSITA would have found obvious to perform.