US 11290527

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

Let me run targeted checks for any litigation or appellate activity involving this patent.

US 11,290,527 B2 — Automatic Tagging of Cloud Resources for Implementing Security Policies

Sources consulted: Google Patents (full text), Justia Patents, FreePatentsOnline, USPTO.report, Patents Encyclopedia. Two searches specifically targeting CAFC 2026 dockets / litigation returned zero results.

Date note: Your message states the current date as April 26, 2026, while my environment date is September 15, 2026. I flag this because it affects the completeness of any litigation/docket search — a docket filed between those dates would not be reflected in the results I retrieved. No docket information was found regardless.

---

Bibliographic Data (high confidence — consistent across all sources)

---

Abstract (verbatim)

"Systems and methods for automatically tagging cloud resources that are spread across multiple cloud platforms are provided. According to one embodiment, information regarding each cloud provider of multiple cloud providers associated with a cloud environment used by a private network is received by a cloud-tagging orchestrator service of the private network. For each cloud resource of a plurality of cloud resources hosted by the cloud providers on behalf of the private network: (i) information associated with the cloud resource is retrieved by the cloud-tagging orchestrator service; (ii) a unified tag of multiple unified tags for the cloud resource is identified by the cloud-tagging orchestrator service based on a pre-defined global tagging policy; and (ii) the unified tag is assigned by the cloud-tagging orchestrator service to the cloud resource via an application programming interface (API) of a cloud provider of the multiple cloud providers hosting the resource."

---

Plain-Language Overview of the Independent Claims

Claim 1 — Method (the core claim). Three steps, all performed by a "cloud-tagging orchestrator service" running on a security manager tied to a private network:

1. Receive information about each cloud provider among several used by the private network's cloud environment.
2. Then, for each cloud resource hosted across those providers, do three sub-steps: (a) retrieve information about that resource; (b) identify a "unified tag" from a set of unified tags, chosen according to a pre-defined global tagging policy; and (c) assign that unified tag back onto the cloud resource through the hosting cloud provider's API.

The practical point: one central service normalizes disparate per-provider tags into a single cross-cloud vocabulary and writes them back to each provider using that provider's own API.

Claim 8 — Non-transitory computer-readable storage medium. Same three-step method as claim 1, but framed as instructions executed by a processing resource of a private network's security manager. The only substantive difference is that the "cloud-tagging orchestrator service" actor is dropped and the orchestrator steps are attributed to the executing security manager. It is, in effect, the method of claim 1 in media form.

Claim 15 — Multi-tag orchestration system. A system claim with just two structural elements: (1) a processing resource and (2) a non-transitory computer-readable medium coupled to it storing instructions. The instructions perform the identical receive / retrieve / identify / assign-via-API sequence of claim 1. The system claim is therefore structurally broad — the only hardware limitation is processor + memory.

Dependent-claim themes (all three families mirror each other, claims 2–7, 9–14, 16–20):

• Applying a security policy expressed by reference to unified tags, by pulling resource information from a storage database (2, 9, 16);
• Cloud environment being a hybrid multi-cloud of a private cloud plus multiple public clouds (3, 10, 17);
• Assignment enabling visibility and control — stated as a "single pane of glass user interface" only in system claim 18 (4, 11, 18);
• Tagging policy keying off resource information, resource location, and resource function (5, 12, 19);
• Cloud resources being virtual machine instances (6, 13, 20);
• Security manager being a cloud-based security management appliance (7, 14 — present only in the method and medium families).

---

Litigation / Appellate Posture — uncertain; nothing verified

• My searches for CAFC 2026 dockets, PTAB/IPR proceedings, and district-court litigation involving 11,290,527 returned no results.
• One caveat worth flagging: the Google Patents record displays a "Family has litigation" banner with a Darts-ip link (family=79030676) labeled "First worldwide family litigation filed." I could not retrieve any detail behind that banner — no case number, venue, parties, or date. I would treat it as a flag to investigate, not a confirmed fact, and it says nothing about whether any appeal reached the Federal Circuit.
• To verify authoritatively, check the USPTO PatentCenter/Assignment records for application 16/916,237, the PTAB API for IPR/PGR filings, and the CAFC docket system directly.

---

Key Uncertainty Statement

Everything in the bibliographic table, abstract, and claim summaries above is drawn from the authoritative full patent text provided and corroborated by multiple patent databases — I have high confidence in it. The two areas where I have low or no confidence are: (1) any litigation or Federal Circuit activity, for which no authoritative records were retrieved; and (2) the Darts-ip litigation banner's underlying substance. I have not fabricated case numbers, court names, or party names to fill those gaps.

I'll run targeted searches on litigation-tracking sources for this specific patent number.

Let me run additional targeted checks — including the Darts-ip family link flagged earlier and Unified Patents' portal.

Let me check additional patent-litigation databases and the Darts-ip family identifier directly.

Litigation Report — U.S. Patent No. 11,290,527

Date of report: April 26, 2026 (per your instruction)
Subject patent: US 11,290,527 B2 — "Automatic tagging of cloud resources for implementing security policies"
App. No.: 16/916,237 | Filed/Granted: 2020-06-30 / 2022-03-29 | Assignee: Fortinet, Inc.
Inventors: Ignacio Franzoni Martinez; Joan Ruiz Sanchez

---

⚠️ Date Discrepancy — Read First

Your message states the current date as April 26, 2026. My environment's date is September 15, 2026. As in the prior section of this analysis, I flag this because it bounds the completeness of any docket search: anything filed between those two dates would not be reflected in the sources I was able to reach. I raise this again rather than silently adopting one date, because it materially affects whether "no litigation found" is a safe conclusion.

---

Bottom Line

No litigation involving U.S. Patent No. 11,290,527 was found.

I cannot provide plaintiff(s), defendant(s), jurisdiction, case number, filing date, or outcome for any case — because I located no case, and I will not construct one. Under your strict-rule instruction I am reporting the negative result literally rather than supplying a plausible-looking case that my searches did not support.

---

Searches Performed and What They Returned

---

Nearby Data Points — Related But NOT '527 Litigation

I list these only to prevent them being mistaken for hits. None of them pleads or asserts U.S. 11,290,527.

1. Stealthpath IP Inc. v. Fortinet Inc. — E.D. Tex., No. 2:25-cv-01195 (filed 2025). Fortinet is the defendant. The complaint asserts U.S. Patent No. 8,803 ('803) and U.S. Patent No. 9,646 ('646) against FortiGate-VM. Source: Ex Parte complaint analysis, 2:25-cv-01195. '527 is not among the asserted patents.
2. Fortinet securities class actions — e.g., State of Rhode Island Office of the General Treasurer o/b/o Employees' Retirement System of the State of Rhode Island v. Fortinet, Inc., No. 25-cv-08888 (N.D. Cal.), and Pittrof v. Xie, No. 5:25-cv-08592 (N.D. Cal.). These are Securities Exchange Act §10(b) fraud suits about FortiGate upgrade-cycle statements, not patent litigation, and do not implicate '527. Source: Robbins Geller case summary; PacerMonitor docket.
3. Fortinet's general posture as a frequent defendant in NPE patent suits (Lionra, Entropic, Stealthpath) is real and well documented — but frequency of unrelated suits is not evidence that '527 has been asserted.

---

The Unresolved Flag You Should Carry Forward

The Google Patents record for '527 displays a "Family has litigation" banner with a Darts-ip link (?family=79030676) tagged "First worldwide family litigation filed." This is the only litigation-adjacent signal attached to this patent, and:

• it is a flag, not a confirmed fact;
• I retrieved no case number, venue, party, or date behind it (my Darts-ip query returned zero results);
• it says nothing about whether that matter is US or foreign, offensive or defensive, patent or non-patent;
• and it says nothing about any Federal Circuit activity.

Consistent with the prior section of this analysis, I treat this as a flag to investigate, not a finding.

---

Confidence and Recommended Verification

High confidence: No US district-court, ITC, PTAB, or CAFC proceeding involving U.S. 11,290,527 appears in the publicly indexed sources I could reach. The patent's family is a single-member US family (ID 79030676) with no foreign counterparts, which narrows the plausible litigation surface considerably — a foreign counterpart suit is largely foreclosed because no foreign counterpart exists.

Low confidence / unverified: (a) any proceeding filed between April 26, 2026 and September 15, 2026; (b) the substance behind the Darts-ip banner; (c) the Unified Patents portal caselist, which I could not complete.

To close these gaps authoritatively, check directly:

• USPTO PatentCenter / Assignment for application 16/916,237 (assignment history may reveal a transfer to an NPE — the usual precursor to assertion);
• PTAB API for any IPR/PGR on '527;
• CAFC docket and PACER for district-court filings;
• Unified Patents Portal caselist and Darts-ip for family 79030676.

I have not fabricated any case number, court, party, or outcome to fill these gaps.

I'll research this proceeding, starting with targeted searches for the specific IPR and related activity.

Let me dig deeper on the specific proceeding and the parties' ongoing dispute.

Let me run a few more targeted checks on this specific patent's assertion and the new IPR.

AIA Trial Proceedings — US 11,290,527 B2 ("Automatic tagging of cloud resources for implementing security policies")

Research cutoff: 2026-09-15. Several targeted queries (patent number + IPR2026-00473 + party names) returned no substantive content — consistent with a petition that is hours old. Everything below that is not in the structured USPTO Open Data Portal block is flagged as unverified.

---

Proceedings overview

One AIA trial proceeding is on file against US 11,290,527: a single IPR (IPR2026-00473, Netskope, Inc. as petitioner) that was filed 2026-09-15 and is still in its pre-institution "Pending" state — zero claims invalidated, zero sustained, zero settled, zero institution denials — which means the patent is currently untested at the PTAB and a defendant today can neither rely on prior cancellations nor ignore a live, sophisticated challenge that will likely be resolved sometime in 2027–2028.

---

IPR2026-00473 — Netskope, Inc. v. Fortinet, Inc.

• Type: Inter Partes Review (35 U.S.C. §§ 311–319)
• Filed: 2026-09-15 (same day as the structured-data snapshot and today's date)
• Status: Pending (verbatim from structured data). Plain-English gloss: the petition has been filed but has not yet been accorded a filing date notice, no Patent Owner Preliminary Response has been filed, and no § 314(a)/(b) institution decision has issued. Nothing has been decided on the merits.
• Judge panel: Unknown / not yet public. Under PTAB practice a panel is not designated until the institution decision; no panel information was retrievable and I will not speculate as to APJ names.
• Petition grounds: Unknown. The Office has not yet published the petition, its exhibit list, or the grounds. The challenged claim set, asserted references, and the statutory basis (§ 102 and/or § 103, and whether § 112 is pled) are all not retrievable as of the cutoff. For a patent with 20 claims (3 independent — 1, 8, 15), a typical Netskope-style petition would challenge some or all claims; I have no basis to state which.
• Institution decision: None yet. Statutorily the Board's institution decision is due within six months of the petition's filing date under 35 U.S.C. § 314(b), i.e., on or about 2027-03-15 (assuming the 2026-09-15 filing date is accorded).
• Final Written Decision: None. No FWD exists, so there are no claim-level cancellations, no surviving-claim holdings, and no panel reasoning to quote.
• Settlement / termination: None.
• Appeal: None. There is nothing appealable to the Federal Circuit; no CAFC docket number exists for this proceeding.
• Defensive value: This proceeding provides no immediate defensive ammunition against a current assertion — nothing is canceled and no estoppel has attached. Its value is prospective: it puts Fortinet on notice of a well-financed, repeat-player adversary attacking the '527 patent, and it signals that if you are also a target, coordinating/joining (or at minimum monitoring) this IPR is the single most efficient path to a validity ruling on this disclosure.

Key procedural facts I could NOT verify (do not treat as established): challenged claims, grounds/references, petitioner's real-parties-in-interest beyond "Netskope, Inc.," counsel of record, panel composition, and whether a Sotera-style stipulation accompanied the petition.

---

Strategic summary

Claim status: all 20 claims are UNTESTED. Because no institution decision and no FWD have issued, claims 1, 8, and 15 and every dependent claim (2–7, 9–14, 16–20) remain in force and presumptively valid. There are no canceled claims and no sustained claims to report. Any statement that claims 1–5 (or any other set) have been canceled by the PTAB would be false for this patent as of 2026-09-15.

Estoppel landscape: no estoppel exists yet. Section 315(e)(2) estoppel is triggered only by a final written decision; a merely pending, uninstituted petition creates none. Accordingly, a defendant currently facing assertion of the '527 patent faces no estoppel constraint today, and the full universe of § 102/§ 103 prior-art grounds (including art already in this petition, if you are not the petitioner) remains nominally available. Two practical caveats: (1) if you are in privity with Netskope, whatever grounds Netskope raised — or reasonably could have raised — will be estopped if a FWD issues; and (2) your own § 315(b) one-year bar runs from service of a complaint alleging infringement of '527, so any independent IPR must be filed within one year of service.

Pattern signals. This is a single, freshly filed IPR — the first AIA challenge ever filed against the '527 patent; there is no multi-petition pattern against this patent. The broader picture, however, is an intense, reciprocal Netskope–Fortinet patent war in which both sides are serial IPR filers. Netskope previously filed a coordinated campaign against Fortinet patents (e.g., IPR2022-01587 and IPR2023-00030/-00175/-00456/-00457/-00458, several of which Fortinet's own court filings characterize as resulting in independent-claim cancellations on the '968 and '825 patents — treat that characterization as a party's position, not an adjudicated fact I verified). More recently, Fortinet filed roughly seven petitions against Netskope's asserted patents in October 2025 (IPR2026-00025 through -00042), several of which drew Director discretionary denials in early 2026 (e.g., IPR2026-00026 denied 2026-01-27; IPR2026-00031 denied 2026-02-03). IPR2026-00473 appears to be Netskope's counter-volley against a Fortinet patent. No defensive aggregator (e.g., Unified Patents) appears in the chain for this proceeding — the petitioner is a direct market competitor, not a proxy.

Contradiction flag (per instructions): The earlier-generated patent summary stated that no litigation was found and that the Google Patents "Family has litigation" (Darts-ip) banner was unverified. My searches surfaced an extensive Netskope–Fortinet docket in N.D. Cal. (e.g., 3:22-cv-01852; 4:25-cv-02360-HSG; a 2026 Fortinet v. Netskope action, 4:26-cv-08886). That resolves the banner's plausibility but does not confirm that the '527 patent is itself asserted in any of those cases — I could not verify '527 is in suit. The presence of a Netskope IPR against it strongly suggests an assertion trigger, but I state that as inference only.

---

Recommended next steps

• If you are a defendant facing a '527 demand or suit: you cannot yet point to any canceled claim — none exist. Do not represent that IPR2026-00473 has invalidated anything. Instead, confirm whether the '527 patent is among the patents asserted in the Netskope–Fortinet litigation and whether you may be bound by, or benefit from, that IPR.
• Watch the trial-stage clock. Because the petition was filed 2026-09-15, the milestones are: Patent Owner Preliminary Response due at the statutory three-month mark (≈ 2026-12-15); Board institution decision due within six months of filing (≈ 2027-03-15) under § 314(b); and if instituted, a Final Written Decision within 12 months of institution (≈ 2028-03-15) under § 318(a), extendable for good cause. Monitor via the USPTO PTAB E2E / Patent Trial and Appeal Board End-to-End system and the PatentCenter docket for application 16/916,237.
• Preserve your own options: run a § 315(b) date-certain on the day you were served with any complaint alleging '527. Absent privity with Netskope, you may file your own IPR within that one-year window; alternatively, consider a § 315(c) joinder motion if the Board institutes IPR2026-00473.
• Track for a POPR and institution decision. The Patent Owner's Preliminary Response will reveal Fortinet's claim-construction positions and any discretionary-denial arguments (Fintiv / § 325(d) / settled expectations). Fortinet has litigated these patents hard for years, so expect a substantive POPR and, potentially, a request for Director discretionary denial — the same dynamic that produced denials in the parallel Fortinet-v.-Netskope petitions.
• No CAFC activity to report. Nothing has been appealed from this proceeding because nothing has been decided. For any future FWD, the Federal Circuit docket and CourtListener will be the authoritative sources.

Bottom line for a current defendant: the patent is hardened by default (all claims live, no estoppel, no adverse PTAB record) but is now actively under attack by a capable competitor. Plan for a validity fight on the merits in district court in the near term, with the possibility of a PTAB ruling on the same claims in 2027–2028 — not for immediate reliance on a cancellation that has not happened.

I'll research the assignment record for this patent.

Assignment & Ownership Analysis — US 11,290,527 B2

Cross-reference note (resolved): The previously generated summary flagged a date discrepancy between "April 26, 2026" and the environment date. The current task header confirms 2026-09-15, so the environment date governs. This affects nothing in the ownership record below, which shows no activity after 2025-09-29 regardless.

Critical source limitation, stated up front: My searches against the USPTO Assignment Search index (assignmentcenter.uspto.gov / assignment.uspto.gov), Google Patents legal events, and third-party mirrors returned no reel/frame-level record content for application 16/916,237 or patent 11,290,527. Every query returned either empty result sets or generic "how to search assignments" guidance. I therefore cannot report reel/frame numbers, execution dates, or the recording correspondent for any assignment on this patent. I am not filling those gaps with plausible-looking numbers. What is confirmed from the authoritative full text provided is that exactly one post-filing conveyance is indexed on the Google Patents legal-events timeline (2020-06-30, ASSIGNMENT OF ASSIGNORS INTEREST), and no post-issuance conveyance appears anywhere in that record.

---

Inventors

• Residence: The earlier generated section attributed both inventors to Barcelona, ES. I could not independently verify inventor residence from the authoritative patent text provided (no inventor addresses appear in it), so I carry that forward as unverified rather than confirmed.
• Departure pattern: Unclear / no data. There is no public record in the sources I retrieved showing either inventor leaving Fortinet within 12 months of the 2020-06-30 filing. Absence of evidence here is genuinely absence of data, not a negative finding — inventor-employment tracking at this granularity typically requires LinkedIn or filings, which I did not retrieve. The classic "all inventors exit within 12 months → fire-sale" precursor is neither present nor ruled out.
• Co-inventor count and breadth: Two inventors, both Barcelona-based (per the earlier section), on a single-application US-only family. No continuation, CIP, or divisional is listed in the family record. This is a small, self-contained prosecution — typical of a product-feature capture inside a large portfolio rather than a portfolio-building campaign.

---

Original assignee

Fortinet, Inc. (Sunnyvale, CA) — named on the issued patent as both original and current assignee.

• Primary line of business: Network security. Fortinet is a publicly traded cybersecurity vendor (NASDAQ: FTNT) whose product lines include the FortiGate next-generation firewall / UTM appliance family, FortiManager (centralized management), FortiAnalyzer, FortiSIEM, and the FortiGuard cloud security services. The patent's own specification explicitly names several of these: the FORTIGATE, FORTIMANAGER, and FORTIANALYZER families and the "FORTIGUARD security services available from assignee of the present invention."
• Did they ship a product embodying the claims? Yes, on the face of the specification. The claimed cloud-tagging orchestrator running on a "security manager" maps directly onto Fortinet's management-plane products — the spec describes the security manager as implementable as an on-premises management appliance or a cloud service, and expressly frames the orchestrator as managing "resources on private cloud services (VMWare ESXi/NSX, OpenStack, Kubernetes or Cisco ACI), public cloud services (AWS, Microsoft Azure, GCP and Oracle)." That is a description of FortiManager/FortiCNF-class functionality plus FortiGate enforcement of tag-referenced policy. This is a product-backed patent, not a paper patent.
• Current status: Operating and financially healthy. Fortinet is an active public company; the patent's maintenance-fee record corroborates ongoing commercial interest — the 4th-year maintenance fee was paid 2025-09-29 as a large entity (M1551), and the patent is Active with an adjusted expiration of 2040-09-24 (PTA-adjusted). No bankruptcy, receivership, or dissolution event appears.
• Litigation posture (operating-company, not NPE): Fortinet is itself an experienced patent plaintiff against competitors in the firewall/UTM space. That is the opposite polarity from an NPE chain, but it matters for signal 5 below: Fortinet asserting its own patents directly is normal operating-company behavior.

---

Assignment timeline

Record count: one (1) confirmed indexed conveyance. No post-issuance assignments retrieved.

• 2020-06-30 (executed) / recorded 2020-06-30 — Reel not retrievable from available sources
  • Conveyance: Assignment of assignors' interest (Google Patents legal-events code: AS; description "ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS)")
  • Assignor: Ignacio Franzoni Martinez; Joan Ruiz Sanchez (joint inventors)
  • Assignee: FORTINET, INC.
  • Correspondent: Not retrievable. The prior generated section separately identified the prosecution attorney/agent of record as the Law Office of Dorian Cartwright (San Jose, CA). Whether that firm is also the recording correspondent on the assignment cover sheet cannot be confirmed from the sources I reached; I will not assert it as a fact. If it is, note that Dorian Cartwright is a high-volume Fortinet prosecution firm and its appearance would be a firm-level recurrence across Fortinet's portfolio, not an NPE tell — routine prosecution outsourcing, not a shell-entity switchboard.
  • Context: Original inventor-to-employer assignment. Executed and recorded on the filing date itself, i.e., recorded contemporaneously with or before the 2020-06-30 filing of application 16/916,237. This is the standard obligation-to-assign capture at filing — not an acquisition, fire-sale, securitization, reorg, or transfer-to-asserter.
• 2022-03-29 — Patent issues to Fortinet, Inc. (not an assignment; recorded here only as the title-confirming event)
• 2025-09-29 — 4th-year maintenance fee paid, large entity (not an assignment; corroborates continued Fortinet ownership and commercial maintenance)

Nothing further is recorded. No security agreement, no license recordation, no merger, no change of name, no release, no correction, and — decisively — no conveyance out of Fortinet.

---

Timeline diagram

timeline
    title Ownership of US 11290527
    2020 : Inventors assign to Fortinet Inc
         : Application filed
    2022 : Patent issued to Fortinet Inc
    2025 : Fourth year maintenance fee paid

---

NPE / troll-pattern signals

Threshold issue: With a single recorded link — inventors → Fortinet — most of these tests are not merely "not present," they are inapplicable, because they presuppose a chain. I distinguish the two.

---

Verdict

Insufficient data — applying the rubric literally: the record consists of only the original assignment, which the instructions define as the "insufficient data" case.

That said, I want to be explicit that "insufficient data" here does not mean "suspicious but underdocumented." On every signal that can be evaluated, the answer is negative: the single recorded conveyance is the 2020-06-30 inventor-to-employer assignment to FORTINET, INC., executed and recorded on the filing date of application 16/916,237, with no subsequent assignment, security interest, merger, name change, or transfer of any kind; the assignee is a publicly traded operating cybersecurity vendor (NASDAQ: FTNT) that demonstrably ships products practicing the disclosed subject matter, as its own specification attests; and the patent remains Active with an adjusted expiration of 2040-09-24 and a 2025-09-29 large-entity maintenance-fee payment on record. There is no NPE pattern to report, and no shell entity, known asserter, repeat NPE correspondent, cascade, pre-suit transfer, bankruptcy sale, privateering arrangement, or defensive-aggregator terminus anywhere in the chain. If a future transfer to a licensing entity is recorded, the reel/frame and correspondent fields — not the entity name — will be where the tell first appears.

Verify directly (I could not retrieve these):

• USPTO Patent Assignment Search — https://assignment.uspto.gov/patent/index.html (search by patent number 11290527, application 16/916,237, or assignee Fortinet)
• USPTO Assignment Center — https://assignmentcenter.uspto.gov/
• USPTO PatentCenter for application 16/916,237 (assignment tab + prosecution file wrapper)
• Google Patents legal events — https://patents.google.com/patent/[US11290527B2](/patent/US11290527B2)/en

What to capture when you pull the record: the reel/frame of the 2020-06-30 conveyance, the execution date on its face (which may precede the 2020-06-30 recording date), and the correspondent of record on that cover sheet. Those three fields are the only gaps in the above analysis, and none of them can change the NPE verdict — a single inventor-to-operating-company assignment cannot constitute an NPE chain.

I'll verify the patent record and pull details on the key cited references before building the § 102 analysis.

Prior-Art Analysis — U.S. Patent No. 11,290,527

Subject: US 11,290,527 B2 — "Automatic tagging of cloud resources for implementing security policies"
App. No.: 16/916,237 | Filed/Priority: 2020-06-30 | Granted: 2022-03-29 | Assignee: Fortinet, Inc.
Task date: April 26, 2026
ID verification: Confirmed. Searches on the literal string 11290527 resolve to the Fortinet patent above (Google Patents, USPTO.report, Justia, patentsencyclopedia, FreePatentsOnline, and the enSilo/Fortinet corporate records). Near-miss identifiers that surfaced in raw search results — e.g. US 11,697,028 (Sun Pharmaceutical) and the EP document EP2458319A1 — are excluded as non-matching. Consistent with the earlier litigation section, I carry forward the date caveat (your stated 2026-04-26 vs. my environment date 2026-09-15) — it does not affect the prior art below, which is all dated well before the 2020-06-30 critical date.

---

1. Legal framework applied

The '527 patent's effective filing date is June 30, 2020 (no earlier priority claim, no foreign priority). Because that is after March 16, 2013, the AIA first-inventor-to-file provisions govern. The two applicable § 102 subsections are:

• § 102(a)(1) — the reference was patented, described in a printed publication, or in public use before 2020-06-30 (date of publication/grant controls).
• § 102(a)(2) — the reference is a U.S. patent or U.S. application publication that names another inventor and was effectively filed before 2020-06-30 (filing/priority date controls, regardless of its publication date).

A methodological catch worth stating up front: one examiner-cited reference — US 2020/0322442 A1 — published 2020-10-08, which is after the '527 filing date. It is therefore not § 102(a)(1) art on its face; it can only operate as § 102(a)(2) art as of its 2019-04-04 filing date. The same logic applies to US 10,721,141 B1 (granted 2020-07-21) and US 10,908,917 B1 (granted 2021-02-02), both of which post-date the critical date and qualify only under § 102(a)(2).

Anticipation vs. obviousness caveat. Strict § 102 anticipation requires a single reference to disclose every element of the claim as arranged. As shown below, no single cited reference appears to disclose all elements of independent claim 1, 8, or 15 — most notably the combination of (a) a cloud-tagging orchestrator service running on a security manager associated with a private network, (b) unified tag identification under a pre-defined global tagging policy, and (c) assignment back through the hosting provider's API. The realistic posture of these references is § 103 combination art, with a few strong § 102 candidates for individual elements. I flag this rather than overstating anticipation. Confidence in the element-mapping is moderate — it rests on the citation list, titles, abstracts, and retrieved excerpts, not a full claim-chart review of every reference's complete specification.

Note on citation provenance: per the Google Patents record, all 21 patent citations are examiner-cited (marked *). There are no third-party (†) citations in the list, and 2 non-patent citations.

---

2. Master table — all 21 cited references + 2 NPL

Dates are taken verbatim from the authoritative record. "§102 basis" reflects the analysis in §1.

---

3. Expanded analysis — the most relevant references

I group the references into tiers. Tier 1 contains the references that actually go to the inventive core — cross-provider unified tagging tied to security policy.

TIER 1 — Directly on point

A. US 2018/0123904 A1 — ServiceNow (Thakrar et al.)

Full citation: US 2018/0123904 A1, "System and method of associating metadata with computing resources across multiple providers," ServiceNow, Inc. — filed/priority 2016-11-02 (provisional 62/416,520, 2016-11-02); published 2018-05-03. Family members include US 10,547,519 B2 (granted 2020-01-28), US 11,025,507 B2, US 11,637,759 B2, and US 2021/0273859 A1.
Disclosure: Discovery of resources across multiple providers, agnostic to which provider hosts them; associating declarative tags or other metadata; a user interface that maps a generic displayed metadata value to a provider-specific value — expressly "corresponded to a provider-specific value via a respective API of the provider." It also addresses the precise problem the '527 patent recites: providers "may fail to use all of the desired metadata or may use metadata in different or inconsistent fashions."
Potentially relevant claims: 1, 8, 15 — this is arguably the closest single reference to the receive-info → identify a cross-provider tag → assign via the hosting provider's API sequence, and it also touches dependent claims 3, 10, 17 (multi-provider/multi-cloud). However, two gaps cut against strict § 102 anticipation of claim 1: (i) it lacks the "cloud-tagging orchestrator service running on a security manager associated with a private network" actor, and (ii) its tag selection is user-driven via a GUI dropdown, not "identified … based on a pre-defined global tagging policy." It also does not tie tagging to security-policy enforcement. Realistic role: strong § 103 primary reference; § 102 anticipation only if a claim construction reads "cloud-tagging orchestrator service"/"pre-defined global tagging policy" very broadly.

B. US 2018/0234459 A1 — Kung (Lisun Joao Kung)

Full citation: US 2018/0234459 A1, "Automated Enforcement of Security Policies in Cloud and Hybrid Infrastructure Environments," inventor Lisun Joao Kung — filed/priority 2017-01-23; published 2018-08-16. Family: US 10,721,275 B2; continuations US 11,575,712 B2 and US 11,962,622 B2 (FireEye Security Holdings US LLC).
Disclosure: A contextual security platform for hybrid cloud (private + public cloud infrastructure) that automatically enforces security policies using native mechanisms. Critically, its figure set includes FIG. 8 "discovering and applying tags for resources," FIG. 9 "assigning an attribute to a resource," FIG. 10 "automated assignment of tags … based on discovered tags or resource properties," FIG. 11 "indirect assignment of tags based on logical group membership," and FIG. 12 "assignment of attributes across organizations." It queries cloud-provider APIs to obtain resource attributes (e.g., IP addresses of nodes/workload units).
Potentially relevant claims: This is the most substantive reference on the security-policy side of the invention, mapping to independent claims 1, 8, 15, and to dependent claims 2/9/16 (security policy enforcement), 3/10/17 (hybrid multi-cloud), 5/12/19 (tag identification based on resource info/properties), 6/13/20 (VM/workload resources), and 17 (visibility/control). Gaps for strict anticipation: the "unified tag" cross-cloud vocabulary and the "cloud-tagging orchestrator service on a security manager" framing are not mirrored in the terminology; the reference is policy-enforcement-centric rather than unified-namespace-centric. Realistic role: primary § 103 reference, with strong § 102-type disclosure of the "automatic tag application + security policy in hybrid cloud" sub-combination.

C. US 2020/0322442 A1 — IBM (Luo et al.)

Full citation: US 2020/0322442 A1, "Multi-dimensional tagging namespace for cloud resource management," International Business Machines Corp. — filed 2019-04-04; published 2020-10-08; granted as US 10,972,567 B2 (2021-04-06).
Disclosure: A structured tagging namespace (≥2 dimensions) into which a set of tags for a cloud resource is received and verified; alerts on tag/position mismatch; the multi-dimensional tag metric is then used to scale, migrate the resource from a first cloud platform to a second, or balance across platforms. Its background expressly states that "some cloud resource providers have tag/label naming rules specific to that provider, [and] there are no uniform techniques to manage tags/labels" — the same problem the '527 patent identifies.
Potentially relevant claims: 1, 8, 15 (unified/cross-provider tag identification and assignment), plus 3, 10, 17 (cross-platform movement), 5, 12, 19 (tag placement/attributes), 17 (visibility).
Critical date caveat: published after the '527 filing date → only § 102(a)(2) art as of 2019-04-04. Also note the reference is not security-policy focused and operates on tags received into a namespace rather than assigned back out through a provider API — a gap for full anticipation. Realistic role: § 103 reference for the "unified tag across providers" element.

D. US 10,594,730 B1 — Amazon (Summers et al.)

Full citation: US 10,594,730 B1, "Policy tag management," Amazon Technologies, Inc. — filed 2015-12-08; granted 2020-03-17.
Disclosure: Tags "automatically applied" at various times; a customer provides an auto-tagging configuration file used to determine tags to be applied to specific data objects based upon … properties of those objects; each tag is associated with a policy stating which actions may be performed. Auto-tagging can trigger on storage, on modification of the auto-tagging configuration, or on access request.
Potentially relevant claims: 1, 8, 15 (automatic tag identification from properties/configuration — i.e., a rules-based tag policy), and especially 2, 9, 16 (security/action policy tied to tags) and 5, 12, 19 (tagging keyed to resource information).
Gap: It is single-provider, data-object-level (not cross-cloud resource unification), so it does not reach the multi-cloud "unified tag" element. Realistic role: § 103 reference, strongest as to dependent claim 2 and the "pre-defined policy determines the tag" limitation.

TIER 2 — Relevant to discrete elements

E. US 2021/0176191 A1 — Micro Focus, "Recommendation engine for resource tagging" — filed 2019-12-06, published 2021-06-10 (§ 102(a)(2) only). A recommendation engine that proposes/recommends tags for resources → maps to the "identifying a unified tag … based on a pre-defined global tagging policy" step of claims 1, 8, 15 and to 5, 12, 19. Gaps: recommendation (human-in-loop) rather than automatic assignment, and no cross-cloud API push. § 103 art on the identifying/tag-selection element.

F. US 9,934,269 B1 / US 10,496,692 B1 — Amazon, "Resource tagging and grouping" — both filed 2015-03-17; granted 2018-04-03 and 2019-12-03 respectively. A resource-groups service letting users "view and access collections of computing resources that share common resource tags and/or other attributes." Maps to claims 1, 8, 15 (resource tagging/grouping) and 2, 9, 16 (policy application by tag). Single-provider scope → § 103 art. Note the IBM reference (C) itself cites US 9,934,269 as background, indicating the tagging/grouping concept was well known by 2019.

G. US 2015/0350103 A1 — IBM, "Managing information technology resources using metadata tags" — filed 2014-05-27, published 2015-12-03. Metadata-tag management of IT resources → claims 1, 5, 8, 12, 15, 19.

H. US 2016/0042031 A1 — IBM, "Performing actions on objects as a result of applying tags to the objects" — filed 2014-08-05, published 2016-02-11. Actions/policies triggered by applied tags → claims 2, 9, 16 (the "apply a security policy with reference to unified tags" limitation).

I. US 10,277,522 B1 — Amazon, "Automated association of computing resources with resource creators for usage allocation" — filed 2014-11-26, granted 2019-04-30. Automated tag association of resources → claims 1, 5, 8, 15, 19.

J. US 10,409,551 B1 — Amazon, "Voice-driven monitoring of resources in a service provider network" — filed 2016-06-21, granted 2019-09-10. Resource monitoring across a provider network → claims 1, 4, 8, 11, 15, 18 (visibility/control).

K. US 10,721,141 B1 — Amazon, "Resource lifecycle automation" — filed 2017-11-29, granted 2020-07-21 (§ 102(a)(2) only). Orchestration/lifecycle automation of resources → claims 1, 4, 8, 11, 15, 18.

L. US 2019/0149436 A1 — Bespin Global, "Service resource management system and method thereof" — filed 2017-11-10, published 2019-05-16. Multi-cloud service resource management → claims 1, 3, 8, 10, 15, 17.

M. US 10,908,917 B1 — EnvZero, "System and method for managing cloud-based infrastructure" — filed 2020-02-26, granted 2021-02-02 (§ 102(a)(2) only). Cloud-infrastructure management → claims 1, 3, 8, 10, 15, 17.

N. US 2006/0026141 A1 — Microsoft, "Uniform resource discovery with multiple computers" — filed 2004-02-20, published 2006-02-02. Cross-system resource discovery → claims 1, 8, 15 (the discovery/receiving-information step). Very early; background.

O. US 2014/0006627 A1 — IBM, "Instantiating resources of an IT-service" — filed 2012-06-27, published 2014-01-02. Resource instantiation → claims 1, 6, 8, 13, 15, 20 (VM/compute resources).

P. US 2018/0302275 A1 — IBM, "Configuration management in a stream computing environment" — filed 2017-04-12, published 2018-10-18. Configuration management → claims 1, 8, 15 (marginal).

Q. US 10,379,838 B1 — Amazon, "Update and rollback of code and API versions" — filed 2017-06-28, granted 2019-08-13; R. US 2021/0064453 A1 — Fujitsu, "Automated application programming interface (API) specification construction" — filed 2019-09-03, published 2021-03-04 (§ 102(a)(2) only). Both appear to be cited for the API-interaction aspect of claims 1, 8, 15. Marginal.

S. US 10,417,593 B1 — VCE IP Holding, "System and method for comparing computing resource offerings" — filed 2014-12-31, granted 2019-09-17. Resource-offering comparison → claims 1, 8, 15 (marginal).

T. US 2013/0006865 A1 — McKesson Financial Holdings, "…network-accessible patient health records" — filed 2011-06-29, published 2013-01-03. Only tangentially related domain; likely cited as generic evidence of metadata/record association → claims 2, 9, 16 (weak).

---

4. Non-patent literature

NPL-1 — AWS, "Tagging Best Practices: Implement an Effective AWS Resource Tagging Strategy," Dec. 2018 (24 pp.). § 102(a)(1) printed publication (Dec. 2018, before 2020-06-30). Establishes that establishing and enforcing a resource-tagging strategy, with naming conventions and tag policies, was known and documented practice → bears on claims 1, 5, 8, 12, 15, 19. Scope is within AWS, so it does not itself teach cross-cloud unification; it is § 103 foundational art for the "pre-defined global tagging policy" concept.

NPL-2 — DivvyCloud, "Multi-Cloud Tagging Strategies for the Win," Oct. 14, 2019 (21 pp.), available at https://divvycloud.com/tagging-strategies-importance-and-utility-of-tagging-cloud-resources/ (URL as listed on the record). § 102(a)(1) printed publication. This is the most on-point NPL: it directly addresses tagging strategy across multiple clouds. It bears on independent claims 1, 8, 15 and on dependent claims 3, 10, 17 (hybrid/multi-cloud). As a printed publication describing the problem and general approach, it is § 103 art and, depending on the specificity of its disclosure, a potential § 102(a)(1) candidate for the multi-cloud-tagging element.

---

5. Bottom-line assessment

1. No single cited reference clearly anticipates independent claims 1, 8, or 15 in full. The claimed combination — a cloud-tagging orchestrator service on a security manager that identifies a unified tag under a pre-defined global tagging policy and assigns it back through the hosting provider's API — is not mirrored in one reference. Anticipation, if any, would have to come from a broad claim construction; otherwise the art is § 103 combination evidence.

2. The strongest prior-art pairing is:

• US 2018/0234459 A1 (Kung) or US 10,721,275 B2 (its granted form) for the automatic tag application + hybrid-cloud security policy concept; combined with
• US 2018/0123904 A1 (ServiceNow) for the cross-provider metadata/tag mapped through each provider's own API concept;
• optionally US 10,594,730 B1 (Amazon) and/or US 2021/0176191 A1 (Micro Focus) for automatic tag determination from resource properties/a policy.
  Together these cover every element of claim 1, which is the classic § 103 posture.

1. Best § 102 candidates for discrete dependent claims: US 10,594,730 B1 (claim 2 — action policy tied to tags) and US 2016/0042031 A1 (claim 2 — actions on objects as a result of applied tags); the AWS and DivvyCloud NPL for the "pre-defined tagging policy" limitation (claims 1/5).

2. Date traps to watch: US 2020/0322442 A1, US 10,721,141 B1, US 10,908,917 B1, US 2021/0064453 A1, and US 2021/0176191 A1 all post-date 2020-06-30 in publication/grant and are § 102(a)(2)-only art, effective as of their earlier filing dates. Any validity challenge that cites them must plead the (a)(2) basis correctly.

3. Confidence: I have high confidence in the citation list, the dates (taken verbatim from the record), and the (a)(1)/(a)(2) classification. I have moderate confidence in the per-claim element mapping for Tier 1 references, which is based on titles/abstracts/retrieved excerpts rather than a full specification-and-claim review of each reference. I have not verified the complete disclosure of the Tier 2/3 references (N–T) beyond title/abstract level, and I did not retrieve the Micro Focus reference text (the search tool returned a step-limit message on that query). I have not fabricated any disclosure, date, or claim mapping.

I'll ground the key prior-art references before mapping them to the claims.

Let me verify a few more of the cited references to ground the combination analysis.

Obviousness Analysis — U.S. Patent No. 11,290,527 B2

Automatic Tagging of Cloud Resources for Implementing Security Policies

35 U.S.C. § 103 | AIA first-inventor-to-file regime (effective filing 2020-06-30) | Prepared 2026-04-26

---

0. Scope note and a flag

This analysis uses only the prior art listed on the patent's own record — the 21 U.S. patent documents and 2 non-patent citations in the "Citations" section, cross-checked against the "Prior art keywords" the examiner catalogued (cloud, resource, unified, tagging, resources).

Two housekeeping points before the substance:

• Date discrepancy (carried forward, now immaterial). Your stated date is April 26, 2026; my environment reports September 15, 2026. For § 103 purposes this is irrelevant — every reference on the list has a publication or effective filing date on or before 2020-06-30, and none of my combinations depend on anything dated between those two 2026 dates. The discrepancy mattered for the litigation sections; it does not matter here.
• Verification status of reference contents. I retrieved and read the full text of ServiceNow US 2018/0123904 A1 (and its continuation US 2021/0273859 A1), Amazon US 10,594,730 B1, IBM US 2020/0322442 A1 (and granted sibling US 10,972,567), Kung US 2018/0234459 A1 (and continuation US 10,721,275), and the DivvyCloud white paper. For the remaining references I am working from the titles, dates, and assignees as listed in the '527 record itself — I flag that explicitly rather than asserting what those documents say. Titles are sufficient to establish that a reference is in the field, but a full-text pull would be needed before relying on any of them as a primary reference.

---

1. The governing legal framework

The '527 patent has an effective filing date of June 30, 2020, so the AIA version of § 103 applies, and the prior-art universe is defined by § 102(a)(1) (publicly available before 2020-06-30) and § 102(a)(2) (U.S. patent documents effectively filed before 2020-06-30 but published later).

The controlling obviousness standard is KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007), applied through the Graham v. John Deere factors. The practical consequence of KSR for this patent is significant: the Federal Circuit and the Board routinely uphold § 103 rejections in the cloud-management space where the claimed advance is automating, centralizing, and standardizing functions that the industry already performed manually and per-provider. A claimed combination of known elements is obvious where (i) the elements existed in the prior art, (ii) the combination yields no more than predictable results, and (iii) there was an articulated reason — a design incentive, market pressure, or an express statement of the problem — to make the combination.

Here, the third prong is not merely available; it is written out in the prior art itself, as shown in § 5 below.

Level of ordinary skill in the art (PHOSITA)

A person having ordinary skill in the art as of June 2020 would be a software/systems engineer with roughly a bachelor's degree in computer science or a related field and 3–5 years of experience in cloud infrastructure management, infrastructure-as-code, or network security management — including hands-on familiarity with the tag/label APIs of at least two major cloud providers (AWS, Azure, GCP) and with policy-driven configuration management. This is a modest skill level. The claimed subject matter is squarely administrative/architectural cloud automation, not an algorithmic or hardware advance.

---

2. The claim 1 elements, decomposed

Claim 1 is the anchor; claims 8 and 15 recite the same sequence in medium and system form. Decomposed:

The critical observation for § 103: elements A–E contain no algorithmic limitation, no non-conventional data structure, no hardware modification, and no asserted unexpected result. Every step is a call to a cloud provider's documented public API plus a lookup. The claimed "invention" is the placement and sequencing of those calls — orchestration architecture — which is exactly the category of subject matter KSR holds is obvious when the components are known and the result is predictable.

---

3. Prior art inventory and its § 102 status

3(a) § 102(a)(1) art — publicly available before 2020-06-30 (all candidates for primary reference)

3(b) § 102(a)(2) art — effectively filed before 2020-06-30, published later

Non-prior-art context (post-filing, flagged to avoid misuse): the "Families Citing" list includes Dell US 12,423,279 B2, "User-configurable autotagging policies," priority 2023-08-31. This is not prior art against '527 and cannot be used in a § 103 combination. I mention it only because it confirms the field's trajectory was toward more policy-driven auto-tagging, not away from it — which undercuts any argument that the '527 approach was a departure from the art's direction.

---

4. What the verified references actually disclose

4.1 ServiceNow US 2018/0123904 A1 (Thakrar et al.) — the primary reference

This is the closest art, and its disclosure is uncomfortably close to claim 1. Verified text:

• Multi-provider scope, provider-agnostic: "when resources or computing infrastructure are provisioned by multiple providers, the providers may fail to use all of the desired metadata or may use metadata in different or inconsistent fashions." And: "This identification can be agnostic in the sense that resources are identified regardless of their provider or the provider of the platform on which they run." — [Element B]
• Discovery / retrieval: the system "can perform discovery of a computer network to identify resources on the network" and can identify those "that have missing or incomplete metadata." — [Element C]
• A normalized, provider-independent metadata value: the interface shows a canonical value that "may correspond to a value 'meta-542' with respect to a provider ... as well as to 'metadata 542' with respect to another provider." — this is a unified tag by another name. — [Element D]
• The killer sentence: *"'Correspond' can mean converted to, mapped to, looked up by provider, or the like. The displayed value 'METADATA 1' can be corresponded to a provider-specific value via a respective API of the provider."* — this is assigning a unified tag to a cloud resource via an API of the hosting provider, verbatim in substance. — [Element E]
• Bulk application: "an implementation permits the user to associate, in bulk, the selected tag (e.g., 'payroll') to the selected resources." — automation of the assignment across many resources.
• A predetermined tag vocabulary: "Selecting the metadata descriptor ... may generate a listing of a predetermined metadata that may include at least one of: providers; cost centers; departments; projects; services; applications; and users." — a plural set of candidate unified tags. — [Element D]

What ServiceNow '904 does not expressly supply: element A's "security manager" framing, and the downstream security-policy application recited in claims 2/9/16. ServiceNow is an ITOM/CMDB platform (IT operations management), not a security appliance. Its tag-selection step is also portrayed as UI/user-driven rather than rule-engine-driven — which is the patent owner's best, and only, meaningful point of distinction against this reference.

4.2 Kung US 2018/0234459 A1 — the security dimension

Verified disclosures that supply exactly what ServiceNow lacks:

• A "contextual security platform" implemented "as software running on a computer server in communication with various security mechanisms native to an organization's or enterprise's data network infrastructure" — a security manager-class component on an enterprise network. — [Element A]
• It "support[s] applications within hybrid computer network infrastructures having both traditional hardware resources and virtual resources provided by private and public cloud infrastructure services providers." — the hybrid multi-cloud environment of dependent claims 3/10/17.
• Figure 8 is captioned "a flow chart illustrating a representative process for discovering and applying tags for resources"; Figure 10 is "automated assignment of tags by a computer network security application based on discovered tags or resource properties"; Figure 11 is "indirect assignment of tags based on logical group membership." — [Elements C and D] (automated, rule-based tag identification, not merely manual UI selection — this closes the gap left by ServiceNow).
• API-based interaction with the provider: "The IP address of the node can be obtained by different mechanisms: 1) It can be queried using the cloud provider API if the node is hosted on a public or private cloud provider..." and the platform "configur[es] native security mechanisms that are part of that resource by sending messages to the agent." — [Element E]
• A persistent model database — "The system model database stores the application and infrastructure information needed by the context security platform. These include the list of managed compute environments and the available network security enforcement mechanisms in each one of them" — the '527 storage database of claims 2/9/16.
• Tag-keyed security policy — the platform maps application-level policy to network-level rules "based on ... the properties of the computing resources hosting the application," and the reference expressly frames tags as the bridge (FIGS. 8–12).

4.3 Amazon US 10,594,730 B1 — policy-driven automatic tagging

Verified: "Data tags ... can be automatically applied at appropriate times in a resource environment. A customer can provide an auto-tagging configuration file that can be used to determine tags to be applied to specific data objects based upon, for example, properties of those objects. The customer can also provide policies that indicate which actions can be performed for those objects based at least in part upon the applied tags."

This is the pre-defined global tagging policy → unified tag → policy enforcement chain in the data-object context. It supplies the automation and policy dimensions in full, and its auto-tagging is triggered "upon storage into the environment, upon modification of the auto-tagging configuration, or upon modification [of] the data object" — the periodic/on-demand push-back the '527 specification describes.

4.4 IBM US 2020/0322442 A1 — the express statement of the problem (§ 102(a)(2) art)

Verified, and this is the single most damaging passage for obviousness because it is a statement of the problem the '527 patent claims to solve:

"In a cloud native environment, tags and labels are becoming increasingly more common for managing various types of resources. ... While some cloud resources providers have tag/label naming rules specific to that provider, there are no uniform techniques to manage tags/labels. This generally results in users or the enterprises for which they work creating user or enterprise-specific tag-naming conventions and/or other tag policies in order to maintain consistency between tags. However, when these self-imposed naming conventions and policies are not strictly followed ... the cloud environment can be left susceptible, for example, to service interruptions and other failures."

Compare the '527 Background: "different cloud providers may use inconsistent tag naming conventions, resulting in similar resources being tagged in a disparate manner across a multi-cloud environment and complicating definition and/or implementation of security policies."

These are the same statement of the same problem. IBM '442 is § 102(a)(2) art (effective filing 2019-04-04, published 2020-10-08), so it is available both as prior art and as evidence of the ordinary artisan's knowledge and the recognized design direction. IBM '442 also discloses a structured namespace with positions, positions "associated with a set of properties controlling a category of tag eligible to be placed in that position," verification, alerting, and cross-platform tasks including "migrating the resource from a first cloud platform to a second cloud platform."

4.5 The non-patent literature

• AWS "Tagging Best Practices" (Dec. 2018) — teaches standardized, governed tag taxonomies, tag naming conventions, and organization-level tag policies enforced across accounts. This is the industry-standardization literature that makes a global tagging policy the natural design choice.
• DivvyCloud, "Multi-Cloud Tagging Strategies for the Win" (Oct. 14, 2019) — verified to teach tagging cloud resources across multiple cloud platforms (AWS, GCP, Azure, OpenStack), to note that untagged resources leave "no hint as to what security controls or compliance standards need to be verified," and to describe security professionals "drill[ing] down into any affected network, based on tags identified in log files by suspicious traffic patterns." This supplies the motivation to unify tags across clouds for security purposes, in an express, pre-filing publication.

Note: the DivvyCloud "Tagging Strategies" white paper is dated earlier (2017) in the copy I retrieved. The '527 record cites the October 14, 2019 blog installment. Both pre-date the filing; the point stands either way.

---

5. Element-by-element claim chart for claim 1

Result: every element of claim 1 is disclosed, and the only element not squarely disclosed by any single reference (A's "security manager") is supplied by Kung, which is expressly a security-policy enforcement platform, and by the DivvyCloud NPL, which expressly frames cross-cloud tagging as a security/compliance function.

---

6. The obviousness combinations

I set out four combinations, in descending order of strength. Each is framed with the KSR rationale that supports it.

---

Combination 1 (strongest): ServiceNow '904 + Kung '459, optionally + IBM '442

What the combination is. Take ServiceNow '904's multi-provider metadata normalization engine — which already discovers resources across providers, holds a canonical ("predetermined") metadata value, maps that value to provider-specific values, and writes it back through each provider's respective API — and implement it on the contextual security platform of Kung '459 instead of an ITOM/CMDB server.

Why the PHOSITA would make this combination (the motivation):

1. Kung '459 already does the security half of the same job and already talks to the same APIs. Kung discloses automated tag assignment based on discovered resource properties (FIG. 10) inside a security platform that already queries cloud provider APIs and already maintains a system-model database of managed compute environments. Adopting ServiceNow's normalized, cross-provider metadata vocabulary is the natural substitution of an equivalent, better-documented mechanism for Kung's own tag-discovery process.

2. The problem was known and stated. Kung itself addresses "workload units ... distributed between a data center and a private or public cloud service provider" and the difficulty of keeping security policy consistent across those domains. ServiceNow '904 addresses "providers ... us[ing] metadata in different or inconsistent fashions." Both references identify the same failure mode — inconsistent per-provider metadata defeating central management — from two angles. Combining two references that attack the same problem from complementary sides is the KSR paradigm.

3. Predictable result, no new function. The combination adds no capability that either reference lacks: it produces a canonical tag applied back to the resource via the provider's API, in a security context. KSR: "the combination of familiar elements according to known methods is likely to be obvious when it does no more than yield predictable results."

4. IBM '442 supplies an express, on-point teaching to do the combination. IBM '442 (a) diagnoses the absence of "uniform techniques to manage tags/labels" across providers, (b) warns that inconsistent enterprise tag conventions leave the cloud "susceptible ... to service interruptions and other failures," and (c) proposes exactly the remedy of a structured, enterprise-level tag namespace/policy spanning "a first cloud platform" and "a second cloud platform." A reference that (i) recognizes the problem and (ii) suggests the general solution is a core § 103 teaching, even where it does not disclose every claimed implementation detail.

Anticipation overlay: ServiceNow '904 alone is close enough to warrant a § 102 challenge to claim 1 — if the Board or a court reads its "predetermined metadata" list plus the "respective API of the provider" mapping as the claimed pre-defined global tagging policy and assignment via API. The patent owner's rebuttal (that '904's selection is a UI dropdown, not a policy engine) is credible but narrow, and it fails entirely against claim 8 or claim 15, which recite the orchestrator steps generically without requiring an unattended policy engine. Expect a rejection framed in the alternative: § 102 over '904, or § 103 over '904 + Kung/'442.

---

Combination 2: Amazon '730 + ServiceNow '904 (or Amazon '730 + IBM '442)

What the combination is. Amazon '730 supplies the auto-tagging-under-policy engine; ServiceNow '904 (or IBM '442) supplies the multi-provider normalization and provider-API write-back.

Motivation:

1. '730 expressly teaches automatic tag determination from a customer-supplied configuration and policies keyed on object properties — the "pre-defined global tagging policy" and "identifying a unified tag" steps. Its triggering events (on storage, on configuration change, on object modification, on access request) map directly onto the '527 specification's "periodically or on-demand" push-back.
2. '730 is provider-scoped (it operates within a resource provider environment). ServiceNow '904 and IBM '442 both expressly extend tagging across providers. Extending a known single-provider automation technique across multiple providers is the KSR rationale of "us[ing] a known technique to improve similar devices in the same way" — specifically, applying a known auto-tagging technique to a plurality of providers that a skilled artisan was already managing jointly.
3. AWS's own "Tagging Best Practices" NPL (Dec. 2018) supplies the standardization motivation: enterprise-wide tag taxonomies and tag policies. Combining AWS's policy-based tagging with a cross-provider normalization layer is a predictable architectural step that the AWS NPL itself invites by framing tagging as an enterprise governance problem.

---

Combination 3: Kung '459 + IBM '442 + AWS NPL (security-first framing)

What the combination is. Kung '459 supplies the security manager, the hybrid multi-cloud discovery, the resource-property-based automated tag assignment, and the provider-API configuration channel. IBM '442 supplies the recognition that per-provider tag conventions are non-uniform, plus the structured cross-platform tag namespace governed by "enterprise-specific tag-naming conventions and/or other tag policies." The AWS NPL supplies the standardized, centrally governed tag taxonomy.

Motivation: This is "obvious to try" in the KSR sense. The artisan faces a known problem (Kung's cross-cloud security policy consistency), with a finite, identified set of solutions (IBM '442's namespace; AWS's tag-policy governance; ServiceNow's provider-agnostic mapping), in a predictable field (metadata management). IBM '442 is § 102(a)(2) art with a 2019-04-04 effective filing date — squarely within the artisan's frame of reference at the June 2020 filing date, and published in October 2020, confirming it reflects contemporaneous thinking.

---

Combination 4: ServiceNow '904 + AWS NPL + DivvyCloud NPL (the "industry-practice" case)

What the combination is. Two printed publications, both pre-filing, teaching that (i) tags should be standardized and governed across an enterprise's cloud estate (AWS, Dec. 2018), and (ii) tags are the practical mechanism for cross-cloud management and security — DivvyCloud expressly noting untagged resources leave "no hint as to what security controls or compliance standards need to be verified" — combined with the ServiceNow implementation teaching of cross-provider normalized metadata written back via provider APIs.

Motivation: This combination is valuable because it does not depend on any single patent reference's framing. It establishes that by the 2020 filing date, unified, policy-governed, cross-cloud tagging for security purposes was the recognized industry best practice, published in vendor white papers. Under KSR, "if a technique has been used to improve one device, and a person of ordinary skill in the art would recognize that it would improve similar devices in the same way, using the technique is obvious." The '527 patent's contribution is, at most, implementing the published best practice on a security manager — an architectural placement choice.

---

7. Dependent claims

Claims 2, 9, 16 — "facilitating application of a security policy expressed with reference to one or more unified tags ... by retrieving information ... from a storage database"

Obvious. Kung '459 discloses the storage database ("The system model database stores the application and infrastructure information needed by the context security platform"), policy expressed at the application level and mapped to enforcement, and tag-driven resource grouping. Amazon '730 discloses policies that "indicate which actions can be performed for those objects based at least in part upon the applied tags." The '527 specification's own definition of "intent-based security policy" ("a security policy expressed with reference to one or more tags rather than or in addition to IP addresses and/or VLANs") is the ordinary policy-by-tag paradigm of both references. No additional inventive concept.

Claims 3, 10, 17 — hybrid multi-cloud (private cloud + multiple public clouds)

Obvious, and nearly anticipated. Kung '459: "hybrid computer network infrastructures combining traditional physical networks and servers with virtual computing infrastructures" and "private and public cloud infrastructure services providers." DivvyCloud NPL enumerates AWS, GCP, Azure, OpenStack. IBM '442 addresses "migrating the resource from a first cloud platform to a second cloud platform." This is a pure field-of-use limitation that the primary references already occupy.

Claims 4, 11 — "said assigning further enables visibility and control for the plurality of cloud resources by the security manager"

Obvious. Kung '459 discloses "continuously monitoring network flows to detect, block and/or quarantine threats, and to monitor security mechanisms to ensure the security mechanisms are configured as defined by policies, fixing detected misconfiguration" — visibility and control, verbatim in substance. The '527 specification treats this as an inherent benefit of the architecture rather than a separate structural feature, which is a § 103 weakness: reciting a result of a step already disclosed adds nothing patentable.

Claim 18 — "single pane of glass user interface" (system family only)

Obvious. ServiceNow '904 discloses a GUI listing discovered resources and preselected metadata with bulk-association controls — a single administrative surface spanning providers. The '527 specification itself defines "single-pane of glass" as a "full administration capabilities" console; that is precisely what ServiceNow '904's interface 500 is. Note that this limitation appears only in the system family (claim 18) — a drafting asymmetry that gives claim 15's dependent set no meaningful extra scope over claims 4/11.

Claims 5, 12, 19 — policy identifies the tag based on resource information, resource location, and resource function

Obvious. ServiceNow '904's predetermined metadata list spans "providers; cost centers; departments; projects; services; applications; and users" — i.e., function/nature and organizational location. Kung '459 ties policy to "the properties of the computing resources hosting the application" and to compute environments (location). The '527 specification's own FIG. 3B example tags resources by cloud and IP address — i.e., by location — which is the least inventive possible implementation of its own dependent claim.

Claims 6, 13, 20 — cloud resources comprise virtual machine instances

Obvious. Kung '459 is built around "virtual machines" and "workload units" across hypervisors and cloud providers; DivvyCloud NPL describes tagging "virtual machines (instances)." This is the most conventional cloud resource in the art — far too ordinary to confer patentability on an otherwise obvious method.

Claims 7, 14 — security manager comprises a cloud-based security management appliance

Obvious. Kung '459 discloses the platform as software running on a server, and its FireEye-family continuations are commercialized as cloud-deployed security services. The '527 specification itself contemplates the security manager being "a cloud based security manager ... implemented in the form of a cloud service." Deploying a known security management function as a cloud service was, by 2020, a routine deployment choice with no asserted technical difficulty.

---

8. Claims 8–14 and 15–20

Claims 8 and 15 are substantively identical to claim 1 — same receive / retrieve / identify / assign-via-API sequence — differing only in statutory category (non-transitory medium; system with processor + memory). Under KSR and the treatment of apparatus claims reciting the same process, they stand or fall with claim 1. There is no independent structural element in claim 15 beyond the processor/memory pairing that every software patent claim recites; the "multi-tag orchestration system" label is a naming convention, not a limitation.

One asymmetry worth recording: claim 15's preamble omits the "security manager" and "private network" actors that appear in claims 1 and 8, reciting only "a cloud environment used by a private network." That makes claim 15's independent claim broader than claim 1 and therefore even more exposed to the ServiceNow '904 + Amazon '730 combination, which requires no security-manager actor at all.

---

9. Rebuttal landscape — what the patent owner would argue, and the response

---

10. Bottom line

Claims 1–20 of US 11,290,527 B2 are, in my assessment, vulnerable to a § 103 rejection, with claim 1 additionally exposed to a § 102 challenge.

1. Claim 1 is squarely met by ServiceNow US 2018/0123904 A1 alone on elements B, C, D, and E — including the express teaching of mapping a canonical metadata value to a provider-specific value via a respective API of the provider, which is the claimed assignment step. The only gap is the "security manager" framing, supplied by Kung US 2018/0234459 A1.

2. The motivation to combine is not inferred — it is published. IBM US 2020/0322442 A1 states, in 2019 language, the identical problem the '527 patent recites as its own, and proposes the identical class of solution. AWS's Dec. 2018 "Tagging Best Practices" and DivvyCloud's Oct. 2019 "Multi-Cloud Tagging Strategies" establish that unified, policy-governed cross-cloud tagging was recognized industry practice before the filing date.

3. The dependent claims are uniformly conventional. Hybrid multi-cloud (3/10/17), policy keyed on resource info/location/function (5/12/19), VM instances (6/13/20), and cloud-based security appliance deployment (7/14) are each disclosed by the primary references or are routine field-of-use limitations.

4. The strongest available rejection is a three-reference combination: ServiceNow '904 as primary, in view of Kung '459, and further in view of Amazon '730 and/or IBM '442. Expect a parallel § 102 rejection of claim 1 over ServiceNow '904, and note that claim 15's broader preamble (omitting the security-manager actor) is weaker still.

---

11. Confidence statement

• High confidence in the disclosures attributed to ServiceNow US 2018/0123904 A1, Amazon US 10,594,730 B1, IBM US 2020/0322442 A1, and Kung US 2018/0234459 A1 — all verified from full text or substantial verbatim excerpt. High confidence in the DivvyCloud white-paper content.
• Moderate confidence in the relevance of references I identified only from the '527 record's citation table — US 9,934,269 B1, US 10,496,692 B1, US 2015/0350103 A1, US 2016/0042031 A1, US 10,721,141 B1, US 2019/0149436 A1, US 2021/0176191 A1, and others. Their titles place them in the field, but I have not verified their disclosures and would not rely on any of them as a primary reference without a full-text pull. Note the record already shows IBM's own specification citing Amazon US 9,934,269 as the "resource groups service" — a cross-reference worth confirming.
• Not assessed / out of scope: I have not evaluated § 101 (Alice/Mayo) eligibility, written-description or enablement under § 112, or claim indefiniteness. A § 101 analysis would likely be a separate and independent vulnerability given the purely administrative and API-invocation nature of the steps — but that is a different inquiry from the one you asked about.
• No fabrication: I have not invented claim language, reference disclosures, case citations, or motivations not supported by text I actually retrieved. Where a motivation is my inference rather than a quotation, I have labelled it as such.