Merchant Cryptogram Lockbox for Local Key-Based Authorization

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing credit card transaction authorization systems rely on cryptograms generated by external entities, which can introduce security risks and dependencies, and lack efficient local generation and management capabilities.

Innovation Solution

Implementing a cryptogram lockbox at the merchant's location, which generates cryptograms locally using unique merchant account keys, securely manages keys, and supports key rotation and lifecycle events, reducing external dependencies and enhancing security.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of operation

If external cryptogram issuers are used for transaction authorization, then transaction processing can be simplified, but security is reduced and dependency on external systems increases

Engineering Contradiction:
Improvetransaction processing simplicityVSAvoidtransaction security
Core Design Contradiction:
Ease of operationVSReliability

Solution Approach 1:

The patent introduces a cryptogram lockbox as an intermediary component that sits between the external cryptogram issuer and the merchant system. This lockbox receives cryptogram requests, retrieves stored cryptograms locally, and forwards requests to external issuers only when necessary. This intermediary approach maintains simplified transaction processing while enhancing security through local cryptogram storage and reduced external dependency.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Adaptability or versatility

If external cryptogram generation is used, then local key management flexibility is reduced, but system complexity is decreased

Engineering Contradiction:
Improvekey management flexibilityVSAvoidsystem complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent segments the cryptogram management system into distinct components: a merchant-specific cryptogram lockbox for local storage and retrieval, a key management server for centralized key distribution and rotation, and external cryptogram issuers for backup generation. This segmentation allows flexible key management with different levels of control while distributing system complexity across multiple specialized components rather than concentrating it in one system.

Inventive Principle:
Principle #1Segmentation

3Reliability

If local cryptogram generation is implemented, then dependency on external systems is reduced, but device complexity increases

Engineering Contradiction:
Improveindependence from external systemsVSAvoidlocal system complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent implements preliminary action by pre-storing cryptograms in the merchant-specific lockbox before they are needed for transaction authorization. The system proactively retrieves and caches cryptograms in advance, so when a transaction occurs, the authorized cryptogram is already available locally without requiring real-time external system communication. This reduces operational dependency on external systems while the modular architecture keeps local complexity manageable.

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentUS12619977B2Systems and methods for using a cryptogram lockbox
Publication Date: 2026.05.05 JPMORGAN CHASE BANK NA
  • US12619977B2 patent drawing
  • US12619977B2 patent drawing
  • US12619977B2 patent drawing

AI summary

Systems and methods for using a cryptogram lockbox are disclosed. In one embodiment, in a merchant-specific cryptogram lockbox comprising at least one computer processor, a method for generating a cryptogram locally using a cryptogram lockbox may include: (1) receiving, from merchant backend, a request for a cryptogram comprising an account identifier received from a customer in a transaction; (2) generating a cryptogram for the account identifier using a limited use key for the account identifier; and (3) returning the cryptogram to the merchant backend. The merchant may conduct the transaction using the cryptogram.