docs: add missing account_based and key_request pattern entries

Author: Danny-Devs

docs/content/ExamplePatterns.mdx

@@ -51,4 +51,16 @@ This section covers access control, not link generation. You can generate and di
 
 [Move source](https://github.com/MystenLabs/seal/blob/main/move/patterns/sources/voting.move)
 
-Use this pattern to run a vote where ballots stay encrypted until completion. You define eligible voters and each submits an encrypted choice. When all votes are in, anyone can fetch the required threshold keys from Seal and use the [on-chain decryption](https://seal-docs.wal.app/UsingSeal/#on-chain-decryption) to produce a verifiable tally. Invalid or tampered ballots are ignored. This pattern is useful for governance, sealed-bid auctions, or time-locked voting.
+Use this pattern to run a vote where ballots stay encrypted until completion. You define eligible voters and each submits an encrypted choice. When all votes are in, anyone can fetch the required threshold keys from Seal and use the [on-chain decryption](https://seal-docs.wal.app/UsingSeal/#on-chain-decryption) to produce a verifiable tally. Invalid or tampered ballots are ignored. This pattern is useful for governance, sealed-bid auctions, or time-locked voting.
+
+## Account-based encryption
+
+[Move source](https://github.com/MystenLabs/seal/blob/main/move/patterns/sources/account_based.move)
+
+Use this pattern when you want to encrypt data to a specific Sui address. The key ID is derived directly from the recipient's address, so anyone can encrypt a message for address B, but only the owner of that address can decrypt it. There is no on-chain state to manage — access is determined entirely by address ownership. This pattern is a natural fit for end-to-end encrypted messaging, private notifications, or any scenario where you need to send encrypted data to a known recipient without setting up shared state first.
+
+## Key request
+
+[Move source](https://github.com/MystenLabs/seal/blob/main/move/patterns/sources/key_request.move)
+
+Use this pattern to separate access policy evaluation from the `seal_approve` step. Instead of checking the full policy inside `seal_approve`, your contract performs whatever authorization logic it needs (payment, role check, rate limit, etc.) and issues a `KeyRequest` object. The `seal_approve` function then only verifies that the `KeyRequest` is valid and unexpired, keeping policy evaluation outside of the Seal dry-run path. This is useful when your access policy is complex, when you need to guarantee safety during dry-run evaluation, or when you want to charge per key request. The pattern uses a witness type to bind each `KeyRequest` to the issuing package, preventing cross-contract forgery.