Smart Card Application Management via User Authorization

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing smart card systems require the knowledge of the application issuer for loading applications, making it cumbersome and costly to add or change applications on a card, as the issuer must be involved in the process.

Innovation Solution

A method where the token user is required to authorize or deny processing requests, allowing them to control application management, including loading, modifying, or deleting applications, without the need for the issuer's involvement after the card is issued.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If the application issuer controls the management of applications on the smart card, then the security and control of application loading is maintained, but the complexity and cost of logistics increase significantly

Engineering Contradiction:
Improveapplication management controlVSAvoidlogistics complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The smart card system enables self-service by allowing the cardholder to autonomously manage application loading and updates without requiring the application issuer's direct involvement. The cardholder can use a personal computer to load applications onto the smart card, eliminating the need for complex issuer-controlled logistics while maintaining security through cryptographic authentication mechanisms.

Inventive Principle:
Principle #25Self-service

2Reliability

If the application issuer is involved in every application loading operation, then the security and authorization control is ensured, but the time and cost of the process increase

Engineering Contradiction:
Improveauthorization controlVSAvoidapplication loading time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The system performs preliminary actions by pre-establishing cryptographic credentials and authorization mechanisms during card issuance. The cardholder receives a personal identification number and other authentication data that enable future autonomous application loading operations without requiring real-time issuer involvement, thus reducing time loss while maintaining authorization control.

Inventive Principle:
Principle #10Preliminary action

3Ease of operation

If the smart card is designed to allow autonomous user control for application management, then the ease of operation improves, but the security risks from unauthorized modifications increase

Engineering Contradiction:
Improveuser control capabilityVSAvoidunauthorized modification risk
Core Design Contradiction:
Ease of operationVSObject-affected harmful factors

Solution Approach 1:

The system introduces cryptographic intermediaries that mediate between the cardholder's autonomous control and the application loading process. Personal identification numbers, cryptographic keys, and authentication protocols act as intermediaries that enable user convenience while preventing unauthorized modifications, as any application loading must pass through these security intermediaries that verify authorization.

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentUS9582955B2Method and token for managing one processing relating to an application supported or to be supported by a token
Publication Date: 2017.02.28 THALES DIS FRANCE SA
  • US9582955B2 patent drawing
  • US9582955B2 patent drawing
  • US9582955B2 patent drawing

AI summary

The invention relates to a method 30 for managing at least one processing relating to an application supported or to be supported by a token. The token comprises means for processing data, means for storing data and means for communicating with outside.According to the invention, the method comprises steps in which at least one token user is required to give or not to give her/his authorization 38 before executing the at least one processing relating to an application supported or to be supported by the token; and the token verifies 316 whether the at least one token user gives or does not give her/his authorization.The invention relates also to a corresponding token likely to cooperate with a terminal.