US7165727B2 - Method and apparatus for installing an application onto a smart card - Google Patents
Method and apparatus for installing an application onto a smart card Download PDFInfo
- Publication number
- US7165727B2 US7165727B2 US10/786,506 US78650604A US7165727B2 US 7165727 B2 US7165727 B2 US 7165727B2 US 78650604 A US78650604 A US 78650604A US 7165727 B2 US7165727 B2 US 7165727B2
- Authority
- US
- United States
- Prior art keywords
- aid
- application
- card
- applet
- interpreter
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active, expires
Links
Images
Classifications
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
- G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
- G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
- G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
- G06F21/34—User authentication involving the use of external additional devices, e.g. dongles or smart cards
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
- G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
- G06F21/74—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information operating in dual or compartmented mode, i.e. at least one secure mode
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
- G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
- G06Q20/357—Cards having a plurality of specified features
- G06Q20/3574—Multiple applications on card
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/30—Security of mobile devices; Security of mobile applications
- H04W12/37—Managing security policies for mobile devices or for controlling mobile applications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/50—Service provisioning or reconfiguring
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/60—Subscription-based services using application servers or record carriers, e.g. SIM application toolkits
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0227—Filtering policies
- H04L63/0236—Filtering by address, protocol, port number or service, e.g. IP-address or URL
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/08—Access security
Definitions
- the present invention relates to the field of computer science. More particularly, the present invention relates to installing an application onto a smart card.
- smart cards have also proliferated. These are similar in scale to traditional credit cards, but incorporate within their plastic cases a microelectronic memory and also (optionally) an embedded processor. It will be appreciated that the computational resources available within a smart card are extremely limited compared to those of a desktop workstation, or even a laptop or handheld device.
- a Java Card This is based on the Java platform developed by Sun Microsystems (“Java” and “Java Card” are trademarks of Sun Microsystems Inc). In such devices, a Java virtual machine (VM) is provided within the smart card to allow the execution of Java applets or applications.
- Java virtual machine VM
- Java Card smart card platform is available from the page: /products/javacard/ at the web site: http://java.sun.com and from the site: http://wwwjavacardforum.org/.
- API Application Programming Interface
- Java Card platform An Application Programming Interface (API) is defined for the Java Card platform.
- Applications written in the Java programming language invoke this API to access the Java Card run-time environment (JRE) and any native services.
- JRE Java Card run-time environment
- the Java Card API allows application portability, in that the same application can run on any smart card that supports the API.
- the Java Card API is compatible with international standards, in particular the ISO/IEC 7816 family of standards.
- applet programs that run on smart cards may be referred to as either an application or as an applet. It will be appreciated that there is a clear distinction between a Java applet and a Java application in a desktop environment, in particular the absence of a main class from the former. However, this distinction does not apply in the smart card environment. Thus applets for use on a Java card platform are not the same as applets that run on a web browser.
- applet will generally be used herein to refer specifically to code, and the term application to refer to the higher level functionality provided by the applet code and associated data (unless the context requires otherwise).
- the Java Card platform supports multiple applications on a single card. These may be separated by firewalls, in order to ensure that they do not interfere with one another. This is particularly of concern if the various applications are operated by different organizations, whose business relationships with the cardholder may be independent of one another.
- FIG. 1 is a high-level schematic diagram illustrating the main architectural components in a typical smart card application.
- smart card 102 belonging to cardholder 101 interacts with a terminal 110 by exchanging an application protocol data unit (ADPU) 108 .
- the format for the ADPU is defined by the International Standard ISO/IEC 7816-3.
- Terminal 110 may be a handheld device, an adjunct to a desktop workstation, a dedicated card reader (analogous to an ATM) or any other suitable system.
- the communications between the smart card 102 and the terminal 110 may be by wired connection, such as some form of bus (e.g. USB), or by wireless link (e.g. radio or some other electromagnetic signal), depending on the particular devices concerned.
- the terminal 110 may be under the direct control of an operator 111 (such as for a handheld terminal), or alternatively terminal 110 may be automated (such as for an ATM).
- Terminal 110 interacts with a back office 130 over any suitable form of network 120 , such as the Internet, a local area network (LAN), a wide area network (WAN), and so on.
- Back office 130 may comprise multiple systems (not explicitly shown in FIG. 1 ), such as a web server or portal attached to network 120 , perhaps with an application server and/or a database system behind.
- the terminal 110 may be off-line until activated by a smart card 102 , a card holder 101 or a terminal operator 111 to access a back office 130 over network 120 .
- the cardholder 101 typically places the card 102 into or adjacent to the terminal 110 , thereby allowing the two to interact, e.g. to perform a debit operation from the card, in order to purchase some goods.
- This interaction will generally be referred to herein as a session, and typically involves the exchange of multiple messages between the smart card 102 and the terminal 110 .
- a session can be regarded as comprising multiple transactions, where each transaction represents the completion of some portion of the overall session (e.g. a security authorization).
- AID Application Identifier
- the AID is a byte string up to 16 bytes long, whose format is defined by International Standard ISO/IEC 7816-5. Thus according to this standard, the first 5 bytes of the AID represent the registered application provider identifier (RID) and have a value allocated by ISO or one of its member bodies.
- the RID generally indicates the merchant or other entity involved with operating the applet, hereinafter referred to as the RID operator.
- the RID operator is generally responsible for the back office program 130 , and is depicted as application/RID operator 131 in FIG. 1 .
- the last 11 bytes of the RID constitute the proprietary application identifier extension (PIX).
- the PIX is determined by the RID operator 131 , and can be used to store a reference number or other information associated with the applet.
- FIG. 1A illustrates the storage of the AID on a typical smart card 102 .
- the AID bytes are stored in a byte array, which represents internal storage for a Java AID object 161 .
- Applications can therefore access the AID by making appropriate calls to AID object 161 , which in effect provides a wrapper for the underlying byte array.
- the procedure starts when the smart card 102 is first inserted into the terminal 110 .
- the terminal detects the insertion of the smart card (reference numeral 162 ), and in response to such detection activates the smart card (reference numerals 164 , 172 ). This activation typically includes providing power to the smart card.
- the terminal now sends a request using an application protocol data unit (ADPU) 108 to the smart card (reference numeral 166 ).
- the ADPU identifies the application to be used in this session in terms of its AID.
- the request from the terminal is received by the smart card (reference numeral 174 ), typically within an applet selector program that is running on the smart card 102 as part of a card executive layer.
- the applet selector is then responsible for locating and launching the application that matches the AID request from the terminal, i.e. the application that has the same AID as specified in the request (reference numerals 176 and 177 ).
- the smart card also returns the AID for the matching application back to the terminal 110 (reference numerals 179 and 180 ).
- N.B. Reference numerals 179 and 180 are optional within the context of ISO/IEC 7816-4, although commonly implemented).
- FIG. 1C describes a variation on the above approach (also in accordance with ISO/IEC7816-4), in which the terminal 110 supplies the card with a truncated AID (known as a partial AID), for example the first ten bytes of an AID.
- a partial AID truncated AID
- One reason for using a partial AID might be if the terminal 110 wants to identify all applets on the card having a particular RID.
- FIG. 1C commences as just described for FIG. 1B , except that at reference numeral 166 the request from the terminal 110 to the smart card 102 comprises only a partial AID. Consequently, the smart card may identify multiple matching applications at reference numeral 176 . The AIDs for these matching applications are then returned to the terminal 110 (reference numerals 179 , 180 ), in order to allow the terminal (or user) to select a specific desired application from those matching the partial AID. Thus the terminal now sends a request to the smart card to launch an applet (reference numeral 182 ). This request specifies the particular applet to be launched on the smart card in terms of its complete AID (generally selected from the set of those received from the smart card at reference numeral 180 ). The smart card duly responds to this request by launching the applet selected by the terminal (reference numeral 190 ).
- FIG. 1C represents an appropriate logical model for the use of partial AIDs
- the actual implementation looks more like FIG. 1B (primarily for historical reasons).
- current systems generally accommodate the matching and return of multiple matching AIDs by identifying only a single matching AID at a time.
- the applet having the AID that is first matched to the partial AID received from the terminal is launched, and the complete AID for this applet is returned to the terminal 110 .
- the smart card then only supplies a next matching AID upon a subsequent specific request from the terminal.
- multiple matching AIDs could be handled in other ways, such as by returning the complete set of multiple matching AIDs all at once in a single response to the terminal (as depicted in FIG. 1C ).
- FIG. 2 is a schematic diagram representing the life cycle of a smart card, which in this particular implementation is a Java Card.
- This life cycle commences with the manufacture of the card, and the initial loading of the base operating system and the Java Card environment (reference numeral 210 ). Also at this stage, one or more applications may be preloaded (reference numeral 215 ).
- the base operating system and Java Card environment, and also potentially any preloaded applications may be stored in ROM on the smart card 102 as part of the manufacturing process.
- the card is now ready for issue to a cardholder (reference numeral 220 ), which typically involves an appropriate personalization process, as well as initialization of the Java environment, and starting the Java virtual machine on the card.
- the cardholder is thereafter able to use the card (reference numeral 230 ), such as in the manner illustrated schematically in FIG. 1 .
- the cardholder may have to load an application prior to making substantive use of the card. In practice however, this situation is rather uncommon, since usually there is at least one preloaded application in order to motivate issuance of the card in the first place.
- the last operation shown in FIG. 2 is where the card is terminated (reference numeral 240 ). This may occur, for example, because the card has a built-in expiry date or is surrendered by the user (perhaps if the user is moving to a new card issuer, or the card is physically damaged).
- An application identifier comprises at least one customization parameter for an application to be installed onto a smart card.
- the application may be installed onto the smart card by providing the AID, instantiating the application onto the smart card, storing the AID onto the card, and configuring the application in accordance with the stored AID, wherein the application is configured in accordance with the at least one customization parameter.
- FIG. 1 is a schematic diagram illustrating the main components involved in a typical smart card application.
- FIG. 1A is a schematic diagram representing the implementation of an AID object in a typical existing smart card.
- FIG. 1B is a flowchart whereby a terminal selects and launches one application out of potentially multiple applications on a smart card by providing a full AID to the smart card.
- FIG. 1C is a flowchart whereby a terminal selects and launches one application out of potentially multiple applications on a smart card using partial AID matching.
- FIG. 2 is a schematic diagram illustrating the typical life cycle of a smart card.
- FIG. 3 is a schematic block diagram representing at a high level the structure of a typical smart card.
- FIG. 4 is a schematic diagram illustrating the interaction between a smart card and a terminal in accordance with one embodiment of the invention.
- FIG. 5 illustrates the composition of an AID in accordance with one embodiment of the invention.
- FIGS. 5A , 5 B, 5 C, and 5 D illustrate the structure of an AID interpreter in accordance within certain embodiments of the invention.
- FIG. 6 is a flowchart depicting a procedure for matching an applet on a card in accordance with certain embodiments of the invention.
- FIGS. 6A through 6E are flowcharts illustrating in more detail the procedure of FIG. 6 in accordance with various embodiments of the invention.
- FIG. 6F is a flowchart depicting a procedure for matching in the terminal an applet on a card in accordance with one embodiment of the invention.
- FIG. 7 is a flowchart illustrating a smart card dynamically generating an AID to provide to a terminal in accordance with one embodiment of the invention.
- FIG. 8 illustrates a procedure for a terminal to utilize an AID to obtain code or information to support processing the AID in accordance with one embodiment of the invention.
- FIGS. 8A through 8F illustrate aspects of the processing of FIG. 8 in more detail for various embodiments of the invention, comprising some of the processing performed at a server.
- FIG. 9 illustrates the server processing for a request from a terminal in accordance with one embodiment of the invention.
- FIGS. 10 and 11 are schematic diagrams of the components involved in utilizing an AID to obtain code or information to support processing the AID in accordance with two different embodiments of the invention.
- FIG. 11A illustrates the use of a default proxy AID interpreter in accordance with one embodiment of the invention.
- FIG. 12 is a flowchart illustrating a procedure for a terminal to obtain a set of AIDs from a smart card in accordance with one embodiment of the invention
- FIG. 12A is a flowchart illustrating some of the operations of the procedure of FIG. 12 in more detail in accordance with one embodiment of the invention.
- FIG. 13 is a flowchart illustrating a procedure for a terminal to identify a matching application in accordance with one embodiment of the invention.
- FIG. 13A is a flowchart illustrating the selection of proxy program on the terminal in accordance with one embodiment of the invention.
- FIG. 14 is a flowchart illustrating the installation of an application comprising an AID onto a smart card in accordance with one embodiment of the invention.
- FIG. 15 is a flowchart illustrating the use of the AID to hold configuration data in the flowchart of FIG. 14 .
- the components, process steps, and/or data structures may be implemented using various types of operating systems (OS), computing platforms, firmware, computer programs, computer languages, and/or general-purpose machines.
- OS operating systems
- the method can be run as a programmed process running on processing circuitry.
- the processing circuitry can take the form of numerous combinations of processors and operating systems, or a stand-alone device.
- the process can be implemented as instructions executed by such hardware, hardware alone, or any combination thereof.
- the software may be stored on a program storage device readable by a machine.
- FPLDs field programmable logic devices
- FPGAs field programmable gate arrays
- CPLDs complex programmable logic devices
- ASICs application specific integrated circuits
- the method may be implemented on a data processing computer such as a personal computer, workstation computer, mainframe computer, or high performance server running an OS such as Solaris® available from Sun Microsystems, Inc. of Santa Clara, Calif., Microsoft® Windows® XP and Windows® 2000, available form Microsoft Corporation of Redmond, Wash., or various versions of the Unix operating system such as Linux available from a number of vendors.
- the method may also be implemented on a multiple-processor system, or in a computing environment including various peripherals such as input devices, output devices, displays, pointing devices, memories, storage devices, media interfaces for transferring data to and from the processor(s), and the like.
- a computer system or computing environment may be networked locally, or over the Internet.
- network comprises local area networks, wide area networks, the Internet, cable television systems, telephone systems, wireless telecommunications systems, fiber optic networks, ATM networks, frame relay networks, satellite communications systems, and the like.
- networks are well known in the art and consequently are not further described here.
- FIG. 3 illustrates in schematic form the high level structure of a smart card 102 in accordance with one embodiment of the present invention.
- the smart card is implemented using a Java Card system.
- a Java Card system Such a system is described for example in: “Java Card Technology for Smart Cards: Architecture and Programmer's Guide” by Zhiqun Chen, Addison-Wesley, 2000, ISBN 0201703297, while the formal Java Card specification is available for download from: http://java.sun.com/products/javacard/specs.html. Both of these texts are hereby incorporated by reference.
- smart card 102 is not limited to the Java Card platform, and that alternative embodiments of the invention can be implemented on any suitable smart card platform.
- smart card 102 is conveniently implemented in a plastic device similar in size and shape to a conventional credit card, in alternative embodiments it takes a variety of other portable formats, such as a ring, or a pendant, and so on.
- smart card 102 comprises a token or similar device, such as for use in authentication.
- smart card 102 can be integrated into another electronic device.
- smart card 102 comprises a Subscriber Identity Module (SIM) card for use in a GSM mobile telephone, or a Wireless Interface Module (WIM) for use in a device that supports the Wireless Application Protocol (WAP), or a Universal Subscriber Identity Module (USIM) card or a User Identity Module (UIM) for use in a 3rd Generation Partnership Project mobile telephone.
- SIM Subscriber Identity Module
- WAP Wireless Application Protocol
- USB Universal Subscriber Identity Module
- UIM User Identity Module
- Smart card 102 can be regarded as having a layered structure, with hardware at the bottom.
- the hardware for a card comprises a CPU 311 , a cryptographic facility 312 , an input/output unit 313 and memory (random access memory (RAM), read only memory (ROM), electrically erasable programmable read only memory (EEPROM)) 314 .
- RAM random access memory
- ROM read only memory
- EEPROM electrically erasable programmable read only memory
- the card executive layer comprises an applet selector 412 , whose operation will be described in more detail below.
- Java Card runtime environment which comprises the Java Card virtual machine (VM) 320 .
- VM Java Card virtual machine
- the Java Card VM itself is generally specific to the particular card executive layer 318 , but then presents the standard Java Card API 330 to application software 351 running on the smart card 102 .
- the Java Card device 102 depicted in FIG. 3 has (by way of example) five loaded applets 351 A, 351 B, 351 C, 351 D and 351 E.
- Each applet 351 comprises a card AID interpreter 411 , which will be described in more detail below.
- the applets 351 A, 351 B, 351 C, 351 D and 351 E generally extend (i.e. subclass) a base applet class 321 provided by the JCRE 320 .
- the AID interpreters 411 A, 411 B, 411 C, 411 D and 411 E extend a base AID interpreter class 322 , which is also provided by the JCRE 320 .
- applets 351 A, 351 B, 351 C, 351 D and 351 E may be from different vendors. It will be appreciated having multiple applications from different vendors installed on a single card avoids the need for a user to have to carry around multiple cards, one for each vendor or application provider.
- the applets 351 are arranged into three groups, separated from another by firewalls 360 .
- applets 351 A and 351 B are in firewall 360 K
- applet 351 C is in firewall 360 L
- applets 351 D and 351 E are in firewall 360 M.
- Applets 351 can share data within a firewall 360 , but not generally from one firewall to another.
- One motivation for having two or more applets within a single firewall is where one applet manages the code and classes of the other application(s) that are within the same firewall. It is expected that all the applets within a particular firewall are controlled by the same RID operator (i.e. they have the same RID).
- applets 351 are static, in that all the code they use is already stored in smart card 102 . In other words, applications do not download any code from terminal 110 or elsewhere except during initial applet installation, at which time all the applet code is loaded for storage onto smart card 102 as part of the applet installation process.
- FIG. 4 depicts in schematic form the interaction between a smart card 102 and a terminal 110 in accordance with one embodiment of the invention.
- the smart card 102 comprises multiple applets, 351 A, 351 B, etc., each incorporating its own AID interpreter object, 411 A, and 411 B respectively.
- Each applet 351 also comprises its own AID 401 .
- the AID 401 for a card can be regarded as contained with the card's AID interpreter 411 .
- a card AID interpreter 411 is responsible for providing access to the AID 401 (and parts thereof) for the applet 351 concerned. This interaction between the card AID interpreter 411 and the AID 401 is described in more detail below.
- the smart card 102 contacts a terminal 110 , which contains one or more proxies ( 410 A, 410 B). As shown in FIG. 4 , there is a corresponding back office application 130 A, 130 B for each proxy. Note that in FIG. 4 , there is a one-to-one correspondence between a proxy 410 in the terminal 110 and an applet 351 on smart card 102 , although in other embodiments one proxy 410 may be associated with multiple applets 351 . Each proxy comprises its own proxy AID interpreter 811 (again as described in more detail below).
- proxy 410 installed on terminal 110 , this can be set to trigger automatically when a card 102 is inserted into the terminal 110 (or otherwise engages with the terminal). Note that the proxy need not be terminated after each session with a card, but rather may only be suspended pending insertion of a new (potentially different) card. This helps to reduce proxy start-up time for the new card interacting with a terminal.
- FIG. 5 illustrates the structure of an AID in terms of byte string 401 in accordance with one embodiment of the present invention.
- an AID 401 is divided into two portions in accordance with the international standard ISO/IEEC 7816-5.
- the AID commences with a 5-byte RID portion 501 that identifies the supplier or operator of the applet 351 (i.e. the RID operator), and then has an 11-byte (maximum) proprietary application identifier extension (PIX) portion 502 , whose format and content are under the control of the RID operator identified by the RID.
- PIX application identifier extension
- FIG. 5 further illustrates various subfields within the PIX portion 502 of the AID 401 , in accordance with one embodiment of the present invention.
- the PIX portion 502 is used to store both an identifier 502 A of the firewall 360 that contains the applet concerned, and also an identifier 502 B of the particular applet 351 itself. If required, additional information 502 C can also be encoded into the PIX, as described later in more detail.
- the sizes and layout shown in FIG. 5 for the Firewall ID portion 502 A, the Applet ID portion 502 B, and the Other portion 502 C are illustrative only, and may vary from one applet to another.
- the bytes allocated to a particular subfield are not contiguous.
- the Applet ID 502 B can be stored in two separate blocks, with bytes indicative of the Firewall ID 502 A located in-between.
- subfields can be omitted altogether if not required by a particular RID operator. All such variations are of course still constrained by total size of the PIX 502 , which is limited to 11 bytes (or at least no greater than 11 bytes), in conformity with the international ISO/IEC standard.
- Firewall ID 502 A within AID 401 One motivation for storing the Firewall ID 502 A within AID 401 is that although all applets in the same firewall are expected to relate to the same RID operator (i.e. have the same RID 501 ), the converse is not true. In other words, applets having the same RID may be located in different firewalls. This might arise if the cardholder has more than one relationship with an RID operator, and these different relationships are to be kept independent.
- an organization such as a bank
- account manipulation e.g. cash withdrawal from an ATM.
- the general card management application is likely to have privileges that should not be extended to the specific application for account manipulation.
- a contractor for a large supermarket may have identity information encoded in a card to allow them to access particular areas of the supermarket in a business capacity.
- the contractor may also have a loyalty or reward program installed in their card for when they make personal purchases at the supermarket.
- FIGS. 5A , 5 B, 5 C, and 5 D illustrate schemes for storing an AID byte string 401 within an applet 351 in accordance with alternative embodiments of the invention.
- the AID is accessed via the card AID interpreter object 411 .
- the card AID interpreter object 411 supports a predetermined set of method calls to perform operations on the AID, such as (for example) get_AID( ), which accesses and returns the complete AID, get_RID( ), which accesses and returns just the RID component of the AID, etc. From the perspective of other software, the card AID interpreter 411 may therefore be regarded as an AID object. (Any separate existence of an AID object internal to the AID interpreter is transparent to software external to the AID interpreter).
- the internal implementation of the card AD interpreter 411 differs between the various embodiments shown in FIGS. 5A , 5 B, 5 C, and 5 D. However, it will be appreciated that these differences are transparent to (i.e. hidden from) software that uses the card AID interpreter 411 to access the AID and its components (due to object encapsulation). Thus in all cases there is a common method signature for the card AID interpreter class 411 . Nevertheless, differences in the internal implementation of the card AID interpreter 411 may have implications for performance, required storage capacity, and so on, as will now be discussed.
- the underlying AID byte string 401 itself is stored in one or more byte arrays, although any other appropriate form of storage primitive(s) could be used.
- a byte array is then accessed via a buffer object 561 , which is a general purpose object that provides method calls for accessing and manipulating its byte array of stored data (i.e. in this case the AID).
- the buffer object 561 has no knowledge of the internal composition of the stored data, such as that the first portion of the AID byte array represents the RID 501 , and the second portion of the AID byte array represents the PIX 502 .
- the card AID interpreter 411 calls the buffer object 561 directly in order to access the stored AID data.
- the card AID interpreter 411 therefore acts in effect as a wrapper for buffer object 561 .
- the card AID interpreter 411 may be implemented as an extension of the buffer object 561 . In either case, the AID interpreter 411 therefore has knowledge of the structure and coding of an AID 401 , in order to be able to derive the various AID components from the full stored AID.
- FIG. 5B illustrates an alternative implementation of the card AID interpreter 411 , in which three components of the AID, namely RID 501 , Firewall ID 502 A, and the Applet ID 502 B, are each represented by a respective (sub)object, namely RID object 540 , Firewall ID object 541 , and Applet ID object. These three subobjects interact with respective buffer objects 561 A, 561 B, 561 C. (It is assumed here that the PIX portion comprises only a Firewall ID 502 A and Applet ID 502 B—i.e. that there is no Other portion 502 C in this particular PIX 502 ).
- card AID interpreter 411 When card AID interpreter 411 receives a method call for the AID or one of its components, it calls the relevant subobject(s). For example, in response to a get_RID( ) call, the card AID interpreter 411 calls the RID (sub)object 540 , while in response to a get_AID( ) call, the AID interpreter 411 retrieves all the components of the AID (i.e. RID 501 , Firewall ID 502 A etc.) from their respective subobjects 540 , 541 , etc. In the latter case, the card AID interpreter then knows how to assemble the retrieved AID components into the complete AID.
- FIG. 5B does not store the AID byte string as a complete entity per se. Rather, the various components of the AID are stored separately (in different byte arrays). These components are then assembled in response to a call into the AID interpreter to dynamically generate the complete AID. (A more extensive use of dynamically generated AIDs will be described later in more detail).
- FIG. 5C represents something of a hybrid between the embodiments of FIGS. 5A and 5B .
- the AID subobjects i.e. RID object 540 , Firewall ID object 541 , and Applet ID object 542 ) all access a single buffer object 561 , which is used to store the complete AID.
- This use of a common buffer for holding the AID generally permits a more compact storage than the three separate buffers shown in FIG. 5B .
- the card AID interpreter 411 itself is also able to communicate with buffer 561 directly, i.e. not through one of the subobjects. This helps to speed up operations involving the whole AID (i.e. it avoids having to reconstruct the AID from its various components).
- FIG. 5D illustrates another embodiment in which the Firewall ID object 541 and the Applet ID object 542 are implemented as transient objects (stored in RAM) rather than persistent objects (stored in EEPROM).
- the Firewall ID object 541 and the Applet ID object are only instantiated if particularly required, thereby saving storage on the card.
- FIGS. 5A , 5 B, 5 C, and 5 D There are various trade-offs between speed, storage capacity, flexibility, and so on regarding the different embodiments of FIGS. 5A , 5 B, 5 C, and 5 D.
- the full subobject hierarchy of FIG. 5B provides a good logical representation of the AID structure, but may not offer the best performance levels.
- card AID interpreter 411 in any given situation depends upon the circumstances in question. For example, one implementation may be selected if speed is of paramount concern compared to data and code storage capacity, while another embodiment may be selected if the relevant importance of performance and storage capacity is reversed.
- the skilled person will be aware of which embodiment to select for a given set of circumstances, and will also be aware of potential variations on the particular embodiments illustrated in FIGS. 5A , 5 B, 5 C, and 5 D.
- terminal 110 itself may be dedicated to a single type of application, or may instead support a range of applications.
- the interaction between a smart card and a terminal still follows in general terms the high-level pattern set out in FIG. 1B .
- the procedure is significantly different, as illustrated in FIG. 6 , which depicts processing in accordance with one embodiment of the invention.
- FIG. 6 commences with the receipt at 674 by the smart card 102 of a request from the terminal 110 .
- This request generally corresponds to that transmitted at reference numeral 166 in FIG. 1B , except that the terminal 110 does not specify a single, complete (or partial) AID per se. Rather, the desired application is identified in terms of multiple parameters. These multiple parameters reflect the different components of the AID, for example as illustrated in FIG. 5 .
- the complete AID is obtained from the relevant applet ( 696 ). This complete AID can then be returned to the terminal and the applet corresponding to the AID activated on the card (corresponding to reference numerals 177 and 179 in FIG. 1B ).
- the AID parameters from an applet on a card do not match those received from a terminal, then it is checked to see if there are any more applets to examine ( 695 ). If so, the AID parameters for these further applets are retrieved and tested against the AID parameters received from the terminal. However, if all the applets have now been tested without a positive response at 695 , the smart card now reports to the terminal that it cannot find a match to the requested application ( 699 ).
- FIG. 6A illustrates in more detail the processing of FIG. 6 in accordance with one particular embodiment of the invention.
- this processing commences with the receipt at 674 by the smart card 102 of a request from the terminal 110 .
- the desired application is identified in terms of three parameters:
- firewall identifier 502 A specifies a firewall that is known to contain at most only a single application, then the applet identifier 502 can be omitted. Conversely, the firewall identifier 502 A can be omitted in one embodiment, for example if the applet identifier 502 B is known to be unique to that RID 501 .
- a request containing the above three parameters is therefore received on the smart card at 674 by the applet selector 412 (see FIGS. 3 and 4 ).
- the applet selector then has to find an application 351 on the card that matches these parameters (corresponding in general terms to reference numeral 176 of FIG. 1B , or to reference numerals 681 , 682 , and 684 of FIG. 6 ).
- the applet selector 412 calls each installed applet to try to match these three parameters. More particularly, a first applet is selected ( 680 ), and the applet selector 412 calls this applet in order to obtain access to the card AID interpreter 411 within the applet ( 681 ).
- the applet selector 412 calls a match_RID( ) method (or such-like) on the card AID interpreter 411 ( 682 ). In making the match_RID( ) call, the applet selector passes as a parameter the particular RID 501 that was received from the terminal—i.e. the RID to be matched. The card AID interpreter 411 then tests the received RID against the locally stored RID for that applet ( 684 ). The exact manner of performing this test will depend upon the method signature and internal implementation of the card AID interpreter 411 , such as discussed above in relation to FIGS. 5A , 5 B, 5 C, and 5 D.
- the match_RID( ) method call After the card AID interpreter 411 has tested the RID received from the terminal against the RID for that applet, the match_RID( ) method call returns a positive or negative response as appropriate ( 684 ). If this response is negative, then it is known that this applet cannot be the one desired by the terminal 110 , since the RID does not match. Accordingly, in this case the applet selector 412 proceeds to select another applet 351 on the card to test ( 697 ).
- the applet selector 412 next examines whether the Firewall ID received from the terminal matches the locally stored Firewall ID for the applet. This testing is again performed by making an appropriate call (e.g. match_FirewallID( )) from the applet selector to the card AID interpreter 411 ( 686 ). If the card AID interpreter produces a negative response to the match_FirewallID( ) call, the Firewall ID received from the terminal does not match the Firewall ID stored in the applet. Accordingly, the applet in question cannot be the one desired by the terminal. The applet selector therefore again proceeds to select the next applet for investigation ( 697 ).
- match_FirewallID( ) e.g. match_FirewallID( )
- the applet selector 412 now examines whether the Applet ID received from the terminal matches the Applet ID stored within this applet ( 690 ). Again, this is achieved by making an appropriate method call into the card AID interpreter 411 ( 690 ). In response to this call, the card AID interpreter 411 tests the Applet ID received from the terminal against the Applet ID stored within the applet ( 692 ). If this test yields a negative outcome, then the applet in question cannot be the one desired by the terminal, since the Applet ID does not match. Accordingly, the applet selector 412 again proceeds to select the next applet for consideration ( 697 ).
- the applet selector 412 calls the get_AID( ) method of the card AID interpreter 411 . This call returns the complete AID for the matching applet ( 696 ), which can then be passed back to the requesting terminal (corresponding to reference numeral 179 in FIG. 1B ).
- the matching applet will also be launched on card 102 (corresponding to reference numeral 177 in FIG. 1B ).
- this may terminate the session between the card and the terminal, or may lead the terminal to submit a request for a different application on the card (i.e. to specify a different set of RID 501 , Firewall ID 502 A, and Applet ID 502 B parameters).
- the RID, Firewall ID and Applet ID reliably define a unique application, so that the situation of finding more than one matching applet on a card for a particular terminal request should not arise.
- a more generic matching process can be utilized.
- the terminal can be permitted to omit an applet ID from its request at 674 .
- there may potentially be multiple matching applications i.e. all the applications located within the specified firewall.
- One option would be to handle this situation similarly to the way in which existing systems handle a partial AID that matches multiple applications (i.e. by returning one match at a time for each terminal request).
- Another possibility is to modify the flowchart of FIG.
- 6A by proceeding from 694 (obtain whole AID) to 695 .
- processing would always eventually arrive at 699 , once the applet selector had investigated all the applets on the card.
- the applet selector 412 can then return to the terminal the complete set of matching AID(s) that have been found, or report the absence of any match (as appropriate).
- FIG. 6B depicts an alternative implementation of the application matching process in accordance with one embodiment of the invention. Note that many aspects of this embodiment are the same as for the embodiment of FIG. 6A , and so will not be described in detail. The main difference is that in this implementation it is the applet selector 412 that is responsible for performing the testing of the three input parameters, namely the RID 501 , the Firewall ID 502 A, and the Applet ID 502 B (rather than the card AID interpreter 411 , as in the embodiment of FIG. 6A ).
- the applet selector 412 that is responsible for performing the testing of the three input parameters, namely the RID 501 , the Firewall ID 502 A, and the Applet ID 502 B (rather than the card AID interpreter 411 , as in the embodiment of FIG. 6A ).
- FIG. 6B again starts when a terminal 110 sends a request containing the parameters identifying the desired application, and this request is then received by the smart card ( 674 ).
- the applet selector 412 instead of the applet selector 412 now passing these parameters to the selected individual applets 351 (as in the embodiment of FIG. 6A ), in this embodiment the applet selector 412 calls the card AID interpreter 411 for each selected applet in order to retrieve the corresponding parameters stored in that applet.
- the applet selector retrieves the RID 501 for a selected applet from the card AID interpreter 411 at 682 B, the Firewall ID 502 A for the selected applet from card AID interpreter 411 at 686 B, and the Applet ID 502 B for the selected applet from card AID interpreter 411 at 690 B.
- the retrieval of 682 B can be regarded as being performed using a get_RID( ) call, in contrast to the match_RID( ) call used in the embodiment of FIG. 6A .
- the Applet selector 412 tests the retrieved parameter against the corresponding parameter received in the request from the terminal. Thus applet selector 412 tests at 684 for a match of RID 501 , at 688 for a match of Firewall ID 502 A, and at 692 for a match of Applet ID 502 B. If all three matches turn out positive, then the desired applet has been identified, and the applet selector can request the complete AID for this applet from the relevant card AID interpreter ( 694 ).
- the applet selector 412 itself will not generally know how to form a complete AID from the three parameters it already has, nor will it know whether any additional information, such as Other 502 C (see FIG. 5 ), might be required for such a task).
- the applet selector can then return the complete AID back to the terminal that originally submitted the request (corresponding to reference numeral 179 in FIG. 1 ).
- the card AID interpreter 411 can support a single combined method call to match (or retrieve) two or three of these identifiers at once.
- FIG. 6C depicts processing in accordance with one embodiment of the invention.
- the flowchart of FIG. 6C is broadly similar to the flowchart of FIG. 6B , except that the applet selector retrieves all three parameters, namely the RID, the Firewall ID and the Applet ID, in a single operation at 682 C. These three retrieved parameters can then be matched against the parameters received from the terminal, in the same way as described for FIG. 6B .
- the selector can retrieve the complete AID at 682 C as well as the various AID components, in which case reference numeral 696 of FIG. 6C can subsequently be omitted.
- FIG. 6D illustrates a further embodiment, which is the same as that of FIG. 6C , except that the parameter matching is performed by the various AID interpreters 411 at 682 D (as in FIG. 6A ), rather than by the applet selector.
- the applet selector 412 invoke a (combined) call on the AID interpreter 411 , and as part of this call passes to the card AID interpreter 411 of an applet the parameter triplet of RID 501 , Firewall ID 502 A and Applet ID 502 B received from the terminal ( 682 D).
- the card AID interpreter 411 then tests these three parameters against the corresponding components of the AID stored within the relevant applet (reference numerals 684 , 688 , and 692 ). If all three parameters match, then the card AID interpreter 411 returns a positive response to the call. On the other hand, if one or more of the parameters do not match, a negative response is returned. (N.B. In one implementation, in the event of all three parameters matching, the card AID interpreter 411 comprises the complete AID string in its return to the applet selector 412 , thereby avoiding the applet selector having to make a separate request for this at 696 ).
- FIG. 6 A further possible variation is that rather than the applet selector investigating the different applets on a card sequentially (i.e. one applet at a time), as in FIG. 6 , the applet selector 412 instead investigates multiple (potentially all) applets at the same time.
- the processing of FIG. 6 (reference numerals 681 through to 694 in particular) is performed for each applet in parallel.
- FIG. 6E This is illustrated in the flowchart of FIG. 6E , which depicts processing in accordance with one embodiment of the invention. Note that the processing of FIG. 6E can be performed by any suitable parallel implementation of the flowcharts of FIGS. 6A through 6D , in which case the loop back via reference numeral 697 is clearly omitted.
- the applet selector 412 can then collate the results from each separate applet in order to determine overall whether a matching applet has been identified.
- FIGS. 6 through to 6 E all perform the applet matching on the smart card 102
- this matching can also be performed on terminal 110 , as illustrated in the flowchart of FIG. 6F , which depicts processing in accordance with another embodiment of the invention.
- the flowchart of FIG. 6F commences with the terminal requesting information about the applets on the card 102 ( 604 ).
- the terminal receives the RID 501 , firewall ID 502 A and applet ID 502 B as well as the complete AID 401 for each applet on the card ( 606 ). This allows the terminal to try to identify the desired applet, based on matching its RID 501 , firewall ID 502 A and applet ID 502 B ( 610 ).
- the terminal can now ask the applet selector 412 to launch or activate this applet by specifying the corresponding (complete) AID ( 612 ).
- the terminal itself to comprise a proxy AID interpreter 811 , as described in more detail below.
- the PIX portion 502 of the AID can be used to store additional information (i.e. Other 502 C, as shown in FIG. 5 ) which is potentially variable.
- additional information can relate to the card itself, such as its remaining memory capacity.
- this additional information relates to the card application corresponding to the AID in question.
- the Other 502 C portion can comprise a version number or configuration details for the application.
- the information in the Other 502 C portion is used for application selection.
- the information in the Other 502 C portion is used for further processing of the session.
- the additional information stored in the Other 502 C is normally not available to the terminal 110 (prior to interaction with card 102 ). Consequently, the terminal does not know the entire AID for matching. However, using an approach such as illustrated in FIGS. 6 though 6 F, the terminal can still locate the desired application on the card by virtue of the application's RID, Firewall ID, and Applet ID, which the terminal does know in advance.
- the terminal and the AID interpreter apply a shared or common data representation to the Firewall ID and the Applet ID.
- This common data representation can correspond to a primitive data type (such as an integer), or to a complex data type (such as a 16-byte string).
- This shared representation is generally larger than the actual number of bytes allocated to each parameter inside the stored AID (which is of course limited to a maximum of 11 bytes corresponding to the size of the PIX portion 502 of the AID). Consequently, the AID interpreter 411 performs the appropriate size conversion between the internally stored Firewall ID (of say 3 bytes) and the external data representation of the Firewall ID (of say 16 bytes), and vice versa, as required.
- Having a shared data representation for external manipulation of the Firewall ID 502 A and/or Applet ID 502 B portions allows the internal storage of these parameters to be altered without impacting terminal compatibility.
- a particular supplier i.e. having a particular RID 501
- the supplier may decide to increase the portion of the PIX 502 used to store the Firewall ID 502 B.
- terminal 110 is only concerned with the external manifestation of these parameters, such modifications are quite transparent to the terminal. (In contrast, if the terminal 110 were matching a precise AID string, as in existing systems, the byte reallocation between the Firewall ID and the Applet ID is potentially problematic).
- a further possibility is to divide the PIX portion at the bit (rather than byte) level, which helps to maximize utilization of this very limited coding space—e.g. a single byte can be split across two or more fields. This then requires somewhat more complicated processing of the internal representation (i.e. within the AID interpreter), given the need to work with individual bits. However, if the common data representation is maintained at the byte level, external programs (such as running on terminal 110 ) are shielded from the complexities of the internal bit operations.
- the situation is a little more complex in reverse, when going from the external representation to the internal representation.
- the value supplied from the terminal will generally be longer (say 16 bytes) than the space available (say 3 bytes) within the AID byte array on the card (or other internal storage facility). If most of the bytes in the AID parameter passed from the terminal to the card are zero, they can be truncated to fit the parameter into the AID byte array. On the other hand, if a non-zero byte is to be truncated, then this generally represents an error situation, and should be flagged accordingly.
- the AID components in question i.e. the Firewall ID portion 502 A and the Applet ID portion 502 B
- the present approach matches AID parameters (generally RID 501 , Firewall ID 502 A and Applet ID 502 B) via an AID interpreter in order to identify a desired application on a card.
- AID parameters generally RID 501 , Firewall ID 502 A and Applet ID 502 B
- the precise manner in which the AID and its components are encoded and stored onto card 102 is hidden behind the AID interpreter, and need not be known to the terminal 110 .
- This then enables terminal 110 to use a relatively stable and straightforward interface to identify applications across a wide range of cards 102 , preserving compatibility without unnecessarily constraining the contents of the AID itself. Consequently, the extra level of indirection, whereby the AID 401 contents are only accessed via AID interpreter 411 , provides great flexibility as to how the AID 401 is utilized and updated.
- FIGS. 6 through 6F depict from the handling of an AID in terms of multiple (logical) components, it will be appreciated that from an implementation perspective the separation of these parameters can be less apparent.
- the parameters i.e. RID 501 , Firewall ID 502 A and Applet ID 502 B
- RID 501 the parameters
- Firewall ID 502 A and Applet ID 502 B can be combined into a single byte sequence for ease of transport and manipulation (e.g. as a data packet).
- firewall ID can in fact be defined as the concatenation of RID portion 501 and Firewall ID portion 502 A. It will be appreciated that such an approach still allows a terminal or other software to distinguish between applications in different firewalls.
- this hierarchy reflects the fact that each RID operator (as defined by RID 501 ) defines its own set of firewalls, and so Firewall ID portion 502 A can only be sensibly interpreted given its corresponding RID portion 501 .
- An example of an implementation that adopts such a hierarchical structure is included in Appendix A.
- FIG. 7 is a flowchart that illustrates in more detail a mechanism for a card AID interpreter 411 to provide an AID in accordance within one embodiment of the invention.
- the processing of FIG. 7 illustrates in particular the situation where at least a portion of the AID is constructed dynamically using state information maintained on the card 102 .
- the AID is used to encode information about the state of the card or the application corresponding to that AID. Some of this data may be stored separately from the static portions of the AID (such as RID 501 , Firewall ID 502 A, and Applet ID 502 B 0 ). This state information then has to be dynamically combined with the static portions to create the complete AID.
- N.B The Other portion 502 C of an AID such as illustrated in FIG. 5 , may comprise static data and/or dynamic data).
- the flowchart of FIG. 7 commences with the card AID interpreter 411 receiving a method call for the (complete) AID ( 710 ).
- a call can arise during a session with a terminal, perhaps because the applet selector 412 wants to retrieve the AID for the matching application in order to return the AID to the terminal (as per reference numeral 696 of FIG. 6 ).
- the card AID interpreter may have to provide a complete AID in other circumstances as well.
- a smart card is asked to provide a complete listing of AIDs for the applets installed on the card, either for applet selection purposes (as in FIGS. 6 and 6A ), or for more general card management operations.
- Another possibility is that if a transaction updates some portion of the AID to be stored on the card, then it can request a read-out of the AID at the end of the session, in order to confirm that the update has been correctly saved onto the card.
- the AID interpreter responds to the request of reference numeral 710 by accessing the stored AID byte array ( 720 ).
- the exact manner in which this is performed depends on the internal implementation of the AID interpreter, as discussed above in relation to FIGS. 5A , 5 B, 5 C, and 5 D.
- the byte array retrieved at this stage represents the complete AID (i.e. there is a negative outcome to the test of reference numeral 730 ). In such cases, the card AID interpreter can immediately proceed to return the retrieved AID to the calling object (reference numeral 770 , via reference numeral 730 ).
- the AID comprises a dynamic component, i.e. there is a positive outcome from reference numeral 730 .
- test of reference numeral 730 may be omitted; rather, the card AID interpreter is hard-wired to include, or not to include, dynamic data, as appropriate for the applet in question).
- the dynamic component of the AID may represent, for example, a current balance for the card, the date of the last transaction of an application, or any other desired data.
- This dynamic data can, in principle, be stored within the card AID interpreter 411 itself, and so be directly accessible to the card AID interpreter. However, more generally the dynamic data is located separately from the card AID interpreter, which pulls in the dynamic data on-the-fly when it is required to generate a complete AID.
- the dynamic data is held in general card data storage 414 (see FIG. 4 ), which can be implemented in a portion of EEPROM 314 assigned to or accessible by the application in question.
- FIG. 7 illustrates one particular situation, where the card AID interpreter 411 calls the applet to which the card AID interpreter belongs to provide the dynamic data ( 740 ). The applet responds by obtaining the dynamic data, for example by accessing one or more subobjects within the applet that are responsible for maintaining the dynamic data. Next, the applet returns this dynamic data to the card AID interpreter, for example by using a call-back mechanism ( 750 ).
- the AID interpreter 411 When the AID interpreter 411 has obtained the desired information, it generates a composite or final AID by combining the stored and dynamic components as appropriate ( 760 ). The newly generated AID can then be returned ( 770 ) in response to the original request at reference numeral 710 .
- reference numeral 735 there are many other possible implementations of reference numeral 735 apart from that shown in FIG. 7 .
- the card AID interpreter itself maintains the dynamic AID component, in which case it would not need to contact the applet for this information.
- the applet may (upon prompting) write the dynamic component directly into the low-level AID storage facility.
- reference numeral 720 is postponed until after 735 , whereupon the card AID interpreter 411 would, in effect, retrieve a complete and already updated AID.
- Other possible implementations will be apparent to the skilled person.
- the purse object may perhaps store two parameters in card data 414 , the first representing the amount of money deposited onto the card, and the second the amount of money spent from the card. The difference between these two amounts then gives the current balance, and it may be this figure (the balance) that is to be incorporated into the AID.
- the purse object responds to the call of reference numeral 740 by calculating the current balance (i.e. by subtracting the amount spent from the amount deposited), and then returning the balance to the card AID interpreter for incorporation into the AID.
- the AID not only is the AID assembled dynamically, but it also incorporates data that does not normally exist per se on the card (rather, the dynamic data that is incorporated into the AID is derived from other data values that are present on the card).
- the dynamic data can reflect the date and/or time of last use of the application, the location of the terminal of last use, or any other desired application or card property. This then gives considerable flexibility in terms of how the card, and in particular the AID, is used.
- the dynamically inserted data is not necessarily subject to change during the lifetime of the card or application.
- this data can instead represent a fixed (or relatively fixed) property, such as the remaining memory capacity of the card, the version number of an applet, etc.
- a fixed property such as the remaining memory capacity of the card, the version number of an applet, etc.
- One advantage of storing details of this (potentially fixed) property or state outside the card AID interpreter 411 is where the same data is to be utilized by multiple applications.
- the AID may be constructed to comprise an indication of which encryption facilities are present on the card, since this may impact the type of operations that a terminal can perform with the card.
- these encryption facilities are common to all applications on the card, it is convenient for the relevant indication to be stored in a single, centralized location (such as in card data 414 ).
- the card AID interpreters for the various applications on the card 102 can use the procedure of FIG. 7 to retrieve this centralized indication of encryption facilities as dynamic state information. The retrieved information can then be incorporated into the AID for the respective applications, as and when required by the AID interpreters 411 . It will be appreciated that storing a single copy of data (in this case the indication of encryption facilities) in a shared resource, such as data block 414 , where it can then be accessed by multiple applications on the card, is generally more efficient than encoding the data separately into the AID for each application on the card.
- Another benefit of storing dynamic data outside the card AID interpreter 411 is that the card AID interpreter itself does not need to know how to access, manipulate or format the dynamic data. Rather, this can be left to those objects that primarily interact with the dynamic data (and possibly update it). This then allows a higher degree of generality for the card AID interpreter 411 itself.
- the card AID interpreter knows whether or not the AID comprises dynamic data, and if there is such dynamic data, how to obtain it (e.g. which method to call on the applet) and how to incorporate it into the AID byte string (perhaps to insert the dynamic data as Other 502 C in bytes 13 – 15 ).
- the card AID interpreter does not need to have any further understanding of or interaction with the dynamic data.
- the card AID interpreter 411 does not calculate the balance itself. Rather, the card AID interpreter calls its applet for the dynamic data to incorporate into the AID, and receives back the balance (already calculated) in response.
- the applet itself can obtain the balance by calling an appropriate method on the object responsible for maintaining the two data values in question (such as a purse object). This object then performs the necessary subtraction in order to produce and return the current balance to the card AID interpreter.
- the same object would also generally be responsible for suitably formatting the dynamic data for inclusion in the AID. For example, where the balance details are maintained in the purse object as real numbers (or possibly integers), the result can be converted into a byte string before return to the card AID interpreter for compatibility with the rest of the AID.
- the presence of the AID interpreter 411 on smart card 102 relieves the terminal 110 of having to utilize the AID 401 directly in order to locate a desired application. Nevertheless there are other situations where the terminal 110 itself does want to be able to access and interpret the AID 401 . For example, there may be other information encoded into an AID 401 passed to the terminal 110 that the terminal desires to use during the session, such as the Other portion 502 C (see FIG. 5 ).
- FIG. 8 which illustrates processing performed at a terminal 110 during a session with a smart card 102 after preliminary interactions between the terminal 110 and the card 102 , such as card activation (see FIG. 1B ), have been completed, in accordance with one embodiment of the invention.
- the flowchart of FIG. 8 commences with the terminal specifying a desired matching application ( 8005 ). This operation corresponds in general terms to reference numeral 166 of FIGS. 1B and 1C .
- the request for a matching application is performed using multiple parameters, such as RID 501 , Firewall ID 502 A, and Applet ID 502 B. These parameters allow the smart card to identify a matching application, as described above in relation to FIGS. 6 through 6E .
- the smart card then returns the AID for the matching application, which is duly received by the terminal (reference numeral 8010 , see also reference numeral 180 of FIGS. 1B and 1C ).
- the terminal Having received the AID from the card, the terminal has to interpret the AID in order to complete the desired user interaction.
- maintaining knowledge of the AID structure within the terminal itself can be problematic, particularly where the terminal 110 supports multiple applications from a variety of suppliers.
- a matching application can now be identified on the basis of certain parameters, such as Firewall ID and Applet ID, rather than requiring the terminal to store a complete AID string for this purpose.
- Firewall ID and Applet ID rather than requiring the terminal to store a complete AID string for this purpose.
- a terminal always knows from international standard ISO/IEC 7816-5 that the first five bytes of an AID represent the associated RID 501 . Accordingly, once the terminal has received the incoming AID from the smart card 102 , it is able to retrieve this RID portion 501 by extracting the first five bytes of the received AID ( 8020 ).
- This network resource identifier represents a Uniform Resource Locator (URL) on the Internet (or similar intranet or extranet). Alternatively, it may represent any other suitable type of network address or resource specifier, etc.
- URL Uniform Resource Locator
- the terminal may maintain a lookup table that maps from RID portion 501 to specific URL. Alternatively, the terminal may follow some algorithm to convert from the RID to a URL.
- some hybrid of the above two approaches is adopted, such as using the lookup table as the first option, and then forming a URL directly if there is no entry in the lookup table for that particular RID.
- reference numeral 8030 involves forming a URL directly from the RID, then some mechanism is provided (such as a constructor method) for converting from the RID byte string into a URL.
- the RID byte string can first be represented in hexadecimal form, which is then transformed into a corresponding text string for incorporation into a URL.
- Alternative methods for deriving a network resource identifier from the RID byte sequence can also be employed, such as using one or more bytes directly to specify an IP address of a URL (this can be done by using the “%” character, followed by two hexadecimal characters to specify an octet).
- any initial mapping of the AID into a URL by the terminal is non-semantic, in that the terminal converts the AID byte sequence into a URL via some mechanism such as the hexadecimal transformation discussed earlier.
- this mapping process is not expected to recognize or interpret any components of the AID (other than perhaps the RID, whose position within the AID is predefined by standard).
- terminal 110 now sends a request to the URL or other address corresponding to the RID 501 ( 8040 ).
- the terminal receives back over the network a response comprising some form of material relevant to the AID ( 8050 ), which is then used to support further activities in the session ( 8060 ).
- the manner of this use depends upon the nature of the downloaded material (e.g. whether it is code, data or a network service address, etc.).
- the downloaded material comprises an AID interpreter for use on the terminal 110 , will be discussed in more detail below.
- the RID can be used to define the domain name portion of a URL.
- the RID can be provided in effect as an http parameter associated with the domain.
- FIG. 8A provides more detail for FIG. 8 .
- the network resource identifier represents a URL which is derived from the RID by performing a lookup in a table or database, etc. (reference numeral 8030 A, corresponding to reference numeral 8030 in FIG. 8 ).
- the table or database is maintained locally on the terminal.
- the terminal downloads code and/or data as required from this URL (reference numeral 8040 A, which can be regarded as corresponding to both reference numerals 8040 and 8050 in FIG. 8 ).
- the URL initially derived from the RID 501 comprises a guide or indicator to one or more sites from which further material can be accessed.
- the URL initially obtained at 8030 can provide a link to a further web site where the material is located (perhaps using the http redirect mechanism).
- the terminal then follows this link (or chain of links) in order to retrieve the relevant material.
- An example of this is where the terminal forms a URL comprising a generic portion, representing perhaps a constant Web site (and page), and an RID-dependent portion, comprising the RID in hexadecimal form.
- the RID-dependent portion is therefore presented in effect as an entry field associated with the generic page (analogous to encoding a search term into a URL for a search engine). This can then be used to determine the address of further material.
- FIG. 8B Such an embodiment is illustrated in the flowchart of FIG. 8B , which again provides more detail for FIG. 8 .
- the RID received from the card is appended as a search parameter to a predetermined first URL stored locally on the terminal (reference numeral 8030 B, corresponding to reference numeral 8030 in FIG. 8 ).
- This then forms a search request which is sent to the first URL (reference numeral 8040 B, corresponding to reference numeral 8040 in FIG. 8 ).
- the terminal receives a second URL (reference numeral 8050 A, corresponding to reference numeral 8050 in FIG. 8 ).
- the terminal now downloads code and/or data from this second URL for use in the session with the card (reference numeral 8060 B, corresponding to reference numeral 8060 in FIG. 8 ).
- the terminal there is a very wide range of material that can potentially be obtained by the terminal at reference numeral 8050 in FIG. 8 .
- the material initially downloaded for use in the session is in fact the second URL, which then directs the terminal to another location from which additional material can be obtained.
- the downloaded material comprises a data mapping, representing the structure of the AID 401 used by that organization (reference numeral 8050 C, corresponding to reference numeral 8050 in FIG. 8 ).
- the terminal can then use this mapping in order to extract desired information (such as a current balance) from the AID supplied from the smart card (reference numeral 8060 C, corresponding to reference numeral 8060 in FIG. 8 ).
- the terminal receives over the network a full set of possible mappings for that RID, and then selects an appropriate mapping from this set based on the particular AID that it obtained from the smart card.
- the terminal incorporates the full AID into the initial network request of reference numeral 8040 D (corresponding to reference numeral 8040 in FIG. 8 ).
- the web server receives this request ( 8043 ) and uses the complete AID to select the material to supply back to the terminal (reference numeral 8046 ), downloading only the material (e.g. a mapping) appropriate to that particular AID ( 8049 ), which is received by the terminal in due course (reference numeral 8050 D, corresponding to reference numeral 8050 of FIG. 8 ).
- the material received by the terminal over the network comprises code (potentially in addition to other forms of material).
- code potentially in addition to other forms of material.
- code components such as a user interface for the terminal to use with the cardholder, or a proxy AID interpreter 811 (see FIG. 4 ) to allow the terminal 110 to decode the AID received from the smart card.
- the code downloaded is responsible for actual processing of application data during the session with the card (i.e. forming part of proxy code 410 ). It will be appreciated that two or more of these code components can be downloaded in any given session.
- the code can be provided to the terminal in a variety of forms, such as raw class files or as Java Archive (JAR) files or packages, each containing (compressed) Java code plus manifest.
- the downloaded code can then indicate further classes or packages that may need to be retrieved from over the network in order for the application to run.
- the terminal receives a Java Application Descriptor (JAD) file.
- Java Application Descriptor This is an XML file that comprises one or more URLs specifying where the relevant application code is located, as well as the location of any data associated with the application.
- the XML file can further comprise one or more descriptors relating to the application.
- the terminal can then download the code and data in accordance with the information provided in the JAD file.
- multimedia data such as a logo image to be utilized for the user session on a terminal screen
- some form of authorization or verification such as a third party certificate guaranteeing the bona fide nature of a merchant involved with the session.
- the material can also comprise a further network resource identifier representing a location, such as a portal, where a desired service can be obtained.
- a service may be the download of some product (e.g. music), some on-line purchase facility (e.g. for buying aircraft tickets), some data service (e.g. the supply of recent financial results), and so on.
- This further network resource identifier can also represent a site at which documentation relating to the commercial transaction (such as contractual details) is located.
- the terminal is specialized for a particular application—e.g. the terminal may comprise a facility to print aircraft tickets, or to burn music downloaded from the network onto a customer CD. The nature of the terminal will then determine the range and nature of application processing available to a customer at the terminal.
- the terminal can download multiple different items for a single smart card session. For example, from the initially derived network resource identifier (at reference numeral 8030 ), the terminal may obtain a set of further URLs specifying locations of various types of material relevant to the session (code, contractual terms, payment service location, etc).
- FIG. 8E illustrates a flowchart for one embodiment of the invention that takes into account the possibility of the terminal already having the specified material.
- a test is made at reference numeral 8033 E to determine whether or not the terminal already has material from the relevant network address. If so, this material can be used directly by the terminal, without having to be downloaded over the network. (The remainder of the processing of FIG. 8E is the same as that for FIG. 8 ).
- the terminal can use more than just the RID portion 501 of the AID in the processing of FIG. 8 .
- the PIX portion can be provided likewise as an input parameter in the URL request.
- the web server can then utilize the PIX portion in determining the response that is provided back to the terminal (see reference numeral 8046 of FIG. 8D ).
- the web server may determine the type of application associated with the AID (based perhaps on the Applet ID in the PIX portion), and then provide code back to the terminal that is appropriate for interacting with this particular application.
- the web-site or other network location performs some semantic interpretation of the AID obtained from the smart card by the terminal, so that the response back to the terminal incorporates data extracted from the AID (such as a current balance on the card, or other such state information included in the AID).
- This provides one mechanism to avoid the terminal itself having to be able to decode or interpret the AID byte string.
- FIG. 8F Such an embodiment is illustrated in the flowchart of FIG. 8F , which generally corresponds to that of FIG. 8D , except that at 8046 F, the server interprets the received AID in order to extract relevant information. This extracted information can then be returned to the terminal ( 8049 F) for further processing in the session.
- FIG. 8 following reference numeral 8010 (receipt of the AID from the smart card 102 ) is generally independent of the exact mechanism or circumstances whereby this AID is obtained.
- the AID may be received following the operations described in relation to FIGS. 1B or 1 C (i.e. without the use of multiple parameters to specify a matching application on the smart card).
- the processing of FIG. 8 might also be performed if a terminal receives an AID from a smart card not as part of the initial selection of a matching application, but rather at some subsequent stage of the session between the card 102 and the terminal 110 .
- FIG. 9 depicts in more detail the server processing in response to the (http) request of reference numeral 8040 of FIG. 8 for one particular embodiment of the invention.
- Processing starts with a first server receiving the http request from the terminal ( 9010 ), where it is assumed that this request comprises the relevant AID (RID and PIX portions).
- This first server extracts the RID portion 501 from the received AID ( 9020 ), and uses the RID to determine the URL of a second server ( 9030 ), generally by means of a database or lookup table available to the first server (either locally or over a network).
- the first server therefore can be considered as representing a form of generic gateway or portal, and the RID as a form of search term submitted to the portal.
- the first server now in effect forwards the incoming request to the second server ( 9040 ). It is assumed that the second server is associated with the particular organization corresponding to the relevant RID. In other words, an organization having the RID in question maintains a web site on the second server. This web site is responsible for receiving and processing AID strings belonging to that organization (i.e. having an RID portion corresponding to that organization).
- the AID string from the terminal is therefore received at the second server from the first server ( 9045 ), and decoded using an appropriate AID interpreter or other mechanism. (It is assumed that the organization knows how to decode its own AID strings).
- the second server Using the information obtained from the decoded AID, the second server now identifies a Java Application Descriptor (JAD) file ( 9050 ) to be used by the terminal in processing the smart card.
- the JAD file is generally retrieved from a stored set of such files, but might also be built dynamically in response to the terminal request.
- the identified JAD file comprises a URL or other reference indicating the location of an AID interpreter.
- the terminal can then use this reference to download code for decoding and processing the AID itself.
- the JAD file can also contain any other appropriate information, code references, descriptors, etc that may be required or useful for the session.
- the second server now places the JAD file at a network-accessible location, and returns a URL for this location to the first server ( 9060 ).
- the first server duly receives the URL ( 9065 ), and in turn forwards the URL back to the terminal ( 9070 ).
- This URL therefore allows the terminal to retrieve the JAD file constructed by the second server, and then to download any code that it references.
- the JAD file itself can be transmitted along this route.
- the first server returns to the terminal the URL of the second server.
- the terminal itself is then responsible for communicating directly with the second server, rather than using the first terminal as an intermediary. If so desired, this can be implemented in a straightforward manner by using the http re-direct mechanism.
- FIG. 10 depicts an environment in which the procedures of FIGS. 8 and 9 can be implemented in accordance with one embodiment of the invention.
- applet 351 is installed on card 102 , and incorporates AID 401 and card AID interpreter 411 .
- the AID 401 for the desired application is extracted from applet 351 and passed to terminal 110 (such as previously described in relation to FIG. 6 , for example).
- the AID 401 is split into its two main constituents, namely RID 501 and PIX 502 .
- the former portion i.e. RID 501
- RID 501 is used to key into a lookup table 810 , which contains a mapping of RID to URL.
- a corresponding URL 805 can then be determined from the lookup table 810 .
- This URL corresponds (in this particular situation) to a download site 860 for code to be used in processing the session involving card 102 .
- a request 805 for such code is therefore sent to the download site 860 .
- this request may incorporate the full AID string received from the card.
- This AID string (or portions of it) can then be used by the download site to identify particular code of relevance for this session.
- a code package 806 for interpreting the AID 401 is returned over network 850 to terminal 110 .
- This code package is then installed into terminal 110 to form a proxy AID interpreter 811 .
- the newly installed code allows the proxy AID interpreter 811 to retrieve and interpret the data encoded in PIX 502 portion of AID 402 , thereby permitting the terminal to continue processing the session with the card 102 .
- Proxy AID interpreter 811 on the terminal 110 comprises code that is analogous to or shared with AID interpreter 411 on the card, and may potentially be a superset (subclass) of the card AID interpreter 411 .
- proxy AID interpreter 811 is generally not only able to extract a firewall and applet identifier from PIX 502 , but it is also able to access any other pertinent information that may be encoded into the PIX 502 . (This additional information might relate to the state of the application on the card, such as described above in relation to FIG. 5 ).
- FIG. 11 illustrates another embodiment, which is similar to that of FIG. 10 , but this time a slightly more complex chain of operations is involved for the terminal 110 to obtain the code for processing a session.
- the terminal directs a query 805 to this portal site.
- the query comprises the AID of applet 351 .
- the AID is incorporated into the URL associated with the request to portal site 862 (generally in an analogous manner to the way that a search string is supplied to a web search engine).
- the portal site 862 responds to the incoming query 805 by providing in return the URL 805 A of the code download site 860 .
- portal site obtains this URL from database 865 using the received AID or at least a portion of it, such as the RID, as an index into the database 865 .
- the code download URL 805 A is therefore received back at terminal 110 from portal site 862 .
- the terminal now generates a code download request 808 directed to the received code download URL.
- the terminal 110 may potentially comprise the AID in this code download request 808 .
- the code download request 808 is received at code download site 860 , which returns code 806 corresponding to the particular URL of the request.
- This code download mechanism is to allow the terminal 110 to install its own proxy AID interpreter 811 , for use during the session with applet 351 , as described above in relation to FIG. 10 .
- code downloaded from site 860 to terminal 110 may be dependent upon the AID (if any) included in code download request 808 .
- the AID might contain membership details for the cardholder.
- the code 806 for download can then be selected so as to only offer services appropriate to the particular class of membership of the cardholder (as determined from the AID).
- mapping table 810 represents in effect a local cache of data from code URL database 865 .
- terminal 110 first attempts to find the location of code download site 860 using lookup table 810 .
- this table stores the mappings for recently processed RIDs.
- the terminal contacts portal site 862 to derive the location of code download site 860 from database 865 (which is assumed to be much larger and more complete than lookup table 810 ). Any mapping information obtained in this manner from the code URL database 865 may be added into the lookup table 810 for future use (depending on the particular cache occupancy strategy deployed).
- a proxy AID interpreter 811 that is specific to the particular AID of the inserted card 102 complements the initial AID matching procedure described above (see e.g. FIGS. 6 through 6F ).
- the provision of card AID interpreter 411 on the card 102 , and the use of Applet ID and Firewall ID (rather than the AID byte string itself) to specify a desired applet 351 allows a terminal to obtain the AID of the desired applet without needing to know (initially) the specifics of the AID itself.
- the AID obtained from the card can then be used by the terminal to identify and acquire a proxy AID interpreter 811 that is able to parse and manipulate the AID in question.
- the appropriate proxy AID interpreter 811 is downloaded over a network onto the terminal in order to complete the relevant session with the card 102 . Accordingly, the dynamic provision of a proxy AID interpreter to a terminal helps to allow the PIX portion 502 of an AID to be used for more complex and varied tasks, which may perhaps be modified over time, without compromising compatibility at the set of terminals already present in the field.
- a default structure may be defined for AID 401 .
- Terminal 110 then has preinstalled a proxy AID interpreter 811 that is able to parse and extract information from an AID conforming to this default structure.
- proxy AID interpreter 811 that is able to parse and extract information from an AID conforming to this default structure.
- lookup table 810 may instead indicate that the default proxy AID interpreter is to be used (perhaps by simply having a null entry for that RID). This can be regarded as analogous to the processing of FIG. 8E .
- the RID to URL mapping (box 810 A) may still be performed, but the response from the portal site 862 then indicates that the default proxy AID interpreter is to be used. In this case there is no need for the terminal to send a subsequent code download request 808 , assuming that the default proxy AID interpreter is already installed on the terminal.
- a further possibility is that the terminal attempts to use the default AID interpreter 811 if it is unable to find any other suitable code for this session, for example because there is no entry for the RID in the lookup table 810 or the portal site 862 (depending on the particular embodiment) or because a network connection is currently unavailable.
- the lack of a positive indication of which proxy AID interpreter for the terminal to use for a given AID might be taken as an error, possibly causing the terminal to abort the session.
- FIG. 11A is a flowchart illustrating the operation of one embodiment of the invention in which the terminal may utilize a default proxy AID interpreter.
- the method starts with the terminal obtaining the AID from the card (reference numeral 1110 , corresponding generally to reference numeral 8020 in FIG. 8 ).
- the terminal now determines whether the RID corresponds to the default interpreter ( 1120 ). If not, then the terminal attempts to download the AID interpreter corresponding to the RID, as previously described in relation to FIGS. 8 and 11 ( 1130 ). A test is now performed to see if this download has been successful ( 1140 ). If so, then the downloaded AID interpreter can be used for the session ( 1150 ).
- the default AID interpreter is used ( 1155 ) if this is the one indicated by the RID received from the card at 1120 , or if the download was unsuccessful at 1140 .
- the terminal now continues to process the session with the card ( 1160 ). Note that there may be certain restrictions on the functionality available during such processing if the default AID interpreter is being used because the specified AID interpreter is unavailable (i.e. the test of reference numeral 1140 was negative).
- code obtained from a location such as code download site 860 can comprise a plug-in for the default proxy AID interpreter, or may be utilized via any other suitable mechanism.
- the downloaded code may subclass portions of the default proxy AID interpreter in order to provide more specific functionality in certain areas.
- FIG. 12 One embodiment of the invention which supports such processing is illustrated in the flowchart of FIG. 12 , which commences in the same general manner as the flowchart of FIG. 1 .
- the terminal detects insertion of the card ( 162 ), and consequently activates the card (reference numerals 164 , 172 ).
- the terminal requests the applet selector 412 to provide it with the full set of AIDs for the card—i.e. the AID for each available applet 351 on the card ( 1245 ).
- the applet selector receives this request ( 1254 ), and according to one embodiment, uses a get_AID( ) method call on the card AID interpreter 411 of each application installed on the card in order to retrieve the AID for that application ( 1256 ).
- the applet selector may first have to call the applet itself in order to locate the card AID interpreter 411 for that particular applet (analogous to reference numeral 681 of FIG. 6 ).
- the AIDs for different applications may be collected in parallel, or one after another, or via any other suitable strategy.
- the AIDs for the card applications are now returned from the card 102 to the terminal 110 (reference numerals 1258 , 1246 ), where the RID is extracted from each AID ( 1247 ). This RID then allows the terminal to identify and to acquire (if necessary) a proxy AID interpreter 811 to be used in processing the corresponding AID ( 1248 ). Note that the same procedure can be used here to obtain the appropriate proxy AID interpreter 811 as described above in relation to FIGS. 8 and 9 . (It will be appreciated that there may be a different proxy AID interpreter 811 to download for each application 351 on card 102 ).
- the terminal can now decode that AID to determine the Firewall ID and Applet ID encoded into the AID. This then allows the terminal to perform the matching of RID, Firewall ID and Applet ID in order to identify a desired application for use in this particular session ( 1249 ).
- the proxy AID interpreter 811 can adopt the same procedure to identify a matching application as described above in relation to card AID interpreter 411 on the card itself (see FIG. 6 ).
- the terminal notifies the card (reference numeral 182 , see also FIG. 1C ) of the applet that matches the above parameters (RID, Firewall ID and Applet ID). According to one embodiment, this is achieved by returning the (complete) AID of the desired matching application from the terminal 110 to the smart card 102 . This then allows the card to launch the specified matching applet (reference numeral 190 , see also FIG. 1C again).
- FIG. 12A illustrates in more detail some of the processing of FIG. 12 .
- the dotted box in FIG. 12A corresponds to the box of the same number in FIG. 12 ).
- the procedure of FIG. 12A is performed in respect of each AID byte string received by the terminal 110 from the card 102 .
- the procedure of FIG. 12A commences with the extraction of the RID from the AID ( 1247 ), as previously discussed in relation to FIG. 12 .
- a test is now performed to see if the RID for this received AID matches the RID of the desired application ( 1212 ). If not, then it is known that it is not desired to activate the applet on the card from which this AID has been received, and so the AID can be discarded, or other appropriate action taken ( 1230 ).
- the terminal now has to determine which proxy AID interpreter to use for the AID ( 1214 ), whereupon the relevant proxy AID interpreter is identified and installed onto the terminal ( 1216 ) (if it is not already present). Note that the identification and installation of the desired proxy AID interpreter is generally driven off the RID, as described above in relation to FIGS. 8 and 9 .
- the proxy AID interpreter 811 is now initialized with the corresponding AID string from the smart card 102 ( 1218 ), which then allows it to proceed with the parameter matching of reference numeral 1249 .
- FIG. 13 depicts a variation on the embodiments of FIG. 6 and FIG. 12 .
- the embodiment of FIG. 13 commences as these other two embodiments, with the terminal detecting insertion of the card ( 162 ), and then activating the card in response to such detection (reference numerals 164 and 172 ).
- the terminal requests not only the set of AIDs from the card, but also the three application identifying parameters for each application—i.e. the RID 501 , the Firewall ID 502 A, and the Applet ID 502 B ( 1345 ).
- the applet selector on the card receives this request ( 1354 ), and responds by calling the get_AID( ), get_RID( ), get_FirewallID( ) and get_AppletID( ) methods for each applet ( 1356 ). Again, this may involve an initial call to the applet in question, in order to locate the card AID interpreter 411 for that applet (as shown in FIG. 6 ).
- the applet selector now returns the set of parameters for each applet back to the terminal (reference numerals 1358 and 1346 ).
- the terminal matches the parameters received from the card against the parameters for the desired application ( 1347 ). Note that because this matching is being performed using parameters supplied from the card, rather than the terminal itself having to derive the parameters from the AID string (as in the procedure of FIG. 12 ), there is no need at this stage for the terminal to have the relevant proxy AID interpreter(s) 811 installed or downloaded.
- the terminal 110 has just a single application to match. Once this (single) application has been identified at 1347 , processing can now proceed to 182 , where the terminal instructs the card to launch this applet (for example by providing its full AID), with the card then responding accordingly ( 179 ).
- the proxy AID interpreter 811 corresponding to the selected applet may be pre-installed on the terminal. This is particularly likely if the terminal 110 only supports a single application, since in this case only one proxy AID interpreter 811 will generally be needed, but may also apply if the terminal supports multiple applications.
- the terminal downloads the proxy AID interpreter 811 for the matching application either before, during, or after reference numeral 182 . (The download of the AID interpreter is not shown in FIG. 13 , but can be as illustrated with respect to FIG. 8 or 9 , and the subsequent installation and initialization of FIG. 12A ).
- the precise timing of any such download of a proxy AID interpreter 811 to terminal 110 is based at least in part on the particular selected application.
- the AID string may contain some data value that affects the start-up or operation of the applet on the card at 660 .
- the proxy AID interpreter 811 should be available on terminal 110 to decode this data value before the terminal can send the appropriate applet launch command to the card at 182 .
- multiple applications may be matched at 1347 .
- the terminal tries to identify all those applications that are present on the card that the terminal could potentially interact with (i.e. conduct a commercial transaction with). Accordingly, if there is a first set of applications installed on the card, and a second set of applications supported by the terminal, then at 1347 the terminal identifies the intersection of these two sets (such as by looking for matching parameters, namely RID, Firewall ID, and applet ID).
- the terminal now presents a choice or listing of these matching applications to a user, for example as a menu on a touch screen ( 1348 ).
- This enables the holder of a multi-function card 102 who is acting with a multi-function terminal to select the particular application to be used for this session ( 1349 ), again perhaps by using a touch-sensitive screen at a kiosk terminal. (More generally, the user would select the desired type of service or operation, and the terminal would then invoke the application corresponding to this form of service).
- the terminal now informs the card of the application that has been selected by the user ( 182 ), allowing the card to launch this application accordingly, as previously described ( 190 ).
- reference numeral 1249 could represent a determination of those applications mutually supported by both the terminal and the card, with the user then selecting one of these applications.
- the terminal then informs the card of which application to launch, as described above in relation to FIG. 13 (reference numerals 182 and 190 ).
- the presentation of options to a user is dependent on information encoded into the AID (other than the RID, Firewall ID and Applet ID components received from the smart card itself).
- an AID may incorporate an expiry date encoded into Other portion 502 C, after which the associated application is no longer available to the user.
- one possibility is to download the proxy AID interpreter 811 for the application (such as by using the method of FIG. 8 ) prior to presenting the user with the set of available options (i.e. before reference numeral 1348 ). This then allows data from the various AIDs to be decoded by the respective proxy AID interpreters, and used to tailor suitably the options presented to the user at 1348 . For example, if an application expiry date has passed, the corresponding application can then be omitted from the list of applications presented to the user.
- the card AID interpreter 411 may obtain not only the RID, Firewall ID and Applet ID, but also an expiry date encoded into the AID. (From the perspective of the card AID interpreter 411 , the expiry date is generally simply an additional piece of abstract data encoded into the Other portion 502 C of the AID 401 ). This expiry date can then be supplied by the card to the terminal at 1358 , along with the RID, Firewall ID and Applet ID. The terminal can then use this additional parameter as appropriate in further processing (for example, in making a decision as to whether or not the corresponding application is available for the cardholder to use).
- each application has its own associated proxy 410 and associated back office program 130 (see FIG. 4 ).
- the proxy for this application can automatically be invoked on terminal 110 in response to the insertion or activation of card 102 .
- the proxy may only be sleeping or suspended between sessions with different cards.
- the terminal supports multiple applications, there may be a different proxy for each application.
- the cardholder is able user to select the particular application to be used with the inserted card (such as discussed above in relation to FIG. 13 )
- the terminal needs to ensure that the correct proxy is invoked to handle the user selected application.
- the terminal can be provided with a program (not shown in FIG. 4 ) analogous to the applet selector program, which is used to determine the appropriate proxy to handle any given card session.
- this selector program is responsible for the interaction with the card through to receipt of the user selection of the desired application ( 1349 ).
- the selector program can then launch the proxy corresponding to the user selection.
- the proxy 410 can then download the corresponding proxy AID interpreter (if not already present), as well as launching the selected application on the card (reference numerals 182 and 190 ).
- FIG. 13A presents a flowchart depicting the selection and activation of a proxy program on terminal 110 in accordance with one embodiment of the invention. Note that this procedure can be regarded as following on from the flowchart of FIG. 12 , whereby it is assumed that the proxy AID interpreter 811 corresponding to a particular AID (and corresponding applet) on the smart card 102 has already been installed and initialized on the terminal 110 . In this case, the procedure of FIG. 13A commences with a determination of the proxy to be used with this application ( 1330 ). Such a determination can be made based on material retrieved over the network (see FIGS. 8 and 9 above and associated discussion), or alternatively the terminal may have local knowledge of the proxy to use with this particular application. Another possibility is that a proxy itself contains information (such as the RID, and perhaps other parameters as well) that allow the proxy to be matched to a corresponding card application
- this proxy is installed into the terminal ( 1332 ), unless it is already present.
- the proxy code can be obtained over a network, in the same manner as the proxy AID interpreter code 811 (see FIGS. 10 and 11 ).
- the proxy code can now be initialized with the proxy AID interpreter code that has already been downloaded ( 1334 ), which in turn can be initialized with the AID received from the application (such as at reference numerals 1246 or 1346 ). This leads to the general configuration of FIG. 4 , whereby substantive processing of the user session can commence.
- the approach described herein permits a more flexible and powerful use of an AID 401 on a smart card 102 .
- One further mechanism for exploiting this increased flexibility is to use the AID to store information concerning the initial configuration of an application at load time.
- FIG. 14 is a flowchart that depicts such a process in accordance with one embodiment of the invention.
- the process of FIG. 14 begins with loading the Java classes for an applet 351 onto the smart card 102 ( 1010 ).
- these classes are assembled into a package (referred to as a CAP file).
- instantiation commences ( 1020 ).
- objects are created based on the class files. Note that in a smart card environment, this instantiation is a one-off procedure at load time, rather than being performed each time the applet is executed, as in a normal desktop environment.
- Object instantiation is followed by initialization of variables ( 1030 ), and then configuration of the applet occurs ( 1040 ). Finally, any other necessary initialization and personalization completes ( 1050 ), whereby the card is now ready for use.
- FIG. 15 illustrates certain aspects of the procedure of FIG. 14 in more detail, in particular the role of the AID in the card configuration process, in accordance with one embodiment of the invention. Note that the dotted outline boxes in FIG. 15 correspond to reference numerals from FIG. 14 .
- the card AID interpreter 411 is created (including the AID object hierarchy such as shown in FIGS. 5A , 5 B, 5 C or 5 D). According to one embodiment, this is achieved by calling appropriate methods (such as a factory method) on the applet being installed in order to instantiate the card AID interpreter 411 ( 1510 ).
- the configuration program now generates the actual AID value to be stored into the card as part of the initialization (reference numeral 1520 in FIG. 15 ).
- reference numeral 1520 In FIG. 15 , there is some flexibility in the timing of reference numeral 1520 , for example, in some embodiments the creation of the AID may precede the creation of the card AID interpreter at 1510 ).
- the newly created AID value can be used to encode various configuration data relating to the application that is being installed. Examples of configuration data that may be stored in the AID in this manner include: an indication of the physical and/or software capabilities of the card (e.g.
- the card AID interpreter 411 1530 .
- a store_AID( ) method (or similar) is called on the card AID interpreter, and this is passed the AID string that was generated at 1520 .
- the card AID interpreter then acts to save the newly received AID string onto the card. The manner in which this is accomplished will depend upon the internal implementation of the card AID interpreter and how the AID is to be stored (such as depicted in FIGS. 5A , 5 B, 5 C and 5 D). For example, in one embodiment the AID string is ultimately saved as a single byte array (as in FIG. 5A ), or may be distributed into multiple components, each associated with a different AID subobject (as in FIG. 5B ).
- a security procedure associated with storing the AID to ensure that a duly saved AID is not subsequently corrupted (either deliberately or accidentally) by an inappropriate repeat call of this facility.
- some form of password can be required to use the store_AID( ) command, or alternatively the store_AID( ) command is perhaps only enabled at applet installation time.
- the AID can then be accessed during subsequent configuration of the applet in order to derive the configuration information encoded into the AID ( 1550 ).
- the AID is accessed by making an appropriate call on the card AID interpreter 411 . In one embodiment, this involves making a get_ABD( ) method call on the AID interpreter, such as previously described, and then extracting the desired configuration information from the AID string. However, this generally requires the applet itself (or other configuration facility) to be able to decode the configuration information encoded into the AID. Thus in another embodiment, the card AID interpreter 411 itself decodes the configuration information stored in the AID string. Accordingly, in this embodiment the card AID interpreter 411 supports one or more method calls that provide specific access to configuration information from the AID string.
- the card AID interpreter 411 can support a get_AIDConfiguration( ) method call, which returns the full set of configuration data from the AID string, appropriately organized into a data structure or such-like.
- the card AID interpreter 411 can include a subobject which provides access to such data. It is also possible that the card AID interpreter 411 supports calls to access individual components of configuration data stored in the AID, e.g. a get_CardMemory( ) to retrieve the memory capacity on the card, although this tends to lead to a rather more complicated method signature for the card AID interpreter.
- configuration data can then be used to control the particular software and data configuration adopted for the applet ( 1560 ).
- Examples of configuration data that can be stored into the AD include parameters that determine the characteristics of cryptographic algorithms used on the card (e.g. number of bits); memory usage (e.g. the number of bytes of card memory allocated to the application); the version number of various software support modules on the card; and so on. Making this information available to an applet via its AID helps to ensure that the installed applet conforms to properties of the smart card in question concerned (for example, the applet does not try to use more memory than is allocated to it on the card).
- the above procedure therefore allows information about the card and the applet instance in the card environment to be encoded into the AID. This information can then be used to control the particular configuration of the applet as it is being installed. It will be appreciated that this provides a convenient software mechanism for optimizing the application configuration for the relevant environment, without having to depart from a relatively conventional or standardized loading procedure. In other words, rather than having to customize the installation process itself, any special configuration details can be encoded into the AID. The AID information can be used to control the precise configuration adopted without further external intervention, so that the applet instance is matched to the particular card on which the applet is installed, with different applet code or configurations being installed on different cards.
- Attached to the present description is a set of Appendices. These provide documentation relating to one implementation of certain components described herein. Various features are detailed that are not necessarily relevant to the invention itself (although they are typical of a complete implementation). Nevertheless, the Appendices provide the skilled person with a general indication at the code level as to how an implementation may be developed.
- Appendix A describes a card AID interpreter (corresponding for example to card AID interpreter 411 in FIG. 4 ).
- the Firewall ID 502 A (see FIG. 5 ) is stored in byte 6 of the AID
- the Applet ID 502 B is stored in byte 7 of the AID.
- An Owner ID is then formed as the composite of the RID 501 and the Firewall ID 502 A, while the Applet ID is (re)defined as the composite of the Owner ID and the Applet ID 502 B.
- Applet selection can then be performed using the Applet ID (only), since this incorporates the RID 501 , the Firewall ID 502 A and the Applet ID 502 B of FIG. 5 . Note that from a logical perspective however, the selection is still utilizing these three parameters, which can be regarded as encoded into the (redefined) Applet ID.
- the RID, Owner ID and the Applet ID correspond to the first five, six and seven bytes respectively of the AID. However, in other implementations they may be encoded differently into the AID (except of course for the RID, whose location is governed by the ISO standard).
- Appendices B, C, D and E describe four classes nested within the AID interpreter that respectively manage the various components of the AID, such as the RID portion, the Owner portion, and so on. This is somewhat analogous to the embodiment illustrated in FIG. 5C .
- Appendix F describes a proxy AID interpreter (corresponding for example to proxy AID interpreter 811 in FIG. 4 ). Note that there is a predefined list of attributes that might potentially be encoded into an AID (and hence need interpreting). Attributes that are not supported by a particular card are set to null. Additional attributes may be supported by suitably extending the class of Appendix F.
- a method for installing an application onto a smart card includes providing an application identifier (AID) for the application.
- the AID includes at least one customization parameter for the application to be installed.
- the method further includes instantiating the application onto the smart card and storing the AID for the application onto the card.
- the application is now configured in accordance with the stored AID, and more particularly, in accordance with said at least one customization parameter.
- the AID can therefore be used to supply configuration information to control the installation of the application onto a smart card.
- One advantage of this approach is that it helps to provide a consistent and self-defining installation process that is not reliant upon external parameters or settings (other than as recorded in the AID itself).
- the parameters may relate to one or more resources available to the application on the card, such as allocated memory or cryptographic facilities.
- a customization parameter is indicative of a level of service to be made available to a cardholder in transactions involving the application.
- the application is then configured to allow for the settings or values of such configuration parameters.
- the application includes an AID interpreter.
- the AID is passed to the AID interpreter, which then stores the AID for the application onto the card.
- the stored AID can be accessed with the AID interpreter, which extracts the customization parameter(s) from the stored AID.
- this involves instantiating the AID interpreter by calling a method on the application during instantiation of the application itself. This then allows the AID for the application to be stored onto the card as part of initialization of the application.
- the apparatus includes an application identifier (AID) for the application.
- the AID includes at least one customization parameter for the application to be installed.
- the apparatus further includes an install facility operable to instantiate the application onto the smart card and to store the AID for the application onto the card.
- the application is configured in accordance with the at least one customization parameter from the stored AID.
- Another embodiment of the invention provides a computer program product comprising instructions on a medium. When loaded into a machine, the instructions cause the machine to install an application onto a smart card.
- the AID includes at least one customization parameter for the application to be installed.
- the application is then instantiated onto the smart card, and the AID for the application is stored onto the card.
- the application is now configured in accordance with the stored AID, and more particularly in accordance with the customization parameter.
- a computer program product may comprise program instructions stored on a removable storage medium, for example an optical (CD ROM, DVD, etc) or magnetic (floppy disk, tape, etc) device. Such a medium can then be introduced into a computer system in order to transfer the program instructions to the system.
- the program instructions may be transferred to the computer system by download via a transmission signal medium over a network, for example, a local area network (LAN), the Internet, and so on.
- the transferred program instructions are stored on a hard disk of a computer system, and loaded for use into random access memory (RAM) for execution by a system processor.
- RAM random access memory
- a representation of the Application Identifier with support for a Java Card standardized encoding of additional data in the PIX field.
- This class and the complementary AID interpreter class provide a key functionality for generic support of card application management and application interoperability in the Java Card application framework.
- This class explicitly provides enhanced support for the selection of Java Card Applets by the terminal using a partial AID.
- this class provides support for the following distinct data elements associated with the Applet which are encoded in the ISO standardized AID byte[ ] representation (see below for the default encoding scheme):
- This AID data element refers to Applet instance data that is different in each applet instance and that may vary in each selection of the applet. This optional information will be encoded in the PIX field. The encoding space for this data in the PIX may be the same (as a part of) the configuration data (see previous item).
- each applet provides its own derived class with appropriate implementations of the abstract methods.
- the OwnerID is different from the RID as according to ISO rules an organization can only obtain a single RID.
- the card issuer may also be the provider of an applet on the card but may want to specify different owners for the loading Applet (function) and the other applet. And also, the issuer may want to distinguish ownership of library packages from both the loading applet and the other applet.
- the AppletID is different from the OwnerID, as the same owner may have more than one collaborating applet, where each applet is specified by the owner as selectable separately.
- the encoding and interpretation of the data elements actually contained in an AID may in general be specific to the application provider (registered entity).
- this AID class provides a default encoding for the first, non optional, data elements contained in the PIX as described below.
- the encoding of optional data elements in the PIX field is not defined, and must be specified in a sub class of this class when such optional data is required.
- This class provides the framework for such optional data to be used.
- the in-card interpretation of the optional instance data, and possible use of this data for install-time configuration is not specified here.
- an abstract class is provided as a basis for the representation in the card of such configuration information.
- Interpreting the AID information in a terminal may be accomplished by using the AID interpreter instance.
- a sub class of the AIDInterpreter class will be used to represent any of the optional data elements.
- the AID interpreter may be provided to the terminal via a provisioning mechanism that uses the unique value of the RID in any given AID. Interpreting the data encoded in the AID by that class might involve retrieving data from the world wide web.
- the AID class provides explicit support for selection of applets by partial AID with the implementation of the methods #matchId( ), #matchOwner( ) and #matchRID( ).
- the mechanism provided by these methods addresses the issue of partial matching which has been left underspecified in version 2.1 of the Java Card technology specifications.
- the AID class provides a default encoding of the AID in a sequence of maximally 16 bytes.
- the encoding follows the following rules (see the diagram):
- configuration data or applet state data In order to use either version data, configuration data or applet state data a sub class of this class must be defined that overrides the relevant methods, getVersion( ), getConfiguration( ) and readStateBytes( ), respectively.
- the specification of the AID class supports enhanced interoperability in application selection and card management with a set of reserved encoding constants and corresponding standard decoding methods. This allows card applications to identify specific common roles in the card by examining the AID of applications.
- the values 0x00 and 0xFF have been specified for this purpose.
- the default encoding implemented in this class uses these constants, implementations of alternative encoding schemes may use different values.
- the meaning of the special values can be asserted with:
- This applet is controlled by the card issuer. It may be the applet management Applet, or an other card management related applet.
- the default coding value is 0XFF.
- This applet is not actively controlled by its owner as may be specified by its AID. It may be an applet that contains personal data related to and entered by the cardholder.
- the default coding value is 0X00.
- This Applet is the card's applet management Applet or a delegated management Applet.
- the Application Management Applet must be owned by the card issuer.
- the default coding value is 0XFF.
- This applet provides information, e.g. pertaining to the cardholder. In addition to returning true in this method a cardholder data applet may indicate itself as not being controlled.
- the default coding value is 0X00.
- the AID class is implemented as wrapper around a data representation as a byte[ ]. Accessor methods and inner classes are specified to access and represent the types of the data elements that may be represented by an instance of the AID class.
- the implementation choice for the byte data representation is intended to improve the speed of retrieval of an AID. This retrieval may happen after the chip is reset when a list of all AIDs in the card may be assembled. Also, this data representation greatly simplifies the implementation of different encoding rules in possible subclasses.
- the implementation of the classes to represent the component data elements similarly is as wrappers around byte[ ].
- these classes share their data representation with their parent AID instance. With some increase in code complexity this design may be advantageous in speed and storage requirements.
- Security in the use of the AID is also enhanced, in that after the value of an AID instance has been committed to the non volatile card memory during Applet installation the information in it is never changed over the lifetime of an Applet.
- the implementation of AID and its component data type classes as a wrapper leverages the functionality provided by Buffer class that implements a generic wrapper around a byte[ ].
- the Buffer is actually used as the base class for all these classes and supports the access to a shared byte[ ].
- the shared byte[ ] holds the single constant data representation of the AID instance in the card memory.
- the classes for the AID component data elements also implement the Readable interface (via the base class ReadableBuffer) to facilitate retrieval as ISO files.
- the AID class is an extension of the class and provides source code compatibility with existing applet implementations. Functionally, however, this class supersedes its base class completely.
- the AID class implements the Serializable interface to support full card emulation with persistent in-card state.
- the implementation also provides methods to parse and produce a human readable form of the AID. These methods utilize in their implementation classes that are not part of the JCRE (StringTokenizer). With these features the implementation assumes the Java Card convertor to silently remove the interface and the non-convertible methods from the converted in-card class definition.
- This class com.sun.smartcard.AID, extends the javacard.framework.AID class only to provide backward compatibility with existing card platform implementations, functionally this class replaces the original base class completely.
- Nested Class Summary Static class AID.AppletId Represent the unique reference to an Applet that is contained in an AID .
- Static class AID.ConfigurationData Represent the Applet instance configuration data that may be contained in an AID .
- Static class AID.OwnerId Represent the owner of an Applet instance that is contained in an AID .
- Static class AID.RID Represent the RID (Registered ID) part of an AID.
- AID( ) Create an Empty AID.
- AID( AID.RID rid) Create an AID with a specific RID encoding.
- AID(byte[ ] encoding) Create an AID from a specific full length encoding.
- boolean matchRID (byte[ ] encoding, short offset) Compare the AID with a given encoding as used when the Applet instance that holds the AID is considered for “selection by AID”.
- static AID parse (java.lang.String data) Interpret a comma separated list of numbers in a string as an AID.
- short read (byte[ ] buffer, short offset, short dataskip, short length) Append a serialized representation of the AID to a given byte[ ].
- the size of an AID is fixed.
- the data representation of an AID is a byte[ ]. This representation storage is shared by all the data elements that are encoded in it.
- This constructor is for use in subclasses; subclasses constructed with this constructor need to use the set data( ) to initialize it properly.
- This definition allows the use of anonymous inner classes in the implementation of a specific Applet subclass to implement an AID. In this way the implementation of the readStateBytes( )method can be done with direct access to relevant state objects.
- This method uses classes that are not part of the JCRE and as a consequence will be skipped by the Java Card converter when building the in-card definition of the AID class. As a consequence none of the in-card methods can refer to this method.
- This method is intended for use in the constructor of a subclass of the AID to assure consistency of the data received with the representation specific to the sub class. To be used as intended this method should return the constant instance of a ⁇ link RID ⁇ class that is initialized with the RID prefix of AIDs that are decoded by the subclass.
- this data may be used to initialize the applet instance configuration.
- this object may include configuration data relevant to instance specific security initialization.
- Applets that want to transfer dynamic state information in the AID can do so by overriding this method with an implementation that calls the appropriate (public, package) methods in the Applet subclass.
- the method signature is compatible with File.Readable.read( ).
- This implementation is based on the default JavaCard AID encoding rules and its result is obtained by appending the results of the inherited read( ) for AppletId getVersion( ) and getConfiguration( ), respectively, to the specified byte[ ].
- this method may need to be overridden.
- the signature of this method is specified by the core version of the Readable interface method and its implementation utilizes the similar lesser OO interface for its AppletId and Configuration components.
- a more sophisticated design could utilize the Readable.WithStream.read(com.sun.smartcard.util.Stream.Writer) method which has a more OO signature.
- This implementation is incomplete as it does not provide error and parameter checking; it is provided as example, e.g. of the use of the Readable interface.
- the actual matching is performed by the Buffer.match(byte[ ] short) method.
- the input parameters include an offset to facilitate matching of the AID against the raw content of the APDU buffer.
- encoding a byte containing a possible encoding of an AID.
- the actual matching is performed by the Buffer.match(byte[ ], short) method.
- the input parameters include an offset to facilitate matching of the AID against the raw content of the APDU buffer.
- encoding a byte[ ] containing a possible encoding of an AID.
- the actual matching is performed by the Buffer.match(byte[ ], short) method.
- the input parameters include an offset to facilitate matching of the AID against the raw content of the APDU buffer.
- encoding a byte containing a possible encoding of an AID.
- This class is a wrapper around a serialized data representation, which may be shared with the parent AID.
- a generic wrapper class for byte[ ], ReadableBuffer is used as a base class.
- AID.RID( ) Construct an empty instance, for exclusive use by the AID class.
- AID.RID(byte[ ] encoding) Construct an instance with a given data representation.
- Method Summary protected getData( ) byte[ ] Share the data with the enclosing class. short getLength( ) Get the length of the data in the byte array for a RID (5).
- Methods Inherited from Class com.sun.smartcard.util.ReadableBuffer read Methods Inherited from Class com.sun.smartcard.util.Buffer getByteAt, getBytes, getDataSize, getFullyAt, getPrefixSkip, getSize, isValidIndex, match, match, match, setByteAt, setData Methods Inherited from Class com.sun.smartcard.util.Bytes equals, getBytes, getBytes, setBytes Methods Inherited from Class java.lang.Object clone, finalize, getClass, hashCode, notify, notifyAll, tosString, wait, wait, wait Constructor Detail AID.
- RID Get the length of the data in the byte array for a RID (5).
- the size of the RID is defined in ISO/IEC 7816-5
- AID.OwnerId( ) Construct an empty instance, for exclusive use by the AID class as wrapper on a shared data representation.
- AID.OwnerId(byte[ ] code) Construct an instance as wrapper on the specified data representation.
- Method Summary short getLength( ) Get the length of the data in the byte array for the Owner part of the AID. (package getRID( ) private) Get the RID part from the OwnerID. AID.RID boolean isIssuer( ) Test for Card Issuer reserved value encoding. boolean isNotControled( ) Test for “not owner controlled” reserved value encoding.
- AID.AppletId( ) Construct an empty instance, for exclusive use by the AID class.
- AID.AppletId(byte[ ] code) Construct an instance with a given data representation.
- Method Summary short getLength( ) Get the length of the data in the byte array for the AppletId component of the AID . (package getOwnerId( ) private) Get the Owner Identifier contained in the applet AID.OwnerId identifier.
- boolean isInformation( ) Test for “not owner controlled” reserved value encoding.
- boolean isManager( ) Test for Card Issuer reserved value encoding.
- the configuration data when present in an AID may be used when the Applet is instantiated to configure its components. For instance, the size of an array of object that represent a set of user data may be specified in the configuration. This class to be extended when a configuration is present on the encoding of an AID.
- This class is a wrapper around a serialized data representation, which may be shared with the parent AID.
- a generic wrapper class for byte[ ], ReadableBuffer is used as a base class;
- the current version of the implementation does not support configuration in the default encoding, however in a more mature version this might well be different.
- AID.ConfigurationData( ) Construct a default instance.
- AID.ConfigurationData(byte[ ] code) Construct an instance as a wrapper around a given data representation
- Method Summary short getLength( ) Specify the length of the data (byte[ ]) that represents the configuration data.
- short getPrefixSkip( ) Skip the initial portion of the AID encoding Methods Inherited from Class com.sun.smartcard.util.ReadableBuffer read Methods Inherited from Class com.sun.smartcard.util.Buffer getByteAt, getBytes, getDataSize, getFullyAt, getPrefixSkip, getSize, isValidIndex, match, match, match, setByteAt, setData Methods Inherited from Class com.sun.smartcard.util.Bytes equals, getBytes, getBytes, getData, setBytes Methods Inherited from Class java.lang.Object clone, finalize, getClass, hashCode, notify, notifyAll, tosString, wait, wait, wait Constructor Detail
- the value returned is in accordance with the default encoding and is equal to the length of the AppletID representation plus one byte for the function code.
- This class is intended for use in terminals, to provide detailed information about an applet in a card. Applet information is partially encoded in the AID data string read from the card; additional data regarding the Applet may be embedded in a sub class derived from this class or in part retrieved on the internet for instance using references embedded in the sub class implementation.
- the attributes defined for this class provide explicit support for internationalization of the terminal code.
- this class is a key component in providing generic application management support for the Java Card platform.
- the class provides support for the dynamic configuration of card terminals.
- the definition of sub classes of this class, their class files, may be stored at web-accessible repositories.
- a class naming scheme is implemented in this class that is based on the internationally registered identifier (RID) that is included in each AID encoding.
- RID internationally registered identifier
- a factory method is provided to instantiate a class based on a specific RID using this naming scheme.
- the class definition register may be maintained by an international organization like Java Card Forum.
- each attribute consist of an attribute name and attribute value both attribute parts being a Java String.
- Sub classes may define additional, e.g method call based, access to part of the data.
- This class actually supports a basic set of attributes; a sub-class may implement support for additional attributes. Attributes that are not supported have a value of null.
- a URL referring to a description of the organizational or business unit that is responsible for the Applet.
- a URL referring to an image characterizing the organizational or business unit that is responsible for the Applet.
- a URI referring to the back office (application management system) operated by the Applet owner to manage the use of the Applet in the card.
- a web page describing the function of the applet in a default language A web page describing the function of the applet in a default language.
- a URL specifying the name of the file containing the downloadable code for the applet.
- Each proxy may be offering a different set of functions.
- the class name of the Java interface that specifies the functional interface of the specific application proxy.
- the URL of ajar file that contains the proxy java class and supporting classes for a specific application proxy.
- This class in general wil be provided by the Application Provider; instantiating the class in a terminal may be subject to commercial agreements.
- a Java class name of the specific interface that may be used to communicate with the applet to obtain the shared functionality as defined by the Function code.
- a Java class name of an implementation of the generic interface that may be used to communicate with the applet to obtain the shared functionality as defined by the Function code.
- the instantiation of this class in the terminal should be possible without commercial restrictions.
- a URL referring to a description of the legal entity that has obtained the RID.
- java.util.Properties GetAsProperties( ) Interpret the content of an AID as a list of name value pairs.
- AIDInterpreter GetCardEncodingInterpreter(byte[ ] encoding) Clone the interpreter initialized with the encoding of a compatible AID as may be obtained from the card.
- java.lang.String[ ] GetConfigurationPropertyNames( ) Obtain the list of attribute names that describe the values that may be present in the configuration part of the AID. (package private) makeOne(AID.RID rid) static AIDInterpreter Create an instance of a derived class for the AID Interpreter, as defined by the specified RID.
- the AID being interpreted.
- interpreter classes are located in a Java package with the special name “javacard.aidinterpreters”.
- This method returns a properties object initialized with the properties available by interpreting the default AID encoding. Additional properties may be provided in a sub class, e.g by adding properties to the result of this function in the constructor.
Abstract
Description
- U.S. patent application Ser. No. 10/786,763, filed Feb. 24, 2004 in the name of inventor Eduard K. de Jong, entitled “Method and Apparatus for Providing an Application on Smart Card”, commonly assigned herewith;
- U.S. patent application Ser. No. 10/786,895, filed Feb. 24, 2004 in the name of inventor Eduard K. de Jong, entitled “Method and Apparatus for Selecting a Desired Application on a Smart Card”, commonly assigned herewith; and
- U.S. patent application Ser. No. 10/786,312, filed Feb. 24, 2004 in the name of inventor Eduard K. de Jong, entitled “Method and Apparatus for Precessing an Application Identifier from a Smart Card”, commonly assigned herewith.
- public class AID
- extends javacard.framework.AID
- implements Readable, java.io.Serializable
-
- 1. It specifies the application provider as a legal entity (via the RID), as defined by ISO/IEC 7816-5. By convention, in the Java Card implementations only nationally or internationally registered RIDs are formally supported.
- 2. It specifies the in-card instance of the Java Card “firewall” that contains the Applet and all the objects the Applet uses to store its data. Or, in more appropriate terminology, it specifies the “owner” of the Applet and Applet data objects instances in the card. The owner of an applet is commonly referred to as the Application Provider. To complicate matters, in principle, the legal entity identified by the RID in an AID may be present in the card as multiple different owners. For example the RID may identify an organization that is both the card issuer and provider of an application. In this example the card management operations performed by the card issuer applet should be separated by a firewall from the application operations implemented by the application Applet. The Ownership information is encoded in the PIX field as an extension of the RID.
- 3. It specifies a unique applet within a firewall, distinguishing it from any other applets that may be instantiated in the card with the same owner. This information is used for selection of applets. This information is encoded in the PIX field as an extension of the owner.
- 4. It specifies specific functions for applets of the same owner. For instance with distinct functions possibly indicated for a pre-paid (purse), debit (ATM) card or credit card applet. Similar function indications have been adopted by ISO 14443 for contact less cards as Application Function Identifiers (AFI). The interpretation of this code can be standardized by industry segment bodies. This information is contained in the PIX field.
- 5. It may specify additional information on the applet code, like code version numbers, for instance to complement the specified function. This information is optional. This optional information will be encoded in the PIX field.
- 6. It may specify additional information on the applet data instantiated in the card like key (batch) identifiers, or configuration data like the number and kind of supported data sets. This AID data element refers to Applet instance data that may vary per applet instance, but that does not, or rarely change over the life time of that instance. This data may be used by the applet at installation time to configure it self. When retrieving an AID from the card part of the code space for this data may be used to encode applet state data (see next item) This optional information will be encoded in the PIX field.
- An implementation of the Select Applet command may use these methods by examining all Applets in a card in a sequence of increasingly less specific matches. First the applets are tested for a matching applet identifier, using the matchId( ). If no Applet has been identified the applets are tested for a match on the owner ID using matchOwner( ). And finally, if that does not identify a single Applet, all Applets are tested for a match on the RID using match
RID ( ). This three stage matching algorithm provides full functional backward compatibility with Applets that are implemented with the javacard.framework.AID class (version 2.1).
Encoding
-
- 1. The RID is encoded as defined by the international standard ISO/IEC 7816-5 over the first five bytes of the AID encoding. The
AID implementation fully conforms to this international standard. - 2. The OwnerID is encoded as the first six bytes of the AID encoding, thus including the RID. The value encoded in the additional byte is not specified here and will be allocated by the entity identified by the RID. The purpose of this value is to distinguish between the different commercial and/or functional roles the registered entity may have in the card that require separation by a firewall.
- 3. The ApplicationID is encoded as the first 7 bytes of the AID encoding, thus including the OwnerID. The value encoded in the additional byte is not specified here and will be allocated by the entity identified by the RID. The purpose of this value is to distinguish between specific applets on the card that share the same owner and firewall, such as a Debit Card applet and a Credit Card applet provided by the same financial institution.
- 4. The Application Function ID is encoded on the 8th byte in the AID encoding. The value of this byte is encoded according to international standard ISO/IEC 14443 (contact-less cards).
- 5. The optional applet version, configuration and applet state data are encoded over the remaining 8 bytes of the AID. The applet AID matching algorithm that may be used in applet selection excludes these data elements. There is no default encoding for these optional data elements.
- An encoding for the configuration data is specified by the implementation of a sub class of the inner class AID.ConfigurationData The concrete configuration data class in the Applet may be used at applet-install time only or, in the implementation of a possible APDU handler to decode configuration data during the operational phase.
- Using Applet state data in an AID retrieved from the card is supported with a method call. This method has a default empty implementation. The method is intended to append a byte[ ] representation of the selected Applet state data to the AID encoding when it is being read by a terminal.
- 1. The RID is encoded as defined by the international standard ISO/IEC 7816-5 over the first five bytes of the AID encoding. The
1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 |
RID | PIX |
OwnerID |
AppletID | AF | Optional Data Elements |
AF = Application Function ID |
Java Card Specific Encoding
-
- 1. AID.RID,
- 2. AID.OwnerId
- 3. AID.AppletId
- 4. AID.ConfigurationData
Nested Class Summary |
Static class | AID.AppletId |
Represent the unique reference to an Applet that | |
is contained in an AID. | |
Static class | AID.ConfigurationData |
Represent the Applet instance configuration data that | |
may be contained in an AID. | |
Static class | AID.OwnerId |
Represent the owner of an Applet instance that | |
is contained in an AID. | |
Static class | AID.RID |
Represent the RID (Registered ID) part of an AID. | |
Nested Classes Inherited from Class com.sun.smartcard.util.Readable
Field Summary |
private | data | ||
byte[ ] | The data representation of an AID is a byte[ ]. | ||
private | SIZE | ||
static short | The size of an AID is fixed. | ||
Constructor Summary |
protected | AID( ) |
Create an Empty AID. | |
AID(AID.RID rid) | |
Create an AID with a specific RID encoding. | |
AID(byte[ ] encoding) | |
Create an AID from a specific full length encoding. | |
Method Summary |
(package private) | getAppletId( ) |
AID.AppletId | Get the AppletId part from an AID. |
Protected | getAssignedRID( ) |
AID.RID | Obtain the RID assigned to a card issuer or an application |
provider. | |
AID.Configuration | getConfiguration( ) |
Data | Obtain the configuration data part from the AID. |
byte | getFunctionCode( ) |
Obtain a descriptor of the function of the applet conforming to | |
ISO/IEC 14443 This method uses the default encoding, with the one | |
byte code immediately following the AID.AppletId. | |
(package private) | getOwnerId( ) |
AID.OwnerId | Get the OwnerId part from an AID. |
(package private) | getRID( ) |
AID.RID | Get the RID part from an AID. |
short | getVersion( ) |
Obtain a descriptor value indicative of the version of the applet | |
code. | |
boolean | matchId(byte[ ] encoding, short offset) |
Compare the AID with a given encoding as used when the Applet | |
instance that holds the AID is considered for “selection by AID”. | |
boolean | matchOwner(byte[ ] encoding, short offset) |
Compare the AID with a given encoding as used when the | |
Applet instance that holds the AID is considered for “selection by | |
AID”. | |
boolean | matchRID(byte[ ] encoding, short offset) |
Compare the AID with a given encoding as used when the | |
Applet instance that holds the AID is considered for “selection by | |
AID”. | |
static AID | parse(java.lang.String data) |
Interpret a comma separated list of numbers in a string as an | |
AID. | |
short | read(byte[ ] buffer, short offset, short dataskip, |
short length) | |
Append a serialized representation of the AID to a given byte[ ]. | |
protected short | readStateBytes(byte[ ] result, short off, short length) |
Append the byte[ ] representation of the current Applet State to | |
the AID's linear representation. | |
protected void | setdata(byte[ ] data) |
Set the data representation for this AID to the specified array of | |
bytes. | |
java.lang.String | toString( ) |
Represent the AID as a string of up to 16 hexadecimal integers. | |
Methods Inherited from Class javacard.framework.AID
Equals, equals, getBytes, partialEquals, RIDEquals
Methods Inherited from Class java.lang.Object
Clone, finalize, getClass, hashCode, notify, notifyAll, wait, wait, wait
Field Detail
SIZE
- private static final
- short SIZE
- private byte[ ]
- data
- protected
- AID( )
- public AID(AID.RID rid)
- public
- AID(byte[ ] encoding)
- public static AID
- parse(java.lang.String data)
- public
- java.lang.String toString( )
- protected
- final void setdata(byte[ ] data)
- final AID.RID
- getRID( )
-
- an instance of AID.RID that is wrapped around the shared data representation.
getAssignedRID
- an instance of AID.RID that is wrapped around the shared data representation.
- protected AID.RID
- getAssignedRID( )
-
- null, the base class does not check for its encoding as compatible with a specific RID.
getOwnerId
- null, the base class does not check for its encoding as compatible with a specific RID.
- final AID.OwnerId
- getOwnerId( )
-
- an instance of com.sun.smartcard.AID.OwnerID that is wrapped around the shared data representation.
getAppletId
- an instance of com.sun.smartcard.AID.OwnerID that is wrapped around the shared data representation.
- final AID.AppletId
- getAppletId( )
-
- an instance of AID.AppletId that is wrapped around the shared data representation.
getFunctionCode
- an instance of AID.AppletId that is wrapped around the shared data representation.
- public byte
- getFunctionCode( )
-
- a single byte containing the applet's function code.
getVersion
- a single byte containing the applet's function code.
- public short
- getVersion( )
-
- 0, the default encoding implemented in the base class does not support a version.
getConfiguration
- 0, the default encoding implemented in the base class does not support a version.
- public AID.ConfigurationData
- getConfiguration( )
- protected short
- readStateBytes(byte[ ] result,
- short off,
- short length)
- public short
- read(byte[ ] buffer,
- short offset,
- short dataskip,
- short length)
- public final boolean
- matchId(byte[ ] encoding,
- short offset)
- public final boolean
- matchOwner(byte[ ] encoding,
- short offset)
- public final boolean
- matchRID(byte[ ] encoding,
- short offset)
- public static class AID.RID
- extends ReadableBuffer
- Represent the RID (Registered ID) part of an AID.
Constructor Summary |
Private | AID.RID( ) |
Construct an empty instance, for exclusive use by the | |
AID class. | |
AID.RID(byte[ ] encoding) | |
Construct an instance with a given data representation. | |
Method Summary |
protected | getData( ) |
byte[ ] | Share the data with the enclosing class. |
short | getLength( ) |
Get the length of the data in the byte array for a RID (5). | |
Methods Inherited from Class com.sun.smartcard.util.ReadableBuffer
read
Methods Inherited from Class com.sun.smartcard.util.Buffer
getByteAt, getBytes, getDataSize, getFullyAt, getPrefixSkip, getSize, isValidIndex, match, match, match, setByteAt, setData
Methods Inherited from Class com.sun.smartcard.util.Bytes
equals, getBytes, getBytes, setBytes
Methods Inherited from Class java.lang.Object
clone, finalize, getClass, hashCode, notify, notifyAll, tosString, wait, wait, wait
Constructor Detail
AID.RID
- public AID.RID(byte[ ] encoding)
- getLength
- public final short getLength( )
-
- getLength in class Bytes
-
- 5
getData
- 5
- protected final byte[ ] getData( )
- public static class AID.OwnerId
- extends ReadableBuffer
- Represent the owner of an Applet instance that is contained in an AID. The owner of data in a Java Card Memory specifies the firewall that controls access to data.
- This class is a wrapper around a serialized data representation, which may be shared with the parent AID. A generic wrapper class for byte[ ], ReadableBuffer is used as a base class.
Nested Class Summary
Nested Classes Inherited from Class com.sun.smartcard.util.Readable
Readable.WithStream
Field Summary - Fields Inherited from Class com.sun.smartcard.util.Bytes
Constructor Summary |
private | AID.OwnerId( ) |
Construct an empty instance, for exclusive use by the AID | |
class as wrapper on a shared data representation. | |
AID.OwnerId(byte[ ] code) | |
Construct an instance as wrapper on the specified data | |
representation. | |
Method Summary |
short | getLength( ) |
Get the length of the data in the byte array for the Owner | |
part of the AID. | |
(package | getRID( ) |
private) | Get the RID part from the OwnerID. |
AID.RID | |
boolean | isIssuer( ) |
Test for Card Issuer reserved value encoding. | |
boolean | isNotControled( ) |
Test for “not owner controlled” reserved value encoding. | |
Methods Inherited from Class com.sun.smartcard.util.ReadableBuffer
Read
Methods Inherited from Class com.sun.smartcard.util.Buffer
getByteAt, getBytes, getDataSize, getFullyAt, getPrefixSkip, getSize, isValidIndex, match, match, match, setByteAt, setData
Methods Inherited from Class com.sun.smartcard.util.Bytes
equals, getBytes, getBytes, getData, setBytes
Methods Inherited from Class java.lang.Object
clone, finalize, getClass, hashCode, notify, notifyAll, tosString, wait, wait, wait
Constructor Detail
AID.OwnerId
- public AID.OwnerId(byte[ ] code)
- private AID.OwnerId( )
- public short getLength( )
- Returns:
- final AID.RID getRID( )
- public final boolean isIssuer( )
- public final boolean isNotControled( )
- public static class AID.AppletId
- extends ReadableBuffer
- This class is a wrapper around a serialized data representation, which may be shared with the parent AID. A generic wrapper class for byte[ ], ReadableBuffer is used as a base class.
Nested Class Summary
Nested Classes Inherited from Class com.sun.smartcard.util.Readable
Readable.WithStream
Field Summary
Fields Inherited from Class com.sun.smartcard.util.Bytes
Constructor Summary |
private | AID.AppletId( ) |
Construct an empty instance, for exclusive use by the AID | |
class. | |
AID.AppletId(byte[ ] code) | |
Construct an instance with a given data representation. | |
Method Summary |
short | getLength( ) |
Get the length of the data in the byte array for the | |
AppletId component of the AID. | |
(package | getOwnerId( ) |
private) | Get the Owner Identifier contained in the applet |
AID.OwnerId | identifier. |
boolean | isInformation( ) |
Test for “not owner controlled” reserved value | |
encoding. | |
boolean | isManager( ) |
Test for Card Issuer reserved value encoding. | |
Methods Inherited from Class com.sun.smartcard.util.ReadableBuffer
read
Methods Inherited from Class com.sun.smartcard.util.Buffer
getByteAt, getBytes, getDataSize, getFullyAt, getPrefixSkip, getSize, isValidIndex, match, match, match, setByteAt, setData
Methods Inherited from Class com.sun.smartcard.util.Bytes
equals, getBytes, getBytes, getData, setBytes
Methods Inherited from Class java.lang.Object
clone, finalize, getClass, hashCode, notify, notifyAll, tosString, wait, wait, wait
Constructor Detail
AID.AppletId
- public AID.AppletId(byte[ ] code)
- private AID.AppletId( )
- public short getLength( )
- Overrides:
- Returns:
- final AID.OwnerId getOwnerId( )
- public final boolean isManager( )
- public final boolean isInformation( )
- public abstract static class AID.ConfigurationData
- extends ReadableBuffer
Constructor Summary |
protected | AID.ConfigurationData( ) | ||
Construct a default instance. | |||
AID.ConfigurationData(byte[ ] code) | |||
Construct an instance as a wrapper around a | |||
given data representation | |||
Method Summary |
short | getLength( ) |
Specify the length of the data (byte[ ]) that represents the | |
configuration data. | |
short | getPrefixSkip( ) |
Skip the initial portion of the AID encoding | |
Methods Inherited from Class com.sun.smartcard.util.ReadableBuffer
read
Methods Inherited from Class com.sun.smartcard.util.Buffer
getByteAt, getBytes, getDataSize, getFullyAt, getPrefixSkip, getSize, isValidIndex, match, match, match, setByteAt, setData
Methods Inherited from Class com.sun.smartcard.util.Bytes
equals, getBytes, getBytes, getData, setBytes
Methods Inherited from Class java.lang.Object
clone, finalize, getClass, hashCode, notify, notifyAll, tosString, wait, wait, wait
Constructor Detail
AID.ConfigurationData
- public AID.ConfigurationData (byte[ ] code)
- protected AID.ConfigurationData( )
- public short getLength( )
- public short getPrefixSkip( )
- getPrefixSkip in class Buffer
Returns:
- public class AIDInterpreter
- extends java.lang.Object
- implements java.lang.Cloneable
-
- 1. Owner properties
- 2. Applet Properties
- 3. Terminal properties
Card Application Attributes
- Owner
- Owner.code
- Owner.URL
- Owner.Logo
- Owner.BackOfficeURI
- Applet.Function.DescriptionURL
- Applet.Function
- Applet.Function.+lang+
- Applet.CAPFile.URL
- Applet.Title
- Applet.Title.+lang+
- Applet.Proxy.Count
- Applet.Proxy.Title.+count+
- Applet.Proxy.Title.+count+.+lang+
- Applet.Proxy.CardApplicationServiceAPI.+count+
- Applet.Proxy.Class.+count+
- Applet.Proxy.Jar.+count+
- Applet.Function.Code
- Applet.Function.ProxyClass
- Applet.Function.ProxyClass.GenericInterface
- Applet.Function.ProxyClass.GenericInterface.Implementation
- Applet.Version
- RID
- RID.code
- RID.URL
- PIX
Field Summary |
private AID | aid |
The AID being interpreted. | |
Static java.lang. | AID_CLASS_NAME_PREFIX |
String | |
Static java.lang. | AID_INTERPRETER_PACKAGE_PATH |
String[ ] | The name of a JavaCard special package for |
Issuer specific versions of this class. | |
Constructor Summary |
AIDInterpreter( ) | ||
Method Summary |
protected static AID | getAID(AID.RID rid) |
Get an instance of an AID sub class as appropriate for the | |
applet. | |
protected | getAIDPackageList( ) |
static java.lang.String[ ] | Get a list of all the package names that may contain the |
definition of an appropriate AIDInterpreter class definition. | |
java.lang.String[ ] | getAppletStateDataPropertyNames( ) |
Obtain the attribute names for applet data that may be | |
included in the AID. | |
java.lang.String | GetAppletString(short stringreference) |
Obtain a string that has been removed from the applet | |
code by the conversion to Java Card ByteCode. | |
java.util.Properties | GetAsProperties( ) |
Interpret the content of an AID as a list of name value | |
pairs. | |
AIDInterpreter | GetCardEncodingInterpreter(byte[ ] encoding) |
Clone the interpreter initialized with the encoding of a | |
compatible AID as may be obtained from the card. | |
java.lang.String[ ] | GetConfigurationPropertyNames( ) |
Obtain the list of attribute names that describe the values | |
that may be present in the configuration part of the AID. | |
(package private) | makeOne(AID.RID rid) |
static AIDInterpreter | Create an instance of a derived class for the AID |
Interpreter, as defined by the specified RID. | |
static AIDInterpreter | makeOne (byte[ ] encoding) |
Create an instance of the AID that fits a specified AID | |
encoding. | |
Methods Inherited from Class java.lang.Object
Clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait
Field Detail
AID_INTERPRETER_PACKAGE_PATH
- public static final java.lang.String[ ] AID_INTERPRETER_PACKAGE_PATH
- public static final java.lang.String AID_CLASS_NAME_PREFIX
aid - private
AID aid
- public AIDInterpreter( )
Method Detail
makeOne - static final AIDInterpreter makeOne(AID.RID rid)
- protected static java.lang.String[ ] getAIDPackageList( )
- public static final AIDInterprete makeOne(byte[ ] encoding)
-
- Note:
- This method is never called inside the card. The in-card implementation of this class may dispense with it.
getAID
- protected static
AID getAID (AID.RID rid)
- public AIDInterpreter getCardEncodingInterpreter(byte[ ] encoding)
-
- null if the specified encoding does not match the application ID.
getAsProperties
- null if the specified encoding does not match the application ID.
- public java.util.Properties getAsProperties( )
- public java.lang.String[ ] getConfigurationPropertyNames( )
- public java.lang.String[ ] getAppletStateDataPropertyNames( )
- public java.lang.String getAppletString(short stringreference)
Claims (31)
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/786,506 US7165727B2 (en) | 2004-02-24 | 2004-02-24 | Method and apparatus for installing an application onto a smart card |
EP20050250948 EP1575005B1 (en) | 2004-02-24 | 2005-02-18 | Method and apparatus for processing an application identifier from a smart card |
DE200560018982 DE602005018982D1 (en) | 2004-02-24 | 2005-02-18 | Method and apparatus for processing an application identifier from a smart card |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/786,506 US7165727B2 (en) | 2004-02-24 | 2004-02-24 | Method and apparatus for installing an application onto a smart card |
Publications (2)
Publication Number | Publication Date |
---|---|
US20050184164A1 US20050184164A1 (en) | 2005-08-25 |
US7165727B2 true US7165727B2 (en) | 2007-01-23 |
Family
ID=34861781
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/786,506 Active 2024-06-19 US7165727B2 (en) | 2004-02-24 | 2004-02-24 | Method and apparatus for installing an application onto a smart card |
Country Status (1)
Country | Link |
---|---|
US (1) | US7165727B2 (en) |
Cited By (182)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040215596A1 (en) * | 2000-09-29 | 2004-10-28 | Fukuhara Keith T | System, method and apparatus for data processing and storage to provide continuous operations independent of device failure or disaster |
US20060084410A1 (en) * | 2004-10-20 | 2006-04-20 | Jay Sutaria | Flexible billing architecture |
US20070027920A1 (en) * | 2005-08-01 | 2007-02-01 | Billy Alvarado | Context aware data presentation |
US20070136797A1 (en) * | 2005-01-11 | 2007-06-14 | Matsushita Electric Industrial Co., Ltd. | Secure device and system for issuing ic cards |
US20070290787A1 (en) * | 2006-06-20 | 2007-12-20 | Trevor Fiatal | Systems and methods for group messaging |
US20080134292A1 (en) * | 2003-01-08 | 2008-06-05 | Ido Ariel | Extending user relationships |
US20090054034A1 (en) * | 2004-11-22 | 2009-02-26 | Ari Backholm | Maintaining Mobile Terminal Information for Secure E-Mail Communications |
US20090063647A1 (en) * | 2004-11-22 | 2009-03-05 | Seven Networks International Oy | Messaging centre for forwarding e-mail |
US20090149203A1 (en) * | 2007-12-10 | 2009-06-11 | Ari Backholm | Electronic-mail filtering for mobile devices |
US20090164560A1 (en) * | 2008-01-25 | 2009-06-25 | Trevor Fiatal | Policy based content service |
US20090181641A1 (en) * | 2008-01-11 | 2009-07-16 | Trevor Fiatal | Mobile virtual network operator |
US20090193130A1 (en) * | 2008-01-28 | 2009-07-30 | Trevor Fiatal | Web-Based Access to Data Objects |
US20090248670A1 (en) * | 2008-03-31 | 2009-10-01 | Trevor Fiatal | Content search engine |
US20090318171A1 (en) * | 2008-06-18 | 2009-12-24 | Ari Backholm | Application Discovery on Mobile Devices |
US20090325565A1 (en) * | 2008-06-26 | 2009-12-31 | Ari Backholm | Provisioning applications for a mobile device |
US20100146107A1 (en) * | 2008-10-10 | 2010-06-10 | Trevor Fiatal | Bandwidth Measurement |
US20110099363A1 (en) * | 2002-01-08 | 2011-04-28 | Boynton Lee R | Secure end-to-end transport through intermediary nodes |
US20110167242A1 (en) * | 2007-11-27 | 2011-07-07 | Oracle America, Inc. | Multiple instruction execution mode resource-constrained device |
US20110190014A1 (en) * | 2007-06-01 | 2011-08-04 | Trevor Fiatal | Integrated messaging |
US8064583B1 (en) | 2005-04-21 | 2011-11-22 | Seven Networks, Inc. | Multiple data store authentication |
US8069166B2 (en) | 2005-08-01 | 2011-11-29 | Seven Networks, Inc. | Managing user-to-user contact with inferred presence information |
US8116214B2 (en) | 2004-12-03 | 2012-02-14 | Seven Networks, Inc. | Provisioning of e-mail settings for a mobile terminal |
US8166164B1 (en) | 2010-11-01 | 2012-04-24 | Seven Networks, Inc. | Application and network-based long poll request detection and cacheability assessment therefor |
US8190701B2 (en) | 2010-11-01 | 2012-05-29 | Seven Networks, Inc. | Cache defeat detection and caching of content addressed by identifiers intended to defeat cache |
US8196131B1 (en) * | 2010-12-17 | 2012-06-05 | Google Inc. | Payment application lifecycle management in a contactless smart card |
US20120159148A1 (en) * | 2010-12-17 | 2012-06-21 | Google Inc. | Local trusted services manager for a contactless smart card |
US8209709B2 (en) | 2005-03-14 | 2012-06-26 | Seven Networks, Inc. | Cross-platform event engine |
US8297520B1 (en) | 2011-09-16 | 2012-10-30 | Google Inc. | Secure application directory |
US8316098B2 (en) | 2011-04-19 | 2012-11-20 | Seven Networks Inc. | Social caching for device resource sharing and management |
US8326985B2 (en) | 2010-11-01 | 2012-12-04 | Seven Networks, Inc. | Distributed management of keep-alive message signaling for mobile network resource conservation and optimization |
US8335921B2 (en) | 2010-12-17 | 2012-12-18 | Google, Inc. | Writing application data to a secure element |
US8379863B1 (en) | 2011-09-15 | 2013-02-19 | Google Inc. | Enabling users to select between secure service providers using a central trusted service manager |
US8385553B1 (en) | 2012-02-28 | 2013-02-26 | Google Inc. | Portable secure element |
US8412933B1 (en) | 2011-09-15 | 2013-04-02 | Google Inc. | Enabling users to select between secure service providers using a key escrow service |
US8417823B2 (en) | 2010-11-22 | 2013-04-09 | Seven Network, Inc. | Aligning data transfer to optimize connections established for transmission over a wireless network |
US8429409B1 (en) | 2012-04-06 | 2013-04-23 | Google Inc. | Secure reset of personal and service provider information on mobile devices |
US8438633B1 (en) | 2005-04-21 | 2013-05-07 | Seven Networks, Inc. | Flexible real-time inbox access |
US8468126B2 (en) | 2005-08-01 | 2013-06-18 | Seven Networks, Inc. | Publishing data in an information community |
US8484314B2 (en) | 2010-11-01 | 2013-07-09 | Seven Networks, Inc. | Distributed caching in a wireless network of content delivered for a mobile application over a long-held request |
US8607321B2 (en) | 2008-06-27 | 2013-12-10 | Microsoft Corporation | Identification of a smart card on a plug and play system |
US8621075B2 (en) | 2011-04-27 | 2013-12-31 | Seven Metworks, Inc. | Detecting and preserving state for satisfying application requests in a distributed proxy and cache system |
US8693494B2 (en) | 2007-06-01 | 2014-04-08 | Seven Networks, Inc. | Polling |
US8700728B2 (en) | 2010-11-01 | 2014-04-15 | Seven Networks, Inc. | Cache defeat detection and caching of content addressed by identifiers intended to defeat cache |
US8750123B1 (en) | 2013-03-11 | 2014-06-10 | Seven Networks, Inc. | Mobile device equipped with mobile network congestion recognition to make intelligent decisions regarding connecting to an operator network |
US8761756B2 (en) | 2005-06-21 | 2014-06-24 | Seven Networks International Oy | Maintaining an IP connection in a mobile network |
US8775631B2 (en) | 2012-07-13 | 2014-07-08 | Seven Networks, Inc. | Dynamic bandwidth adjustment for browsing or streaming activity in a wireless network based on prediction of user behavior when interacting with mobile applications |
US8793305B2 (en) | 2007-12-13 | 2014-07-29 | Seven Networks, Inc. | Content delivery to a mobile device from a content service |
US8812695B2 (en) | 2012-04-09 | 2014-08-19 | Seven Networks, Inc. | Method and system for management of a virtual network connection without heartbeat messages |
US8832228B2 (en) | 2011-04-27 | 2014-09-09 | Seven Networks, Inc. | System and method for making requests on behalf of a mobile device based on atomic processes for mobile network traffic relief |
US8838783B2 (en) | 2010-07-26 | 2014-09-16 | Seven Networks, Inc. | Distributed caching for resource and mobile network traffic management |
US8843153B2 (en) | 2010-11-01 | 2014-09-23 | Seven Networks, Inc. | Mobile traffic categorization and policy for network use optimization while preserving user experience |
US8861354B2 (en) | 2011-12-14 | 2014-10-14 | Seven Networks, Inc. | Hierarchies and categories for management and deployment of policies for distributed wireless traffic optimization |
US8868753B2 (en) | 2011-12-06 | 2014-10-21 | Seven Networks, Inc. | System of redundantly clustered machines to provide failover mechanisms for mobile traffic management and network resource conservation |
US8874761B2 (en) | 2013-01-25 | 2014-10-28 | Seven Networks, Inc. | Signaling optimization in a wireless network for traffic utilizing proprietary and non-proprietary protocols |
US8886176B2 (en) | 2010-07-26 | 2014-11-11 | Seven Networks, Inc. | Mobile application traffic optimization |
US8903954B2 (en) | 2010-11-22 | 2014-12-02 | Seven Networks, Inc. | Optimization of resource polling intervals to satisfy mobile device requests |
US8909202B2 (en) | 2012-01-05 | 2014-12-09 | Seven Networks, Inc. | Detection and management of user interactions with foreground applications on a mobile device in distributed caching |
US8918503B2 (en) | 2011-12-06 | 2014-12-23 | Seven Networks, Inc. | Optimization of mobile traffic directed to private networks and operator configurability thereof |
USRE45348E1 (en) | 2004-10-20 | 2015-01-20 | Seven Networks, Inc. | Method and apparatus for intercepting events in a communication system |
US8984581B2 (en) | 2011-07-27 | 2015-03-17 | Seven Networks, Inc. | Monitoring mobile application activities for malicious traffic on a mobile device |
US9002828B2 (en) | 2007-12-13 | 2015-04-07 | Seven Networks, Inc. | Predictive content delivery |
US9009250B2 (en) | 2011-12-07 | 2015-04-14 | Seven Networks, Inc. | Flexible and dynamic integration schemas of a traffic management system with various network operators for network traffic alleviation |
US9021021B2 (en) | 2011-12-14 | 2015-04-28 | Seven Networks, Inc. | Mobile network reporting and usage analytics system and method aggregated using a distributed traffic optimization system |
US9043731B2 (en) | 2010-03-30 | 2015-05-26 | Seven Networks, Inc. | 3D mobile user interface with configurable workspace management |
US9043433B2 (en) | 2010-07-26 | 2015-05-26 | Seven Networks, Inc. | Mobile network traffic coordination across multiple applications |
US9055102B2 (en) | 2006-02-27 | 2015-06-09 | Seven Networks, Inc. | Location-based operations and messaging |
US9060032B2 (en) | 2010-11-01 | 2015-06-16 | Seven Networks, Inc. | Selective data compression by a distributed traffic management system to reduce mobile data traffic and signaling traffic |
US9065765B2 (en) | 2013-07-22 | 2015-06-23 | Seven Networks, Inc. | Proxy server associated with a mobile carrier for enhancing mobile traffic management in a mobile network |
US9077630B2 (en) | 2010-07-26 | 2015-07-07 | Seven Networks, Inc. | Distributed implementation of dynamic wireless traffic policy |
US9161258B2 (en) | 2012-10-24 | 2015-10-13 | Seven Networks, Llc | Optimized and selective management of policy deployment to mobile clients in a congested network to prevent further aggravation of network congestion |
US9173128B2 (en) | 2011-12-07 | 2015-10-27 | Seven Networks, Llc | Radio-awareness of mobile device for sending server-side control signals using a wireless network optimized transport protocol |
US9203864B2 (en) | 2012-02-02 | 2015-12-01 | Seven Networks, Llc | Dynamic categorization of applications for network access in a mobile network |
US9241314B2 (en) | 2013-01-23 | 2016-01-19 | Seven Networks, Llc | Mobile device with application or context aware fast dormancy |
US9275163B2 (en) | 2010-11-01 | 2016-03-01 | Seven Networks, Llc | Request and response characteristics based adaptation of distributed caching in a mobile network |
US9307493B2 (en) | 2012-12-20 | 2016-04-05 | Seven Networks, Llc | Systems and methods for application management of mobile device radio state promotion and demotion |
US9326189B2 (en) | 2012-02-03 | 2016-04-26 | Seven Networks, Llc | User as an end point for profiling and optimizing the delivery of content and data in a wireless network |
US9325662B2 (en) | 2011-01-07 | 2016-04-26 | Seven Networks, Llc | System and method for reduction of mobile network traffic used for domain name system (DNS) queries |
US9330196B2 (en) | 2010-11-01 | 2016-05-03 | Seven Networks, Llc | Wireless traffic management system cache optimization using http headers |
US9832095B2 (en) | 2011-12-14 | 2017-11-28 | Seven Networks, Llc | Operation modes for mobile traffic optimization and concurrent management of optimized and non-optimized traffic |
US10263899B2 (en) | 2012-04-10 | 2019-04-16 | Seven Networks, Llc | Enhanced customer service for mobile carriers using real-time and historical mobile application and traffic or optimization data associated with mobile devices in a mobile network |
US10425129B1 (en) | 2019-02-27 | 2019-09-24 | Capital One Services, Llc | Techniques to reduce power consumption in near field communication systems |
US10438437B1 (en) | 2019-03-20 | 2019-10-08 | Capital One Services, Llc | Tap to copy data to clipboard via NFC |
US10467445B1 (en) | 2019-03-28 | 2019-11-05 | Capital One Services, Llc | Devices and methods for contactless card alignment with a foldable mobile device |
US10467622B1 (en) | 2019-02-01 | 2019-11-05 | Capital One Services, Llc | Using on-demand applications to generate virtual numbers for a contactless card to securely autofill forms |
US10489781B1 (en) | 2018-10-02 | 2019-11-26 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10498401B1 (en) | 2019-07-15 | 2019-12-03 | Capital One Services, Llc | System and method for guiding card positioning using phone sensors |
US10505738B1 (en) | 2018-10-02 | 2019-12-10 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10506426B1 (en) | 2019-07-19 | 2019-12-10 | Capital One Services, Llc | Techniques for call authentication |
US10510074B1 (en) | 2019-02-01 | 2019-12-17 | Capital One Services, Llc | One-tap payment using a contactless card |
US10511443B1 (en) | 2018-10-02 | 2019-12-17 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10516447B1 (en) | 2019-06-17 | 2019-12-24 | Capital One Services, Llc | Dynamic power levels in NFC card communications |
US10523708B1 (en) | 2019-03-18 | 2019-12-31 | Capital One Services, Llc | System and method for second factor authentication of customer support calls |
US10535062B1 (en) | 2019-03-20 | 2020-01-14 | Capital One Services, Llc | Using a contactless card to securely share personal data stored in a blockchain |
US10542036B1 (en) | 2018-10-02 | 2020-01-21 | Capital One Services, Llc | Systems and methods for signaling an attack on contactless cards |
US10541995B1 (en) | 2019-07-23 | 2020-01-21 | Capital One Services, Llc | First factor contactless card authentication system and method |
US10546444B2 (en) | 2018-06-21 | 2020-01-28 | Capital One Services, Llc | Systems and methods for secure read-only authentication |
US10554411B1 (en) | 2018-10-02 | 2020-02-04 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10565587B1 (en) | 2018-10-02 | 2020-02-18 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10581611B1 (en) | 2018-10-02 | 2020-03-03 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10579998B1 (en) | 2018-10-02 | 2020-03-03 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10582386B1 (en) | 2018-10-02 | 2020-03-03 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10592710B1 (en) | 2018-10-02 | 2020-03-17 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10607214B1 (en) | 2018-10-02 | 2020-03-31 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10607216B1 (en) | 2018-10-02 | 2020-03-31 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10615981B1 (en) | 2018-10-02 | 2020-04-07 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10623393B1 (en) | 2018-10-02 | 2020-04-14 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10630653B1 (en) | 2018-10-02 | 2020-04-21 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10643420B1 (en) | 2019-03-20 | 2020-05-05 | Capital One Services, Llc | Contextual tapping engine |
US10657754B1 (en) | 2019-12-23 | 2020-05-19 | Capital One Services, Llc | Contactless card and personal identification system |
US10664941B1 (en) | 2019-12-24 | 2020-05-26 | Capital One Services, Llc | Steganographic image encoding of biometric template information on a card |
US10680824B2 (en) | 2018-10-02 | 2020-06-09 | Capital One Services, Llc | Systems and methods for inventory management using cryptographic authentication of contactless cards |
US10686603B2 (en) | 2018-10-02 | 2020-06-16 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10685350B2 (en) | 2018-10-02 | 2020-06-16 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10701560B1 (en) | 2019-10-02 | 2020-06-30 | Capital One Services, Llc | Client device authentication using contactless legacy magnetic stripe data |
US10713649B1 (en) | 2019-07-09 | 2020-07-14 | Capital One Services, Llc | System and method enabling mobile near-field communication to update display on a payment card |
US10733283B1 (en) | 2019-12-23 | 2020-08-04 | Capital One Services, Llc | Secure password generation and management using NFC and contactless smart cards |
US10733601B1 (en) | 2019-07-17 | 2020-08-04 | Capital One Services, Llc | Body area network facilitated authentication or payment authorization |
US10733645B2 (en) | 2018-10-02 | 2020-08-04 | Capital One Services, Llc | Systems and methods for establishing identity for order pick up |
US10748138B2 (en) | 2018-10-02 | 2020-08-18 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10757574B1 (en) | 2019-12-26 | 2020-08-25 | Capital One Services, Llc | Multi-factor authentication providing a credential via a contactless card for secure messaging |
US10771253B2 (en) | 2018-10-02 | 2020-09-08 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10769299B2 (en) | 2018-07-12 | 2020-09-08 | Capital One Services, Llc | System and method for dynamic generation of URL by smart card |
US10771254B2 (en) | 2018-10-02 | 2020-09-08 | Capital One Services, Llc | Systems and methods for email-based card activation |
US10783519B2 (en) | 2018-10-02 | 2020-09-22 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10797882B2 (en) | 2018-10-02 | 2020-10-06 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10832271B1 (en) | 2019-07-17 | 2020-11-10 | Capital One Services, Llc | Verified reviews using a contactless card |
US10841091B2 (en) | 2018-10-02 | 2020-11-17 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10853795B1 (en) | 2019-12-24 | 2020-12-01 | Capital One Services, Llc | Secure authentication based on identity data stored in a contactless card |
US10861006B1 (en) | 2020-04-30 | 2020-12-08 | Capital One Services, Llc | Systems and methods for data access control using a short-range transceiver |
US10860914B1 (en) | 2019-12-31 | 2020-12-08 | Capital One Services, Llc | Contactless card and method of assembly |
US10862540B1 (en) | 2019-12-23 | 2020-12-08 | Capital One Services, Llc | Method for mapping NFC field strength and location on mobile devices |
US10860814B2 (en) | 2018-10-02 | 2020-12-08 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10871958B1 (en) | 2019-07-03 | 2020-12-22 | Capital One Services, Llc | Techniques to perform applet programming |
US10885514B1 (en) | 2019-07-15 | 2021-01-05 | Capital One Services, Llc | System and method for using image data to trigger contactless card transactions |
US10885410B1 (en) | 2019-12-23 | 2021-01-05 | Capital One Services, Llc | Generating barcodes utilizing cryptographic techniques |
US10909527B2 (en) | 2018-10-02 | 2021-02-02 | Capital One Services, Llc | Systems and methods for performing a reissue of a contactless card |
US10909544B1 (en) | 2019-12-26 | 2021-02-02 | Capital One Services, Llc | Accessing and utilizing multiple loyalty point accounts |
US10915888B1 (en) | 2020-04-30 | 2021-02-09 | Capital One Services, Llc | Contactless card with multiple rotating security keys |
US10949520B2 (en) | 2018-10-02 | 2021-03-16 | Capital One Services, Llc | Systems and methods for cross coupling risk analytics and one-time-passcodes |
US10963865B1 (en) | 2020-05-12 | 2021-03-30 | Capital One Services, Llc | Augmented reality card activation experience |
US10970712B2 (en) | 2019-03-21 | 2021-04-06 | Capital One Services, Llc | Delegated administration of permissions using a contactless card |
US10984416B2 (en) | 2019-03-20 | 2021-04-20 | Capital One Services, Llc | NFC mobile currency transfer |
US10992477B2 (en) | 2018-10-02 | 2021-04-27 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US11030339B1 (en) | 2020-04-30 | 2021-06-08 | Capital One Services, Llc | Systems and methods for data access control of personal user data using a short-range transceiver |
US11038688B1 (en) | 2019-12-30 | 2021-06-15 | Capital One Services, Llc | Techniques to control applets for contactless cards |
US11037136B2 (en) | 2019-01-24 | 2021-06-15 | Capital One Services, Llc | Tap to autofill card data |
US11062098B1 (en) | 2020-08-11 | 2021-07-13 | Capital One Services, Llc | Augmented reality information display and interaction via NFC based authentication |
US11063979B1 (en) | 2020-05-18 | 2021-07-13 | Capital One Services, Llc | Enabling communications between applications in a mobile operating system |
US11100511B1 (en) | 2020-05-18 | 2021-08-24 | Capital One Services, Llc | Application-based point of sale system in mobile operating systems |
US11113685B2 (en) | 2019-12-23 | 2021-09-07 | Capital One Services, Llc | Card issuing with restricted virtual numbers |
US11120453B2 (en) | 2019-02-01 | 2021-09-14 | Capital One Services, Llc | Tap card to securely generate card data to copy to clipboard |
US11165586B1 (en) | 2020-10-30 | 2021-11-02 | Capital One Services, Llc | Call center web-based authentication using a contactless card |
US11182771B2 (en) | 2019-07-17 | 2021-11-23 | Capital One Services, Llc | System for value loading onto in-vehicle device |
US11200563B2 (en) | 2019-12-24 | 2021-12-14 | Capital One Services, Llc | Account registration using a contactless card |
US11210664B2 (en) | 2018-10-02 | 2021-12-28 | Capital One Services, Llc | Systems and methods for amplifying the strength of cryptographic algorithms |
US11210656B2 (en) | 2020-04-13 | 2021-12-28 | Capital One Services, Llc | Determining specific terms for contactless card activation |
US11216799B1 (en) | 2021-01-04 | 2022-01-04 | Capital One Services, Llc | Secure generation of one-time passcodes using a contactless card |
US11216623B1 (en) | 2020-08-05 | 2022-01-04 | Capital One Services, Llc | Systems and methods for controlling secured data transfer via URLs |
US11222342B2 (en) | 2020-04-30 | 2022-01-11 | Capital One Services, Llc | Accurate images in graphical user interfaces to enable data transfer |
US11245438B1 (en) | 2021-03-26 | 2022-02-08 | Capital One Services, Llc | Network-enabled smart apparatus and systems and methods for activating and provisioning same |
US11354555B1 (en) | 2021-05-04 | 2022-06-07 | Capital One Services, Llc | Methods, mediums, and systems for applying a display to a transaction card |
US11361302B2 (en) | 2019-01-11 | 2022-06-14 | Capital One Services, Llc | Systems and methods for touch screen interface interaction using a card overlay |
US11373169B2 (en) | 2020-11-03 | 2022-06-28 | Capital One Services, Llc | Web-based activation of contactless cards |
US11392933B2 (en) | 2019-07-03 | 2022-07-19 | Capital One Services, Llc | Systems and methods for providing online and hybridcard interactions |
US11438329B2 (en) | 2021-01-29 | 2022-09-06 | Capital One Services, Llc | Systems and methods for authenticated peer-to-peer data transfer using resource locators |
US11455620B2 (en) | 2019-12-31 | 2022-09-27 | Capital One Services, Llc | Tapping a contactless card to a computing device to provision a virtual number |
US11482312B2 (en) | 2020-10-30 | 2022-10-25 | Capital One Services, Llc | Secure verification of medical status using a contactless card |
US11521213B2 (en) | 2019-07-18 | 2022-12-06 | Capital One Services, Llc | Continuous authentication for digital services based on contactless card positioning |
US11521262B2 (en) | 2019-05-28 | 2022-12-06 | Capital One Services, Llc | NFC enhanced augmented reality information overlays |
US11562358B2 (en) | 2021-01-28 | 2023-01-24 | Capital One Services, Llc | Systems and methods for near field contactless card communication and cryptographic authentication |
US11615395B2 (en) | 2019-12-23 | 2023-03-28 | Capital One Services, Llc | Authentication for third party digital wallet provisioning |
US11637826B2 (en) | 2021-02-24 | 2023-04-25 | Capital One Services, Llc | Establishing authentication persistence |
US11651361B2 (en) | 2019-12-23 | 2023-05-16 | Capital One Services, Llc | Secure authentication based on passport data stored in a contactless card |
US11682012B2 (en) | 2021-01-27 | 2023-06-20 | Capital One Services, Llc | Contactless delivery systems and methods |
US11683325B2 (en) | 2020-08-11 | 2023-06-20 | Capital One Services, Llc | Systems and methods for verified messaging via short-range transceiver |
US11687930B2 (en) | 2021-01-28 | 2023-06-27 | Capital One Services, Llc | Systems and methods for authentication of access tokens |
US11694187B2 (en) | 2019-07-03 | 2023-07-04 | Capital One Services, Llc | Constraining transactional capabilities for contactless cards |
US11777933B2 (en) | 2021-02-03 | 2023-10-03 | Capital One Services, Llc | URL-based authentication for payment cards |
US11792001B2 (en) | 2021-01-28 | 2023-10-17 | Capital One Services, Llc | Systems and methods for secure reprovisioning |
US11823175B2 (en) | 2020-04-30 | 2023-11-21 | Capital One Services, Llc | Intelligent card unlock |
US11902442B2 (en) | 2021-04-22 | 2024-02-13 | Capital One Services, Llc | Secure management of accounts on display devices using a contactless card |
US11924188B2 (en) | 2022-02-23 | 2024-03-05 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
Families Citing this family (53)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7165727B2 (en) | 2004-02-24 | 2007-01-23 | Sun Microsystems, Inc. | Method and apparatus for installing an application onto a smart card |
US7191288B2 (en) * | 2004-02-24 | 2007-03-13 | Sun Microsystems, Inc. | Method and apparatus for providing an application on a smart card |
US7374099B2 (en) * | 2004-02-24 | 2008-05-20 | Sun Microsystems, Inc. | Method and apparatus for processing an application identifier from a smart card |
US7140549B2 (en) * | 2004-02-24 | 2006-11-28 | Sun Microsystems, Inc. | Method and apparatus for selecting a desired application on a smart card |
US7055740B1 (en) * | 2004-12-06 | 2006-06-06 | Target Brands, Inc. | Stored-value card adapted to be read by an electronic device |
US7252225B2 (en) * | 2004-12-06 | 2007-08-07 | Target Brands, Inc. | Stored-value card adapted to be read by an electronic device |
US7232073B1 (en) | 2004-12-21 | 2007-06-19 | Sun Microsystems, Inc. | Smart card with multiple applications |
FR2881007B1 (en) * | 2005-01-19 | 2007-02-23 | Gemplus Sa | ESTABLISHING COMMUNICATION BETWEEN NON-CONTACT DEVICES |
US7992203B2 (en) * | 2006-05-24 | 2011-08-02 | Red Hat, Inc. | Methods and systems for secure shared smartcard access |
US8332637B2 (en) | 2006-06-06 | 2012-12-11 | Red Hat, Inc. | Methods and systems for nonce generation in a token |
US8364952B2 (en) | 2006-06-06 | 2013-01-29 | Red Hat, Inc. | Methods and system for a key recovery plan |
US8495380B2 (en) | 2006-06-06 | 2013-07-23 | Red Hat, Inc. | Methods and systems for server-side key generation |
US8180741B2 (en) * | 2006-06-06 | 2012-05-15 | Red Hat, Inc. | Methods and systems for providing data objects on a token |
US7822209B2 (en) | 2006-06-06 | 2010-10-26 | Red Hat, Inc. | Methods and systems for key recovery for a token |
US8098829B2 (en) | 2006-06-06 | 2012-01-17 | Red Hat, Inc. | Methods and systems for secure key delivery |
US8589695B2 (en) | 2006-06-07 | 2013-11-19 | Red Hat, Inc. | Methods and systems for entropy collection for server-side key generation |
US9769158B2 (en) | 2006-06-07 | 2017-09-19 | Red Hat, Inc. | Guided enrollment and login for token users |
US8707024B2 (en) | 2006-06-07 | 2014-04-22 | Red Hat, Inc. | Methods and systems for managing identity management security domains |
US8099765B2 (en) | 2006-06-07 | 2012-01-17 | Red Hat, Inc. | Methods and systems for remote password reset using an authentication credential managed by a third party |
US8412927B2 (en) * | 2006-06-07 | 2013-04-02 | Red Hat, Inc. | Profile framework for token processing system |
US8787566B2 (en) | 2006-08-23 | 2014-07-22 | Red Hat, Inc. | Strong encryption |
US8806219B2 (en) | 2006-08-23 | 2014-08-12 | Red Hat, Inc. | Time-based function back-off |
US8074265B2 (en) | 2006-08-31 | 2011-12-06 | Red Hat, Inc. | Methods and systems for verifying a location factor associated with a token |
US8977844B2 (en) | 2006-08-31 | 2015-03-10 | Red Hat, Inc. | Smartcard formation with authentication keys |
US9038154B2 (en) | 2006-08-31 | 2015-05-19 | Red Hat, Inc. | Token Registration |
US8356342B2 (en) | 2006-08-31 | 2013-01-15 | Red Hat, Inc. | Method and system for issuing a kill sequence for a token |
US7717335B2 (en) * | 2006-10-03 | 2010-05-18 | Target Brands, Inc. | Finger puppet stored-value card |
US8693690B2 (en) | 2006-12-04 | 2014-04-08 | Red Hat, Inc. | Organizing an extensible table for storing cryptographic objects |
US8813243B2 (en) | 2007-02-02 | 2014-08-19 | Red Hat, Inc. | Reducing a size of a security-related data object stored on a token |
US8639940B2 (en) | 2007-02-28 | 2014-01-28 | Red Hat, Inc. | Methods and systems for assigning roles on a token |
US8832453B2 (en) * | 2007-02-28 | 2014-09-09 | Red Hat, Inc. | Token recycling |
US9081948B2 (en) | 2007-03-13 | 2015-07-14 | Red Hat, Inc. | Configurable smartcard |
ITMI20070996A1 (en) * | 2007-05-17 | 2008-11-18 | Incard Sa | METHOD FOR CHECKING THE EXECUTION OF AN APPLICATION FOR AN IC CARD |
US8463279B2 (en) * | 2007-09-26 | 2013-06-11 | Qualcomm Incorporated | Methods and apparatus for application network-server determination for removable module-based wireless devices |
US8442507B2 (en) * | 2007-09-26 | 2013-05-14 | Qualcomm Incorporated | Methods and apparatus for dynamic source determination of provisioning information on a per-network service basis for open market wireless devices |
US8831575B2 (en) * | 2007-09-26 | 2014-09-09 | Qualcomm Incorporated | Apparatus and methods associated with open market handsets |
US7841538B2 (en) | 2007-10-31 | 2010-11-30 | Target Brands, Inc. | Transaction product with memory |
JP5209281B2 (en) * | 2007-11-22 | 2013-06-12 | 株式会社エヌ・ティ・ティ・ドコモ | Communication terminal device, access control method, IC card |
US8495213B2 (en) * | 2008-04-10 | 2013-07-23 | Lg Electronics Inc. | Terminal and method for managing secure devices |
US8308058B2 (en) * | 2008-07-31 | 2012-11-13 | Sybase, Inc. | Mobile banking architecture |
US20100029306A1 (en) * | 2008-07-31 | 2010-02-04 | Sybase, Inc. | Mobile Banking with Short Message Service |
US20120124659A1 (en) | 2010-11-17 | 2012-05-17 | Michael Craft | System and Method for Providing Diverse Secure Data Communication Permissions to Trusted Applications on a Portable Communication Device |
FR2968804B1 (en) * | 2010-12-13 | 2013-01-04 | St Microelectronics Rousset | METHOD FOR MANAGING THE DIALOGUE BETWEEN EQUIPMENT AND AT LEAST ONE MULTI-APPLICATION OBJECT SUCH AS A CONTACTLESS CHIP CARD AND CORRESPONDING OBJECT |
EP2775742A1 (en) | 2013-03-05 | 2014-09-10 | Sandeep Mittal | A method to launch an application on a mobile device using short code |
CN104156761A (en) * | 2014-08-06 | 2014-11-19 | 诚迈科技(南京)股份有限公司 | ID card data transmission system and method |
EP3093761A1 (en) * | 2015-05-13 | 2016-11-16 | Gemalto Sa | Integrated circuit card adapted to transfer first data from a first application for use by a second application |
US10318952B1 (en) | 2015-05-23 | 2019-06-11 | Square, Inc. | NFC base station and passive transmitter device |
US9721123B1 (en) | 2015-12-11 | 2017-08-01 | Square, Inc. | Microcontroller intercept of EMV card contact switch |
US9990194B2 (en) * | 2016-08-25 | 2018-06-05 | Oracle International Corporation | Preservation of backward compatibility for java card cap files |
US10402816B2 (en) | 2016-12-31 | 2019-09-03 | Square, Inc. | Partial data object acquisition and processing |
US9858448B1 (en) | 2017-01-31 | 2018-01-02 | Square, Inc. | Communication protocol speedup and step-down |
US10621590B2 (en) | 2017-02-22 | 2020-04-14 | Square, Inc. | Line-based chip card tamper detection |
US10438189B2 (en) | 2017-02-22 | 2019-10-08 | Square, Inc. | Server-enabled chip card interface tamper detection |
Citations (43)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO1994030023A1 (en) | 1993-06-15 | 1994-12-22 | Celltrace Communications Limited | Telecommunications system |
US5481715A (en) | 1993-12-15 | 1996-01-02 | Sun Microsystems, Inc. | Method and apparatus for delegated communications in a computer system using trusted deputies |
US5530232A (en) | 1993-12-22 | 1996-06-25 | Datamark Services, Inc. | Multi-application data card |
US5590038A (en) | 1994-06-20 | 1996-12-31 | Pitroda; Satyan G. | Universal electronic transaction card including receipt storage and system and methods of conducting electronic transactions |
US5721781A (en) | 1995-09-13 | 1998-02-24 | Microsoft Corporation | Authentication system and method for smart card transactions |
US5742756A (en) | 1996-02-12 | 1998-04-21 | Microsoft Corporation | System and method of using smart cards to perform security-critical operations requiring user authorization |
WO1998019237A1 (en) | 1996-10-25 | 1998-05-07 | Schlumberger Systemes | Using a high level programming language with a microcontroller |
WO1998037526A1 (en) | 1997-02-21 | 1998-08-27 | Mondex International Limited | Multi-application ic card system |
US5802519A (en) | 1994-02-08 | 1998-09-01 | Belle Gate Investment B.V. | Coherent data structure with multiple interaction contexts for a smart card |
US5844218A (en) | 1996-07-16 | 1998-12-01 | Transaction Technology, Inc. | Method and system for using an application programmable smart card for financial transactions in multiple countries |
US5857079A (en) | 1994-12-23 | 1999-01-05 | Lucent Technologies Inc. | Smart card for automatic financial records |
WO1999016030A1 (en) | 1997-09-19 | 1999-04-01 | Schlumberger Systemes | Smart card application-selection |
US5894550A (en) | 1996-01-19 | 1999-04-13 | Soliac | Method of implementing a secure program in a microprocessor card, and a microprocessor card including a secure program |
US5912453A (en) | 1995-09-29 | 1999-06-15 | International Business Machines Corporation | Multiple application chip card with decoupled programs |
US6005942A (en) * | 1997-03-24 | 1999-12-21 | Visa International Service Association | System and method for a multi-application smart card which can facilitate a post-issuance download of an application onto the smart card |
US6024286A (en) | 1997-10-21 | 2000-02-15 | At&T Corp | Smart card providing a plurality of independently accessible accounts |
US6032136A (en) | 1998-11-17 | 2000-02-29 | First Usa Bank, N.A. | Customer activated multi-value (CAM) card |
US6038551A (en) | 1996-03-11 | 2000-03-14 | Microsoft Corporation | System and method for configuring and managing resources on a multi-purpose integrated circuit card using a personal computer |
US6094656A (en) | 1995-08-04 | 2000-07-25 | Belle Gate Investment B.V. | Data exchange system comprising portable data processing units |
WO2000045262A2 (en) | 1999-01-22 | 2000-08-03 | Sun Microsystems, Inc. | Techniques for permitting access across a context barrier in a small footprint device using global data structures |
US6101477A (en) * | 1998-01-23 | 2000-08-08 | American Express Travel Related Services Company, Inc. | Methods and apparatus for a travel-related multi-function smartcard |
US6199762B1 (en) | 1998-05-06 | 2001-03-13 | American Express Travel Related Services Co., Inc. | Methods and apparatus for dynamic smartcard synchronization and personalization |
US20010000814A1 (en) | 1997-06-30 | 2001-05-03 | Montgomery Michael A. | Smart card control of terminal and network resources |
US20020040936A1 (en) | 1998-10-27 | 2002-04-11 | David C. Wentker | Delegated management of smart card applications |
US6390374B1 (en) | 1999-01-15 | 2002-05-21 | Todd Carper | System and method for installing/de-installing an application on a smart card |
US20020083322A1 (en) | 2000-12-22 | 2002-06-27 | Laurent Lagosanto | Distribution of deployment information for remote applications |
US6418554B1 (en) * | 1998-09-21 | 2002-07-09 | Microsoft Corporation | Software implementation installer mechanism |
US20020134843A1 (en) * | 2001-01-19 | 2002-09-26 | Minoru Ashizawa | Method of providing IC card service, card terminal, and IC card |
US6477702B1 (en) * | 1994-12-20 | 2002-11-05 | Sun Microsystems, Inc. | Bytecode program interpreter apparatus and method with pre-verification of data type restrictions and object initialization |
US20030078866A1 (en) | 1996-11-27 | 2003-04-24 | Diebold, Incorporated | Automated banking machine system using plural communication formats |
US6631849B2 (en) | 2000-12-06 | 2003-10-14 | Bank One, Delaware, National Association | Selectable multi-purpose card |
US20030212896A1 (en) | 2001-12-20 | 2003-11-13 | Andrew Kisliakov | User interface for accessing files in a smartcard file |
US20040024735A1 (en) * | 2000-09-12 | 2004-02-05 | Sue-Ken Yap | Card reading device for service access |
US20040255081A1 (en) | 2003-06-16 | 2004-12-16 | Michael Arnouse | System of secure personal identification, information processing, and precise point of contact location and timing |
US20050038741A1 (en) * | 2001-07-10 | 2005-02-17 | American Express Travel Related Services Company, Inc. | Method and system for a travel-related multi-function fob |
US20050091544A1 (en) | 2002-02-22 | 2005-04-28 | Jean-Marc Lambert | Controlling an application provided on a portable object |
US20050097550A1 (en) | 1999-02-02 | 2005-05-05 | Sun Microsystems, Inc. | Token-based linking |
US20050138354A1 (en) * | 2003-12-22 | 2005-06-23 | Sun Microsystems, Inc. | Framework for providing a security context and configurable firewall for computing systems |
US6915957B2 (en) * | 2001-12-20 | 2005-07-12 | Canon Information Systems Research Australia Pty Ltd | User interface for interaction with smart card applications |
US20050178833A1 (en) * | 2001-12-20 | 2005-08-18 | Canon Information Systems Research Australia Pty | Microprocessor card defining a custom user interface |
US20050188360A1 (en) | 2004-02-24 | 2005-08-25 | Sun Microsystems, Inc., A Delaware Corporation | Method and apparatus for providing an application on a smart card |
US20050184164A1 (en) | 2004-02-24 | 2005-08-25 | Sun Microsystems, Inc. A Delaware Corporation | Method and apparatus for installing an application onto a smart card |
US20050184163A1 (en) | 2004-02-24 | 2005-08-25 | Sun Microsystems, Inc., A Delaware Corporation | Method and apparatus for processing an application identifier from a smart card |
-
2004
- 2004-02-24 US US10/786,506 patent/US7165727B2/en active Active
Patent Citations (51)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO1994030023A1 (en) | 1993-06-15 | 1994-12-22 | Celltrace Communications Limited | Telecommunications system |
EP0748135A2 (en) | 1993-06-15 | 1996-12-11 | Celltrace Communications Limited | Telecommunications system |
EP0865217A2 (en) | 1993-06-15 | 1998-09-16 | Celltrace Communications Limited | Telecommunications system |
US5481715A (en) | 1993-12-15 | 1996-01-02 | Sun Microsystems, Inc. | Method and apparatus for delegated communications in a computer system using trusted deputies |
US5530232A (en) | 1993-12-22 | 1996-06-25 | Datamark Services, Inc. | Multi-application data card |
US6052690A (en) | 1994-02-08 | 2000-04-18 | Belle Gate Investment B.V. | Coherent data structure with multiple interaction contexts for a smart card |
US5802519A (en) | 1994-02-08 | 1998-09-01 | Belle Gate Investment B.V. | Coherent data structure with multiple interaction contexts for a smart card |
US5590038A (en) | 1994-06-20 | 1996-12-31 | Pitroda; Satyan G. | Universal electronic transaction card including receipt storage and system and methods of conducting electronic transactions |
US6477702B1 (en) * | 1994-12-20 | 2002-11-05 | Sun Microsystems, Inc. | Bytecode program interpreter apparatus and method with pre-verification of data type restrictions and object initialization |
US5857079A (en) | 1994-12-23 | 1999-01-05 | Lucent Technologies Inc. | Smart card for automatic financial records |
US6094656A (en) | 1995-08-04 | 2000-07-25 | Belle Gate Investment B.V. | Data exchange system comprising portable data processing units |
US5721781A (en) | 1995-09-13 | 1998-02-24 | Microsoft Corporation | Authentication system and method for smart card transactions |
US5912453A (en) | 1995-09-29 | 1999-06-15 | International Business Machines Corporation | Multiple application chip card with decoupled programs |
US5894550A (en) | 1996-01-19 | 1999-04-13 | Soliac | Method of implementing a secure program in a microprocessor card, and a microprocessor card including a secure program |
US5742756A (en) | 1996-02-12 | 1998-04-21 | Microsoft Corporation | System and method of using smart cards to perform security-critical operations requiring user authorization |
US6038551A (en) | 1996-03-11 | 2000-03-14 | Microsoft Corporation | System and method for configuring and managing resources on a multi-purpose integrated circuit card using a personal computer |
US5844218A (en) | 1996-07-16 | 1998-12-01 | Transaction Technology, Inc. | Method and system for using an application programmable smart card for financial transactions in multiple countries |
WO1998019237A1 (en) | 1996-10-25 | 1998-05-07 | Schlumberger Systemes | Using a high level programming language with a microcontroller |
US6308317B1 (en) * | 1996-10-25 | 2001-10-23 | Schlumberger Technologies, Inc. | Using a high level programming language with a microcontroller |
US20030078866A1 (en) | 1996-11-27 | 2003-04-24 | Diebold, Incorporated | Automated banking machine system using plural communication formats |
WO1998037526A1 (en) | 1997-02-21 | 1998-08-27 | Mondex International Limited | Multi-application ic card system |
US6005942A (en) * | 1997-03-24 | 1999-12-21 | Visa International Service Association | System and method for a multi-application smart card which can facilitate a post-issuance download of an application onto the smart card |
US6233683B1 (en) | 1997-03-24 | 2001-05-15 | Visa International Service Association | System and method for a multi-application smart card which can facilitate a post-issuance download of an application onto the smart card |
US20010000814A1 (en) | 1997-06-30 | 2001-05-03 | Montgomery Michael A. | Smart card control of terminal and network resources |
WO1999016030A1 (en) | 1997-09-19 | 1999-04-01 | Schlumberger Systemes | Smart card application-selection |
US6024286A (en) | 1997-10-21 | 2000-02-15 | At&T Corp | Smart card providing a plurality of independently accessible accounts |
US6101477A (en) * | 1998-01-23 | 2000-08-08 | American Express Travel Related Services Company, Inc. | Methods and apparatus for a travel-related multi-function smartcard |
US6199762B1 (en) | 1998-05-06 | 2001-03-13 | American Express Travel Related Services Co., Inc. | Methods and apparatus for dynamic smartcard synchronization and personalization |
US6418554B1 (en) * | 1998-09-21 | 2002-07-09 | Microsoft Corporation | Software implementation installer mechanism |
US20020040936A1 (en) | 1998-10-27 | 2002-04-11 | David C. Wentker | Delegated management of smart card applications |
US6481632B2 (en) | 1998-10-27 | 2002-11-19 | Visa International Service Association | Delegated management of smart card applications |
US6032136A (en) | 1998-11-17 | 2000-02-29 | First Usa Bank, N.A. | Customer activated multi-value (CAM) card |
US6390374B1 (en) | 1999-01-15 | 2002-05-21 | Todd Carper | System and method for installing/de-installing an application on a smart card |
WO2000045262A2 (en) | 1999-01-22 | 2000-08-03 | Sun Microsystems, Inc. | Techniques for permitting access across a context barrier in a small footprint device using global data structures |
US20050097550A1 (en) | 1999-02-02 | 2005-05-05 | Sun Microsystems, Inc. | Token-based linking |
US20040024735A1 (en) * | 2000-09-12 | 2004-02-05 | Sue-Ken Yap | Card reading device for service access |
US6631849B2 (en) | 2000-12-06 | 2003-10-14 | Bank One, Delaware, National Association | Selectable multi-purpose card |
US20020083322A1 (en) | 2000-12-22 | 2002-06-27 | Laurent Lagosanto | Distribution of deployment information for remote applications |
US6976635B2 (en) | 2001-01-19 | 2005-12-20 | Hitachi, Ltd. | Method of providing IC card service, card terminal, and IC card |
US20020134843A1 (en) * | 2001-01-19 | 2002-09-26 | Minoru Ashizawa | Method of providing IC card service, card terminal, and IC card |
US20050038741A1 (en) * | 2001-07-10 | 2005-02-17 | American Express Travel Related Services Company, Inc. | Method and system for a travel-related multi-function fob |
US6915957B2 (en) * | 2001-12-20 | 2005-07-12 | Canon Information Systems Research Australia Pty Ltd | User interface for interaction with smart card applications |
US20050178833A1 (en) * | 2001-12-20 | 2005-08-18 | Canon Information Systems Research Australia Pty | Microprocessor card defining a custom user interface |
US20030212896A1 (en) | 2001-12-20 | 2003-11-13 | Andrew Kisliakov | User interface for accessing files in a smartcard file |
US20050091544A1 (en) | 2002-02-22 | 2005-04-28 | Jean-Marc Lambert | Controlling an application provided on a portable object |
US20040255081A1 (en) | 2003-06-16 | 2004-12-16 | Michael Arnouse | System of secure personal identification, information processing, and precise point of contact location and timing |
US20050138354A1 (en) * | 2003-12-22 | 2005-06-23 | Sun Microsystems, Inc. | Framework for providing a security context and configurable firewall for computing systems |
US20050149926A1 (en) * | 2003-12-22 | 2005-07-07 | Sun Microsystems, Inc. | Framework for providing a configurable firewall for computing systems |
US20050188360A1 (en) | 2004-02-24 | 2005-08-25 | Sun Microsystems, Inc., A Delaware Corporation | Method and apparatus for providing an application on a smart card |
US20050184164A1 (en) | 2004-02-24 | 2005-08-25 | Sun Microsystems, Inc. A Delaware Corporation | Method and apparatus for installing an application onto a smart card |
US20050184163A1 (en) | 2004-02-24 | 2005-08-25 | Sun Microsystems, Inc., A Delaware Corporation | Method and apparatus for processing an application identifier from a smart card |
Non-Patent Citations (22)
Title |
---|
"Sun Microsystems Announces Javacard API", Business Wire, Oct. 1996. |
Bernadat, et al., "Java Sandboxes meet Service Guarantees: Secure Partitioning of CPU and Memory", Dec. 14, 1998, The Open Group Research Institute, Cambridge, MA, pp. 1-24. |
Chan, "Infrastructure of Multi-Application Smart Card", http://home.hkstar.com/~alanchan/papers/multiApplicationSmartCard/, Jul. 25, 2002. |
Chen, Zhiqun, "Java Card(TM) Technology for Smart Cards", Sun Microsystems, pp. 11-16, Jun. 2000. |
Dreifus, H. Smart Cards; A guide to Building and Managing Smart Card Applications; Copyright 1998; Publisher Robert Ipsen; "Smart Card Development Skills, Methods, and Tools"; pp. 159-225. |
Gong, et al. "Going Beyond the Sandbox: An Overview of the New Security Architecture in the Java TM Development Kit 1.2", USENIX Symposium on Internet Technologies and Systems-Dec. 8-11, 1997, pp. 103-112. |
Hawblitzel, et al., "Implementing Multiple Protection Domains in Java", Technical Report 97-1660, Department of Computer Science, Cornell University. |
Heiss, J. et al. "Java Card(TM) Technology Grows Up Smart", printed on Apr. 22, 2000 at http://java.sum.com/features/1999/01/javacard.html, 5 pages. |
OSS-J Architecture Board, "OSS Through Java(TM) J2EE Design Guidelines", OSS Through Java(TM) , pp. 1-116, [Online] Oct. 31, 2001. (XP002325475). |
Sun Microsystems, Inc. "Smart Cards: A primer", printed on Apr. 22, 2000 from http://www.javaworld.com/javaworld/jw-12-1997/f<SUB>-</SUB>jw-12-javadev<SUB>-</SUB>p.html, 13 pages. |
Sun Microsystems, Inc., "How to write a Java Card applet: A developer's guide", printed on Apr. 22, 2000 from http://www.javaworld.com.javaworld/jw-07-1999/f<SUB>-</SUB>jw-07-javacard<SUB>-</SUB>p.htlm, 15 pages. |
Sun Microsystems, Inc., "Java Card 2.2 Application Programming Interface", Revision 1.1 for the 2.2<SUB>-</SUB>01 Release, Sep. 2002. |
Sun Microsystems, Inc., "Java Card(TM) 2.0 Programming Concepts", Oct. 15, 1997, Revision 1.0 Final. |
Sun Microsystems, Inc., "Java Card(TM) 2.1 Application Programming Interface", Jun. 7, 1999, Final Revision 1.1. |
Sun Microsystems, Inc., "Java Card(TM) 2.2 Application Programming Interface", Palo Alto, CA, pp. 1-90, [Online] Sep. 2002. (XP002325474). |
Sun Microsystems, Inc., "Java Card(TM) 2.2 Runtime Environment (JCRE) Specification", Palo Alto, CA, pp. 1-110, [Online] Jun. 2002. (XP002325473). |
Sun Microsystems, Inc., "Java Card(TM) Applet Developer's Guide", Aug. 19, 1998, Revision 1.12. |
Sun Microsystems, Inc., "Sun's Java Card(TM) Technology Extends its Industry Leadership", printed Apr. 22, 2000 from http://java.sun.com/pr/1999/11/pr991116-01.htm l, 5 pages. |
Sun Microsystems, Inc., "Understanding Java Card 2.0", printed on Apr. 22, 2000 from http://www. javaworld.com/javaworld/jw-03-1998/f<SUB>-</SUB>jw-03-javadev<SUB>-</SUB>p.htlm, 12 pages. |
Sun Microsystems, Inc., "User's Guide, Wireless Toolkit, Version 2.1, Java(TM) 2 Platform, Micro Edition", Santa Clara, CA, pp. 7-17, 73-75, [Online] Dec. 2003. (XP002325476). |
Sun Microsystems, Inc., Java Card(TM) 2.0 Application Programming Interfaces, Oct. 13, 1997, Revision 1.0 Final. |
Thomas, David J., "Smart and Smarter: The Emergence of Java Card(TM) Technology", printed on Apr. 22, 2000 from http://java/sun.com/features/1998/04/javacard.html, 8 pages. |
Cited By (295)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040215596A1 (en) * | 2000-09-29 | 2004-10-28 | Fukuhara Keith T | System, method and apparatus for data processing and storage to provide continuous operations independent of device failure or disaster |
US20110213898A1 (en) * | 2002-01-08 | 2011-09-01 | Fiatal Trevor A | Mobile device power management in data synchronization over a mobile network with or without a trigger notification |
US8549587B2 (en) | 2002-01-08 | 2013-10-01 | Seven Networks, Inc. | Secure end-to-end transport through intermediary nodes |
US8127342B2 (en) | 2002-01-08 | 2012-02-28 | Seven Networks, Inc. | Secure end-to-end transport through intermediary nodes |
US8989728B2 (en) | 2002-01-08 | 2015-03-24 | Seven Networks, Inc. | Connection architecture for a mobile network |
US20110099363A1 (en) * | 2002-01-08 | 2011-04-28 | Boynton Lee R | Secure end-to-end transport through intermediary nodes |
US8811952B2 (en) | 2002-01-08 | 2014-08-19 | Seven Networks, Inc. | Mobile device power management in data synchronization over a mobile network with or without a trigger notification |
US20080134292A1 (en) * | 2003-01-08 | 2008-06-05 | Ido Ariel | Extending user relationships |
US9251193B2 (en) | 2003-01-08 | 2016-02-02 | Seven Networks, Llc | Extending user relationships |
USRE45348E1 (en) | 2004-10-20 | 2015-01-20 | Seven Networks, Inc. | Method and apparatus for intercepting events in a communication system |
US20060084410A1 (en) * | 2004-10-20 | 2006-04-20 | Jay Sutaria | Flexible billing architecture |
US8010082B2 (en) | 2004-10-20 | 2011-08-30 | Seven Networks, Inc. | Flexible billing architecture |
US8831561B2 (en) | 2004-10-20 | 2014-09-09 | Seven Networks, Inc | System and method for tracking billing events in a mobile wireless network for a network operator |
US20090054034A1 (en) * | 2004-11-22 | 2009-02-26 | Ari Backholm | Maintaining Mobile Terminal Information for Secure E-Mail Communications |
US10659421B2 (en) | 2004-11-22 | 2020-05-19 | Seven Networks, Llc | Messaging centre for forwarding e-mail |
US8805334B2 (en) | 2004-11-22 | 2014-08-12 | Seven Networks, Inc. | Maintaining mobile terminal information for secure communications |
US20090063647A1 (en) * | 2004-11-22 | 2009-03-05 | Seven Networks International Oy | Messaging centre for forwarding e-mail |
US8116214B2 (en) | 2004-12-03 | 2012-02-14 | Seven Networks, Inc. | Provisioning of e-mail settings for a mobile terminal |
US8873411B2 (en) | 2004-12-03 | 2014-10-28 | Seven Networks, Inc. | Provisioning of e-mail settings for a mobile terminal |
US20070136797A1 (en) * | 2005-01-11 | 2007-06-14 | Matsushita Electric Industrial Co., Ltd. | Secure device and system for issuing ic cards |
US7428992B2 (en) * | 2005-01-11 | 2008-09-30 | Matsushita Electric Industrial Co., Ltd. | Secure device and system for issuing IC cards |
US8561086B2 (en) | 2005-03-14 | 2013-10-15 | Seven Networks, Inc. | System and method for executing commands that are non-native to the native environment of a mobile device |
US9047142B2 (en) | 2005-03-14 | 2015-06-02 | Seven Networks, Inc. | Intelligent rendering of information in a limited display environment |
US8209709B2 (en) | 2005-03-14 | 2012-06-26 | Seven Networks, Inc. | Cross-platform event engine |
US8438633B1 (en) | 2005-04-21 | 2013-05-07 | Seven Networks, Inc. | Flexible real-time inbox access |
US8064583B1 (en) | 2005-04-21 | 2011-11-22 | Seven Networks, Inc. | Multiple data store authentication |
US8839412B1 (en) | 2005-04-21 | 2014-09-16 | Seven Networks, Inc. | Flexible real-time inbox access |
US8761756B2 (en) | 2005-06-21 | 2014-06-24 | Seven Networks International Oy | Maintaining an IP connection in a mobile network |
US8468126B2 (en) | 2005-08-01 | 2013-06-18 | Seven Networks, Inc. | Publishing data in an information community |
US8069166B2 (en) | 2005-08-01 | 2011-11-29 | Seven Networks, Inc. | Managing user-to-user contact with inferred presence information |
US20070027920A1 (en) * | 2005-08-01 | 2007-02-01 | Billy Alvarado | Context aware data presentation |
US8412675B2 (en) | 2005-08-01 | 2013-04-02 | Seven Networks, Inc. | Context aware data presentation |
US9055102B2 (en) | 2006-02-27 | 2015-06-09 | Seven Networks, Inc. | Location-based operations and messaging |
US20070290787A1 (en) * | 2006-06-20 | 2007-12-20 | Trevor Fiatal | Systems and methods for group messaging |
US8805425B2 (en) | 2007-06-01 | 2014-08-12 | Seven Networks, Inc. | Integrated messaging |
US8693494B2 (en) | 2007-06-01 | 2014-04-08 | Seven Networks, Inc. | Polling |
US8774844B2 (en) | 2007-06-01 | 2014-07-08 | Seven Networks, Inc. | Integrated messaging |
US20110190014A1 (en) * | 2007-06-01 | 2011-08-04 | Trevor Fiatal | Integrated messaging |
US20110167242A1 (en) * | 2007-11-27 | 2011-07-07 | Oracle America, Inc. | Multiple instruction execution mode resource-constrained device |
US8943486B2 (en) * | 2007-11-27 | 2015-01-27 | Oracle America, Inc. | Multiple instruction execution mode resource-constrained device |
US8738050B2 (en) | 2007-12-10 | 2014-05-27 | Seven Networks, Inc. | Electronic-mail filtering for mobile devices |
US20090149203A1 (en) * | 2007-12-10 | 2009-06-11 | Ari Backholm | Electronic-mail filtering for mobile devices |
US8364181B2 (en) | 2007-12-10 | 2013-01-29 | Seven Networks, Inc. | Electronic-mail filtering for mobile devices |
US9002828B2 (en) | 2007-12-13 | 2015-04-07 | Seven Networks, Inc. | Predictive content delivery |
US8793305B2 (en) | 2007-12-13 | 2014-07-29 | Seven Networks, Inc. | Content delivery to a mobile device from a content service |
US8914002B2 (en) | 2008-01-11 | 2014-12-16 | Seven Networks, Inc. | System and method for providing a network service in a distributed fashion to a mobile device |
US8909192B2 (en) | 2008-01-11 | 2014-12-09 | Seven Networks, Inc. | Mobile virtual network operator |
US20090181641A1 (en) * | 2008-01-11 | 2009-07-16 | Trevor Fiatal | Mobile virtual network operator |
US8107921B2 (en) | 2008-01-11 | 2012-01-31 | Seven Networks, Inc. | Mobile virtual network operator |
US9712986B2 (en) | 2008-01-11 | 2017-07-18 | Seven Networks, Llc | Mobile device configured for communicating with another mobile device associated with an associated user |
US8849902B2 (en) | 2008-01-25 | 2014-09-30 | Seven Networks, Inc. | System for providing policy based content service in a mobile network |
US20090164560A1 (en) * | 2008-01-25 | 2009-06-25 | Trevor Fiatal | Policy based content service |
US8862657B2 (en) | 2008-01-25 | 2014-10-14 | Seven Networks, Inc. | Policy based content service |
US8838744B2 (en) | 2008-01-28 | 2014-09-16 | Seven Networks, Inc. | Web-based access to data objects |
US20090193130A1 (en) * | 2008-01-28 | 2009-07-30 | Trevor Fiatal | Web-Based Access to Data Objects |
US8799410B2 (en) | 2008-01-28 | 2014-08-05 | Seven Networks, Inc. | System and method of a relay server for managing communications and notification between a mobile device and a web access server |
US20110238772A1 (en) * | 2008-01-28 | 2011-09-29 | Trevor Fiatal | System and method for facilitating mobile traffic in a mobile network |
US20110191474A1 (en) * | 2008-01-28 | 2011-08-04 | Trevor Fiatal | System and method of a relay server for managing communications and notification between a mobile device and application server |
US20090248670A1 (en) * | 2008-03-31 | 2009-10-01 | Trevor Fiatal | Content search engine |
US20090318171A1 (en) * | 2008-06-18 | 2009-12-24 | Ari Backholm | Application Discovery on Mobile Devices |
US8787947B2 (en) | 2008-06-18 | 2014-07-22 | Seven Networks, Inc. | Application discovery on mobile devices |
US20090325565A1 (en) * | 2008-06-26 | 2009-12-31 | Ari Backholm | Provisioning applications for a mobile device |
US8078158B2 (en) | 2008-06-26 | 2011-12-13 | Seven Networks, Inc. | Provisioning applications for a mobile device |
US8494510B2 (en) | 2008-06-26 | 2013-07-23 | Seven Networks, Inc. | Provisioning applications for a mobile device |
US8607321B2 (en) | 2008-06-27 | 2013-12-10 | Microsoft Corporation | Identification of a smart card on a plug and play system |
US20100146107A1 (en) * | 2008-10-10 | 2010-06-10 | Trevor Fiatal | Bandwidth Measurement |
US8909759B2 (en) | 2008-10-10 | 2014-12-09 | Seven Networks, Inc. | Bandwidth measurement |
US9043731B2 (en) | 2010-03-30 | 2015-05-26 | Seven Networks, Inc. | 3D mobile user interface with configurable workspace management |
US8838783B2 (en) | 2010-07-26 | 2014-09-16 | Seven Networks, Inc. | Distributed caching for resource and mobile network traffic management |
US9077630B2 (en) | 2010-07-26 | 2015-07-07 | Seven Networks, Inc. | Distributed implementation of dynamic wireless traffic policy |
US9049179B2 (en) | 2010-07-26 | 2015-06-02 | Seven Networks, Inc. | Mobile network traffic coordination across multiple applications |
US9043433B2 (en) | 2010-07-26 | 2015-05-26 | Seven Networks, Inc. | Mobile network traffic coordination across multiple applications |
US9407713B2 (en) | 2010-07-26 | 2016-08-02 | Seven Networks, Llc | Mobile application traffic optimization |
US8886176B2 (en) | 2010-07-26 | 2014-11-11 | Seven Networks, Inc. | Mobile application traffic optimization |
US8166164B1 (en) | 2010-11-01 | 2012-04-24 | Seven Networks, Inc. | Application and network-based long poll request detection and cacheability assessment therefor |
US8204953B2 (en) | 2010-11-01 | 2012-06-19 | Seven Networks, Inc. | Distributed system for cache defeat detection and caching of content addressed by identifiers intended to defeat cache |
US8326985B2 (en) | 2010-11-01 | 2012-12-04 | Seven Networks, Inc. | Distributed management of keep-alive message signaling for mobile network resource conservation and optimization |
US9275163B2 (en) | 2010-11-01 | 2016-03-01 | Seven Networks, Llc | Request and response characteristics based adaptation of distributed caching in a mobile network |
US8966066B2 (en) | 2010-11-01 | 2015-02-24 | Seven Networks, Inc. | Application and network-based long poll request detection and cacheability assessment therefor |
US9060032B2 (en) | 2010-11-01 | 2015-06-16 | Seven Networks, Inc. | Selective data compression by a distributed traffic management system to reduce mobile data traffic and signaling traffic |
US8700728B2 (en) | 2010-11-01 | 2014-04-15 | Seven Networks, Inc. | Cache defeat detection and caching of content addressed by identifiers intended to defeat cache |
US8291076B2 (en) | 2010-11-01 | 2012-10-16 | Seven Networks, Inc. | Application and network-based long poll request detection and cacheability assessment therefor |
US8484314B2 (en) | 2010-11-01 | 2013-07-09 | Seven Networks, Inc. | Distributed caching in a wireless network of content delivered for a mobile application over a long-held request |
US9330196B2 (en) | 2010-11-01 | 2016-05-03 | Seven Networks, Llc | Wireless traffic management system cache optimization using http headers |
US8190701B2 (en) | 2010-11-01 | 2012-05-29 | Seven Networks, Inc. | Cache defeat detection and caching of content addressed by identifiers intended to defeat cache |
US8843153B2 (en) | 2010-11-01 | 2014-09-23 | Seven Networks, Inc. | Mobile traffic categorization and policy for network use optimization while preserving user experience |
US8782222B2 (en) | 2010-11-01 | 2014-07-15 | Seven Networks | Timing of keep-alive messages used in a system for mobile network resource conservation and optimization |
US9100873B2 (en) | 2010-11-22 | 2015-08-04 | Seven Networks, Inc. | Mobile network background traffic data management |
US8417823B2 (en) | 2010-11-22 | 2013-04-09 | Seven Network, Inc. | Aligning data transfer to optimize connections established for transmission over a wireless network |
US8903954B2 (en) | 2010-11-22 | 2014-12-02 | Seven Networks, Inc. | Optimization of resource polling intervals to satisfy mobile device requests |
US8539040B2 (en) | 2010-11-22 | 2013-09-17 | Seven Networks, Inc. | Mobile network background traffic data management with optimized polling intervals |
US8806199B2 (en) | 2010-12-17 | 2014-08-12 | Google Inc. | Writing application data to a secure element |
US8335921B2 (en) | 2010-12-17 | 2012-12-18 | Google, Inc. | Writing application data to a secure element |
US20120159148A1 (en) * | 2010-12-17 | 2012-06-21 | Google Inc. | Local trusted services manager for a contactless smart card |
US8646059B1 (en) | 2010-12-17 | 2014-02-04 | Google Inc. | Wallet application for interacting with a secure element application without a trusted server for authentication |
US8807440B1 (en) | 2010-12-17 | 2014-08-19 | Google Inc. | Routing secure element payment requests to an alternate application |
US8196131B1 (en) * | 2010-12-17 | 2012-06-05 | Google Inc. | Payment application lifecycle management in a contactless smart card |
US8793508B2 (en) | 2010-12-17 | 2014-07-29 | Google Inc. | Local trusted services manager for a contactless smart card |
US8335932B2 (en) * | 2010-12-17 | 2012-12-18 | Google Inc. | Local trusted services manager for a contactless smart card |
US8352749B2 (en) | 2010-12-17 | 2013-01-08 | Google Inc. | Local trusted services manager for a contactless smart card |
US9325662B2 (en) | 2011-01-07 | 2016-04-26 | Seven Networks, Llc | System and method for reduction of mobile network traffic used for domain name system (DNS) queries |
US9300719B2 (en) | 2011-04-19 | 2016-03-29 | Seven Networks, Inc. | System and method for a mobile device to use physical storage of another device for caching |
US8316098B2 (en) | 2011-04-19 | 2012-11-20 | Seven Networks Inc. | Social caching for device resource sharing and management |
US8356080B2 (en) | 2011-04-19 | 2013-01-15 | Seven Networks, Inc. | System and method for a mobile device to use physical storage of another device for caching |
US9084105B2 (en) | 2011-04-19 | 2015-07-14 | Seven Networks, Inc. | Device resources sharing for network resource conservation |
US8621075B2 (en) | 2011-04-27 | 2013-12-31 | Seven Metworks, Inc. | Detecting and preserving state for satisfying application requests in a distributed proxy and cache system |
US8832228B2 (en) | 2011-04-27 | 2014-09-09 | Seven Networks, Inc. | System and method for making requests on behalf of a mobile device based on atomic processes for mobile network traffic relief |
US8635339B2 (en) | 2011-04-27 | 2014-01-21 | Seven Networks, Inc. | Cache state management on a mobile device to preserve user experience |
US8984581B2 (en) | 2011-07-27 | 2015-03-17 | Seven Networks, Inc. | Monitoring mobile application activities for malicious traffic on a mobile device |
US9239800B2 (en) | 2011-07-27 | 2016-01-19 | Seven Networks, Llc | Automatic generation and distribution of policy information regarding malicious mobile traffic in a wireless network |
US9450927B2 (en) | 2011-09-15 | 2016-09-20 | Google Inc. | Enabling users to select between secure service providers using a key escrow service |
US8737621B2 (en) | 2011-09-15 | 2014-05-27 | Google Inc. | Enabling users to select between secure service providers using a central trusted service manager |
US8379863B1 (en) | 2011-09-15 | 2013-02-19 | Google Inc. | Enabling users to select between secure service providers using a central trusted service manager |
US8412933B1 (en) | 2011-09-15 | 2013-04-02 | Google Inc. | Enabling users to select between secure service providers using a key escrow service |
US8511573B2 (en) | 2011-09-16 | 2013-08-20 | Google Inc. | Secure application directory |
US8313036B1 (en) | 2011-09-16 | 2012-11-20 | Google Inc. | Secure application directory |
US8297520B1 (en) | 2011-09-16 | 2012-10-30 | Google Inc. | Secure application directory |
US8868753B2 (en) | 2011-12-06 | 2014-10-21 | Seven Networks, Inc. | System of redundantly clustered machines to provide failover mechanisms for mobile traffic management and network resource conservation |
US8918503B2 (en) | 2011-12-06 | 2014-12-23 | Seven Networks, Inc. | Optimization of mobile traffic directed to private networks and operator configurability thereof |
US8977755B2 (en) | 2011-12-06 | 2015-03-10 | Seven Networks, Inc. | Mobile device and method to utilize the failover mechanism for fault tolerance provided for mobile traffic management and network/device resource conservation |
US9009250B2 (en) | 2011-12-07 | 2015-04-14 | Seven Networks, Inc. | Flexible and dynamic integration schemas of a traffic management system with various network operators for network traffic alleviation |
US9277443B2 (en) | 2011-12-07 | 2016-03-01 | Seven Networks, Llc | Radio-awareness of mobile device for sending server-side control signals using a wireless network optimized transport protocol |
US9208123B2 (en) | 2011-12-07 | 2015-12-08 | Seven Networks, Llc | Mobile device having content caching mechanisms integrated with a network operator for traffic alleviation in a wireless network and methods therefor |
US9173128B2 (en) | 2011-12-07 | 2015-10-27 | Seven Networks, Llc | Radio-awareness of mobile device for sending server-side control signals using a wireless network optimized transport protocol |
US9021021B2 (en) | 2011-12-14 | 2015-04-28 | Seven Networks, Inc. | Mobile network reporting and usage analytics system and method aggregated using a distributed traffic optimization system |
US8861354B2 (en) | 2011-12-14 | 2014-10-14 | Seven Networks, Inc. | Hierarchies and categories for management and deployment of policies for distributed wireless traffic optimization |
US9832095B2 (en) | 2011-12-14 | 2017-11-28 | Seven Networks, Llc | Operation modes for mobile traffic optimization and concurrent management of optimized and non-optimized traffic |
US9131397B2 (en) | 2012-01-05 | 2015-09-08 | Seven Networks, Inc. | Managing cache to prevent overloading of a wireless network due to user activity |
US8909202B2 (en) | 2012-01-05 | 2014-12-09 | Seven Networks, Inc. | Detection and management of user interactions with foreground applications on a mobile device in distributed caching |
US9203864B2 (en) | 2012-02-02 | 2015-12-01 | Seven Networks, Llc | Dynamic categorization of applications for network access in a mobile network |
US9326189B2 (en) | 2012-02-03 | 2016-04-26 | Seven Networks, Llc | User as an end point for profiling and optimizing the delivery of content and data in a wireless network |
US8385553B1 (en) | 2012-02-28 | 2013-02-26 | Google Inc. | Portable secure element |
US8625800B2 (en) | 2012-02-28 | 2014-01-07 | Google Inc. | Portable secure element |
US8429409B1 (en) | 2012-04-06 | 2013-04-23 | Google Inc. | Secure reset of personal and service provider information on mobile devices |
US8971533B2 (en) | 2012-04-06 | 2015-03-03 | Google Inc. | Secure reset of personal and service provider information on mobile devices |
US8812695B2 (en) | 2012-04-09 | 2014-08-19 | Seven Networks, Inc. | Method and system for management of a virtual network connection without heartbeat messages |
US10263899B2 (en) | 2012-04-10 | 2019-04-16 | Seven Networks, Llc | Enhanced customer service for mobile carriers using real-time and historical mobile application and traffic or optimization data associated with mobile devices in a mobile network |
US8775631B2 (en) | 2012-07-13 | 2014-07-08 | Seven Networks, Inc. | Dynamic bandwidth adjustment for browsing or streaming activity in a wireless network based on prediction of user behavior when interacting with mobile applications |
US9161258B2 (en) | 2012-10-24 | 2015-10-13 | Seven Networks, Llc | Optimized and selective management of policy deployment to mobile clients in a congested network to prevent further aggravation of network congestion |
US9307493B2 (en) | 2012-12-20 | 2016-04-05 | Seven Networks, Llc | Systems and methods for application management of mobile device radio state promotion and demotion |
US9241314B2 (en) | 2013-01-23 | 2016-01-19 | Seven Networks, Llc | Mobile device with application or context aware fast dormancy |
US9271238B2 (en) | 2013-01-23 | 2016-02-23 | Seven Networks, Llc | Application or context aware fast dormancy |
US8874761B2 (en) | 2013-01-25 | 2014-10-28 | Seven Networks, Inc. | Signaling optimization in a wireless network for traffic utilizing proprietary and non-proprietary protocols |
US8750123B1 (en) | 2013-03-11 | 2014-06-10 | Seven Networks, Inc. | Mobile device equipped with mobile network congestion recognition to make intelligent decisions regarding connecting to an operator network |
US9065765B2 (en) | 2013-07-22 | 2015-06-23 | Seven Networks, Inc. | Proxy server associated with a mobile carrier for enhancing mobile traffic management in a mobile network |
US10878651B2 (en) | 2018-06-21 | 2020-12-29 | Capital One Services, Llc | Systems and methods for secure read-only authentication |
US10546444B2 (en) | 2018-06-21 | 2020-01-28 | Capital One Services, Llc | Systems and methods for secure read-only authentication |
US10769299B2 (en) | 2018-07-12 | 2020-09-08 | Capital One Services, Llc | System and method for dynamic generation of URL by smart card |
US11556668B2 (en) | 2018-07-12 | 2023-01-17 | Capital One Services, Llc | System and method for dynamic generation of URL by smart card |
US11797710B2 (en) | 2018-07-12 | 2023-10-24 | Capital One Services, Llc | System and method for dynamic generation of URL by smart card |
US11770254B2 (en) | 2018-10-02 | 2023-09-26 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10778437B2 (en) | 2018-10-02 | 2020-09-15 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US11129019B2 (en) | 2018-10-02 | 2021-09-21 | Capital One Services, Llc | Systems and methods for performing transactions with contactless cards |
US10511443B1 (en) | 2018-10-02 | 2019-12-17 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10505738B1 (en) | 2018-10-02 | 2019-12-10 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US11182785B2 (en) | 2018-10-02 | 2021-11-23 | Capital One Services, Llc | Systems and methods for authorization and access to services using contactless cards |
US11790187B2 (en) | 2018-10-02 | 2023-10-17 | Capital One Services, Llc | Systems and methods for data transmission using contactless cards |
US10542036B1 (en) | 2018-10-02 | 2020-01-21 | Capital One Services, Llc | Systems and methods for signaling an attack on contactless cards |
US11784820B2 (en) | 2018-10-02 | 2023-10-10 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US11843698B2 (en) | 2018-10-02 | 2023-12-12 | Capital One Services, Llc | Systems and methods of key selection for cryptographic authentication of contactless cards |
US10554411B1 (en) | 2018-10-02 | 2020-02-04 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10565587B1 (en) | 2018-10-02 | 2020-02-18 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10581611B1 (en) | 2018-10-02 | 2020-03-03 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10579998B1 (en) | 2018-10-02 | 2020-03-03 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10582386B1 (en) | 2018-10-02 | 2020-03-03 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10592710B1 (en) | 2018-10-02 | 2020-03-17 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10607214B1 (en) | 2018-10-02 | 2020-03-31 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10607216B1 (en) | 2018-10-02 | 2020-03-31 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10615981B1 (en) | 2018-10-02 | 2020-04-07 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10623393B1 (en) | 2018-10-02 | 2020-04-14 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10630653B1 (en) | 2018-10-02 | 2020-04-21 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10489781B1 (en) | 2018-10-02 | 2019-11-26 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US11728994B2 (en) | 2018-10-02 | 2023-08-15 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US11182784B2 (en) | 2018-10-02 | 2021-11-23 | Capital One Services, Llc | Systems and methods for performing transactions with contactless cards |
US11699047B2 (en) | 2018-10-02 | 2023-07-11 | Capital One Services, Llc | Systems and methods for contactless card applet communication |
US10680824B2 (en) | 2018-10-02 | 2020-06-09 | Capital One Services, Llc | Systems and methods for inventory management using cryptographic authentication of contactless cards |
US10686603B2 (en) | 2018-10-02 | 2020-06-16 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10685350B2 (en) | 2018-10-02 | 2020-06-16 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US11658997B2 (en) | 2018-10-02 | 2023-05-23 | Capital One Services, Llc | Systems and methods for signaling an attack on contactless cards |
US11610195B2 (en) | 2018-10-02 | 2023-03-21 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US11563583B2 (en) | 2018-10-02 | 2023-01-24 | Capital One Services, Llc | Systems and methods for content management using contactless cards |
US11843700B2 (en) | 2018-10-02 | 2023-12-12 | Capital One Services, Llc | Systems and methods for email-based card activation |
US10733645B2 (en) | 2018-10-02 | 2020-08-04 | Capital One Services, Llc | Systems and methods for establishing identity for order pick up |
US10748138B2 (en) | 2018-10-02 | 2020-08-18 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US11544707B2 (en) | 2018-10-02 | 2023-01-03 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10771253B2 (en) | 2018-10-02 | 2020-09-08 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US11102007B2 (en) | 2018-10-02 | 2021-08-24 | Capital One Services, Llc | Contactless card emulation system and method |
US10771254B2 (en) | 2018-10-02 | 2020-09-08 | Capital One Services, Llc | Systems and methods for email-based card activation |
US11804964B2 (en) | 2018-10-02 | 2023-10-31 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US11502844B2 (en) | 2018-10-02 | 2022-11-15 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10783519B2 (en) | 2018-10-02 | 2020-09-22 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10797882B2 (en) | 2018-10-02 | 2020-10-06 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US11469898B2 (en) | 2018-10-02 | 2022-10-11 | Capital One Services, Llc | Systems and methods for message presentation using contactless cards |
US10841091B2 (en) | 2018-10-02 | 2020-11-17 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US11456873B2 (en) | 2018-10-02 | 2022-09-27 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US11444775B2 (en) | 2018-10-02 | 2022-09-13 | Capital One Services, Llc | Systems and methods for content management using contactless cards |
US11438311B2 (en) | 2018-10-02 | 2022-09-06 | Capital One Services, Llc | Systems and methods for card information management |
US11438164B2 (en) | 2018-10-02 | 2022-09-06 | Capital One Services, Llc | Systems and methods for email-based card activation |
US10860814B2 (en) | 2018-10-02 | 2020-12-08 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US11423452B2 (en) | 2018-10-02 | 2022-08-23 | Capital One Services, Llc | Systems and methods for establishing identity for order pick up |
US11144915B2 (en) | 2018-10-02 | 2021-10-12 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards using risk factors |
US10880327B2 (en) | 2018-10-02 | 2020-12-29 | Capital One Services, Llc | Systems and methods for signaling an attack on contactless cards |
US11195174B2 (en) | 2018-10-02 | 2021-12-07 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US11349667B2 (en) | 2018-10-02 | 2022-05-31 | Capital One Services, Llc | Systems and methods for inventory management using cryptographic authentication of contactless cards |
US10887106B2 (en) | 2018-10-02 | 2021-01-05 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10909527B2 (en) | 2018-10-02 | 2021-02-02 | Capital One Services, Llc | Systems and methods for performing a reissue of a contactless card |
US11341480B2 (en) | 2018-10-02 | 2022-05-24 | Capital One Services, Llc | Systems and methods for phone-based card activation |
US11336454B2 (en) | 2018-10-02 | 2022-05-17 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10949520B2 (en) | 2018-10-02 | 2021-03-16 | Capital One Services, Llc | Systems and methods for cross coupling risk analytics and one-time-passcodes |
US10965465B2 (en) | 2018-10-02 | 2021-03-30 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US11321546B2 (en) | 2018-10-02 | 2022-05-03 | Capital One Services, Llc | Systems and methods data transmission using contactless cards |
US11301848B2 (en) | 2018-10-02 | 2022-04-12 | Capital One Services, Llc | Systems and methods for secure transaction approval |
US11297046B2 (en) | 2018-10-02 | 2022-04-05 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10992477B2 (en) | 2018-10-02 | 2021-04-27 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US11232272B2 (en) | 2018-10-02 | 2022-01-25 | Capital One Services, Llc | Systems and methods for contactless card applet communication |
US11233645B2 (en) | 2018-10-02 | 2022-01-25 | Capital One Services, Llc | Systems and methods of key selection for cryptographic authentication of contactless cards |
US11210664B2 (en) | 2018-10-02 | 2021-12-28 | Capital One Services, Llc | Systems and methods for amplifying the strength of cryptographic algorithms |
US11361302B2 (en) | 2019-01-11 | 2022-06-14 | Capital One Services, Llc | Systems and methods for touch screen interface interaction using a card overlay |
US11037136B2 (en) | 2019-01-24 | 2021-06-15 | Capital One Services, Llc | Tap to autofill card data |
US10467622B1 (en) | 2019-02-01 | 2019-11-05 | Capital One Services, Llc | Using on-demand applications to generate virtual numbers for a contactless card to securely autofill forms |
US11120453B2 (en) | 2019-02-01 | 2021-09-14 | Capital One Services, Llc | Tap card to securely generate card data to copy to clipboard |
US10510074B1 (en) | 2019-02-01 | 2019-12-17 | Capital One Services, Llc | One-tap payment using a contactless card |
US10425129B1 (en) | 2019-02-27 | 2019-09-24 | Capital One Services, Llc | Techniques to reduce power consumption in near field communication systems |
US10523708B1 (en) | 2019-03-18 | 2019-12-31 | Capital One Services, Llc | System and method for second factor authentication of customer support calls |
US10438437B1 (en) | 2019-03-20 | 2019-10-08 | Capital One Services, Llc | Tap to copy data to clipboard via NFC |
US10783736B1 (en) | 2019-03-20 | 2020-09-22 | Capital One Services, Llc | Tap to copy data to clipboard via NFC |
US10984416B2 (en) | 2019-03-20 | 2021-04-20 | Capital One Services, Llc | NFC mobile currency transfer |
US10643420B1 (en) | 2019-03-20 | 2020-05-05 | Capital One Services, Llc | Contextual tapping engine |
US10535062B1 (en) | 2019-03-20 | 2020-01-14 | Capital One Services, Llc | Using a contactless card to securely share personal data stored in a blockchain |
US10970712B2 (en) | 2019-03-21 | 2021-04-06 | Capital One Services, Llc | Delegated administration of permissions using a contactless card |
US10467445B1 (en) | 2019-03-28 | 2019-11-05 | Capital One Services, Llc | Devices and methods for contactless card alignment with a foldable mobile device |
US11521262B2 (en) | 2019-05-28 | 2022-12-06 | Capital One Services, Llc | NFC enhanced augmented reality information overlays |
US10516447B1 (en) | 2019-06-17 | 2019-12-24 | Capital One Services, Llc | Dynamic power levels in NFC card communications |
US11694187B2 (en) | 2019-07-03 | 2023-07-04 | Capital One Services, Llc | Constraining transactional capabilities for contactless cards |
US11392933B2 (en) | 2019-07-03 | 2022-07-19 | Capital One Services, Llc | Systems and methods for providing online and hybridcard interactions |
US10871958B1 (en) | 2019-07-03 | 2020-12-22 | Capital One Services, Llc | Techniques to perform applet programming |
US10713649B1 (en) | 2019-07-09 | 2020-07-14 | Capital One Services, Llc | System and method enabling mobile near-field communication to update display on a payment card |
US10885514B1 (en) | 2019-07-15 | 2021-01-05 | Capital One Services, Llc | System and method for using image data to trigger contactless card transactions |
US10498401B1 (en) | 2019-07-15 | 2019-12-03 | Capital One Services, Llc | System and method for guiding card positioning using phone sensors |
US10733601B1 (en) | 2019-07-17 | 2020-08-04 | Capital One Services, Llc | Body area network facilitated authentication or payment authorization |
US10832271B1 (en) | 2019-07-17 | 2020-11-10 | Capital One Services, Llc | Verified reviews using a contactless card |
US11182771B2 (en) | 2019-07-17 | 2021-11-23 | Capital One Services, Llc | System for value loading onto in-vehicle device |
US11521213B2 (en) | 2019-07-18 | 2022-12-06 | Capital One Services, Llc | Continuous authentication for digital services based on contactless card positioning |
US10506426B1 (en) | 2019-07-19 | 2019-12-10 | Capital One Services, Llc | Techniques for call authentication |
US10541995B1 (en) | 2019-07-23 | 2020-01-21 | Capital One Services, Llc | First factor contactless card authentication system and method |
US10701560B1 (en) | 2019-10-02 | 2020-06-30 | Capital One Services, Llc | Client device authentication using contactless legacy magnetic stripe data |
US11638148B2 (en) | 2019-10-02 | 2023-04-25 | Capital One Services, Llc | Client device authentication using contactless legacy magnetic stripe data |
US11651361B2 (en) | 2019-12-23 | 2023-05-16 | Capital One Services, Llc | Secure authentication based on passport data stored in a contactless card |
US10885410B1 (en) | 2019-12-23 | 2021-01-05 | Capital One Services, Llc | Generating barcodes utilizing cryptographic techniques |
US11113685B2 (en) | 2019-12-23 | 2021-09-07 | Capital One Services, Llc | Card issuing with restricted virtual numbers |
US10657754B1 (en) | 2019-12-23 | 2020-05-19 | Capital One Services, Llc | Contactless card and personal identification system |
US10862540B1 (en) | 2019-12-23 | 2020-12-08 | Capital One Services, Llc | Method for mapping NFC field strength and location on mobile devices |
US10733283B1 (en) | 2019-12-23 | 2020-08-04 | Capital One Services, Llc | Secure password generation and management using NFC and contactless smart cards |
US11615395B2 (en) | 2019-12-23 | 2023-03-28 | Capital One Services, Llc | Authentication for third party digital wallet provisioning |
US10664941B1 (en) | 2019-12-24 | 2020-05-26 | Capital One Services, Llc | Steganographic image encoding of biometric template information on a card |
US10853795B1 (en) | 2019-12-24 | 2020-12-01 | Capital One Services, Llc | Secure authentication based on identity data stored in a contactless card |
US11200563B2 (en) | 2019-12-24 | 2021-12-14 | Capital One Services, Llc | Account registration using a contactless card |
US10757574B1 (en) | 2019-12-26 | 2020-08-25 | Capital One Services, Llc | Multi-factor authentication providing a credential via a contactless card for secure messaging |
US10909544B1 (en) | 2019-12-26 | 2021-02-02 | Capital One Services, Llc | Accessing and utilizing multiple loyalty point accounts |
US11038688B1 (en) | 2019-12-30 | 2021-06-15 | Capital One Services, Llc | Techniques to control applets for contactless cards |
US11455620B2 (en) | 2019-12-31 | 2022-09-27 | Capital One Services, Llc | Tapping a contactless card to a computing device to provision a virtual number |
US10860914B1 (en) | 2019-12-31 | 2020-12-08 | Capital One Services, Llc | Contactless card and method of assembly |
US11210656B2 (en) | 2020-04-13 | 2021-12-28 | Capital One Services, Llc | Determining specific terms for contactless card activation |
US10915888B1 (en) | 2020-04-30 | 2021-02-09 | Capital One Services, Llc | Contactless card with multiple rotating security keys |
US11030339B1 (en) | 2020-04-30 | 2021-06-08 | Capital One Services, Llc | Systems and methods for data access control of personal user data using a short-range transceiver |
US11562346B2 (en) | 2020-04-30 | 2023-01-24 | Capital One Services, Llc | Contactless card with multiple rotating security keys |
US10861006B1 (en) | 2020-04-30 | 2020-12-08 | Capital One Services, Llc | Systems and methods for data access control using a short-range transceiver |
US11823175B2 (en) | 2020-04-30 | 2023-11-21 | Capital One Services, Llc | Intelligent card unlock |
US11222342B2 (en) | 2020-04-30 | 2022-01-11 | Capital One Services, Llc | Accurate images in graphical user interfaces to enable data transfer |
US11270291B2 (en) | 2020-04-30 | 2022-03-08 | Capital One Services, Llc | Systems and methods for data access control using a short-range transceiver |
US10963865B1 (en) | 2020-05-12 | 2021-03-30 | Capital One Services, Llc | Augmented reality card activation experience |
US11100511B1 (en) | 2020-05-18 | 2021-08-24 | Capital One Services, Llc | Application-based point of sale system in mobile operating systems |
US11063979B1 (en) | 2020-05-18 | 2021-07-13 | Capital One Services, Llc | Enabling communications between applications in a mobile operating system |
US11216623B1 (en) | 2020-08-05 | 2022-01-04 | Capital One Services, Llc | Systems and methods for controlling secured data transfer via URLs |
US11822994B2 (en) | 2020-08-05 | 2023-11-21 | Capital One Services, Llc | Systems and methods for controlling secured data transfer via URLs |
US11683325B2 (en) | 2020-08-11 | 2023-06-20 | Capital One Services, Llc | Systems and methods for verified messaging via short-range transceiver |
US11062098B1 (en) | 2020-08-11 | 2021-07-13 | Capital One Services, Llc | Augmented reality information display and interaction via NFC based authentication |
US11482312B2 (en) | 2020-10-30 | 2022-10-25 | Capital One Services, Llc | Secure verification of medical status using a contactless card |
US11165586B1 (en) | 2020-10-30 | 2021-11-02 | Capital One Services, Llc | Call center web-based authentication using a contactless card |
US11373169B2 (en) | 2020-11-03 | 2022-06-28 | Capital One Services, Llc | Web-based activation of contactless cards |
US11216799B1 (en) | 2021-01-04 | 2022-01-04 | Capital One Services, Llc | Secure generation of one-time passcodes using a contactless card |
US11682012B2 (en) | 2021-01-27 | 2023-06-20 | Capital One Services, Llc | Contactless delivery systems and methods |
US11562358B2 (en) | 2021-01-28 | 2023-01-24 | Capital One Services, Llc | Systems and methods for near field contactless card communication and cryptographic authentication |
US11792001B2 (en) | 2021-01-28 | 2023-10-17 | Capital One Services, Llc | Systems and methods for secure reprovisioning |
US11687930B2 (en) | 2021-01-28 | 2023-06-27 | Capital One Services, Llc | Systems and methods for authentication of access tokens |
US11438329B2 (en) | 2021-01-29 | 2022-09-06 | Capital One Services, Llc | Systems and methods for authenticated peer-to-peer data transfer using resource locators |
US11777933B2 (en) | 2021-02-03 | 2023-10-03 | Capital One Services, Llc | URL-based authentication for payment cards |
US11637826B2 (en) | 2021-02-24 | 2023-04-25 | Capital One Services, Llc | Establishing authentication persistence |
US11245438B1 (en) | 2021-03-26 | 2022-02-08 | Capital One Services, Llc | Network-enabled smart apparatus and systems and methods for activating and provisioning same |
US20220311475A1 (en) | 2021-03-26 | 2022-09-29 | Capital One Services, Llc | Network-enabled smart apparatus and systems and methods for activating and provisioning same |
US11848724B2 (en) | 2021-03-26 | 2023-12-19 | Capital One Services, Llc | Network-enabled smart apparatus and systems and methods for activating and provisioning same |
US11902442B2 (en) | 2021-04-22 | 2024-02-13 | Capital One Services, Llc | Secure management of accounts on display devices using a contactless card |
US11354555B1 (en) | 2021-05-04 | 2022-06-07 | Capital One Services, Llc | Methods, mediums, and systems for applying a display to a transaction card |
US11924188B2 (en) | 2022-02-23 | 2024-03-05 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US11922417B2 (en) | 2022-12-06 | 2024-03-05 | Capital One Services, Llc | Systems and methods for near field contactless card communication and cryptographic authentication |
Also Published As
Publication number | Publication date |
---|---|
US20050184164A1 (en) | 2005-08-25 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7165727B2 (en) | Method and apparatus for installing an application onto a smart card | |
US7140549B2 (en) | Method and apparatus for selecting a desired application on a smart card | |
US7374099B2 (en) | Method and apparatus for processing an application identifier from a smart card | |
US7191288B2 (en) | Method and apparatus for providing an application on a smart card | |
US6808111B2 (en) | Terminal software architecture for use with smart cards | |
US7232073B1 (en) | Smart card with multiple applications | |
US9400668B2 (en) | Computer program product containing instructions for providing a processor the capability of executing an application derived from a compiled form | |
EP1575005B1 (en) | Method and apparatus for processing an application identifier from a smart card | |
CA2466650A1 (en) | Data exchange system comprising portable data processing units | |
US7340748B2 (en) | Automatic client proxy configuration for portable services | |
KR100971126B1 (en) | System for Operating Card | |
KR101013162B1 (en) | System for Relaying Application and Service Code for Card with ICC and MS | |
KR101124262B1 (en) | Method for Creating and Relaying Application and Service Code for Card with ICC and MS | |
Guo | Smart Cards and their Operating Systems | |
Ma et al. | Implementing FISC IC card specification and developing health care application using Java Card | |
dong Koul et al. | 5 Smart Cards and Applications | |
Jang | Secure Object Sharing on Java Card | |
Paavilainen | Java based smart cards | |
Sachdeva | Smart Card Operating Systems: Past, Present and Future | |
KR20080014913A (en) | Card terminal device | |
KR20080014914A (en) | Ic chip | |
KR20040066393A (en) | Network Card of Smart Card Type, System and Method for Operating Network Card by It | |
MXPA99003796A (en) | Using a high level programming language with a microcontroller |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: SUN MICROSYSTEMS, INC., CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:DE JONG, EDUARD K.;REEL/FRAME:015025/0780 Effective date: 20040220 |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
FPAY | Fee payment |
Year of fee payment: 4 |
|
FPAY | Fee payment |
Year of fee payment: 8 |
|
AS | Assignment |
Owner name: ORACLE AMERICA, INC., CALIFORNIA Free format text: MERGER AND CHANGE OF NAME;ASSIGNORS:ORACLE USA, INC.;SUN MICROSYSTEMS, INC.;ORACLE AMERICA, INC.;REEL/FRAME:037302/0683 Effective date: 20100212 |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 12TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1553) Year of fee payment: 12 |