+

US20070033291A1 - System and method for support of legacy communications protocols in a smart card - Google Patents

System and method for support of legacy communications protocols in a smart card Download PDF

Info

Publication number
US20070033291A1
US20070033291A1 US11/199,690 US19969005A US2007033291A1 US 20070033291 A1 US20070033291 A1 US 20070033291A1 US 19969005 A US19969005 A US 19969005A US 2007033291 A1 US2007033291 A1 US 2007033291A1
Authority
US
United States
Prior art keywords
annotations
protocol
apdu
message
program
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.)
Abandoned
Application number
US11/199,690
Other languages
English (en)
Inventor
Sylvain Prevost
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Axalto Inc
Original Assignee
Axalto Inc
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Priority claimed from US11/188,065 external-priority patent/US20070033248A1/en
Application filed by Axalto Inc filed Critical Axalto Inc
Priority to US11/199,690 priority Critical patent/US20070033291A1/en
Assigned to AXALTO INC. reassignment AXALTO INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: PREVOST, SYLVAIN
Priority to EP06765640A priority patent/EP1908252A1/fr
Priority to US11/996,265 priority patent/US8799932B2/en
Priority to PCT/IB2006/002010 priority patent/WO2007010380A1/fr
Publication of US20070033291A1 publication Critical patent/US20070033291A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/541—Interprogram communication via adapters, e.g. between incompatible applications
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/547—Remote procedure calls [RPC]; Web services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/547—Remote procedure calls [RPC]; Web services
    • G06F9/548—Object oriented; Remote method invocation [RMI]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/133—Protocols for remote procedure calls [RPC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/08—Protocols for interworking; Protocol conversion

Definitions

  • the present invention relates generally to remote access of methods on a smart card, and more particularly to the support of a legacy communications model for remote access of methods on a smart card.
  • Smart cards are small personal computing devices that are used to protect very sensitive information. Smart cards may be used to perform banking functions, provide access to health records, personalization of computer network access, secure building access, and many more functions. Smart cards are also used as subscriber identity modules (SIM) in certain mobile telephony networks.
  • SIM subscriber identity modules
  • smart cards Although they are small computers, smart cards lack input and output devices as well as power supply. Therefore, access to data and programs stored in a smart card has to be obtained through another computer to which the smart card is connected. Typically a smart card is inserted into a smart card reader attached to a host computer for input and output functions as well as power.
  • the smart card and host computer operate according to a server-client model in which client programs execute on the host computer and server programs execute on the smart card.
  • the host computer client programs call upon the smart card server programs to provide some data or other functionality provided by the smart card.
  • the dominant standard for smart cards has been the ISO-7816 standard.
  • communication between smart cards and host computers use a communication packet called an APDU (Application Program Data Unit)
  • APDU Application Program Data Unit
  • smart cards were very small and had very limited computing power. Therefore, the APDU format was geared towards efficient and compact communication suitable for very small and not very powerful processors.
  • RPC Remote Procedure Call
  • FIG. 1 is a schematic illustration of an example of an operating environment for a smart card, in particular illustrating an example in which a smart card is connected to a host computer by being inserted into a terminal.
  • FIG. 2 is a schematic illustration of an exemplary architecture of a smart card processor.
  • FIG. 3 is a block diagram of an exemplary software architecture that one may find implemented on a smart card.
  • FIG. 4 is a block diagram illustrating message flow between a client program executing on the host computer and a server program executing on a smart card.
  • FIG. 5 is a block diagram illustrating the development cycle of the client program and the server program.
  • FIG. 6 is a schematic illustration of the structure of an RPC method invocation.
  • FIG. 7 is a flow-chart illustrating the processing, according to the invention, of an incoming remote message from a client program to be processed by the smart card.
  • FIG. 8 is a block diagram illustrating the structure of an APDU message.
  • FIG. 9 is a flow-chart illustrating one embodiment of a converter to process a source file to construct a mapping table.
  • FIG. 10 is a flow-chart illustrating in detail the steps of FIG. 9 of building an APDU mapping entry structure from the APDU annotation, the APDUParam annotation if any, and the APDUExceptions annotation if any.
  • FIG. 11 is a flow-chart illustrating one embodiment of the transformation of an APDU message into an RPC message.
  • the invention is embodied in a system and method for providing support for legacy communications protocols in a smart card system that support a modern communications protocol.
  • the invention is embodied in a system and method for providing support for the APDU protocol in a smart card system that uses the RPC communications model as its native communications model.
  • FIG. 1 is a schematic illustration of an example of an operating environment for a smart card, in particular illustrating an example in which a smart card 101 is connected to a host computer 103 by being inserted into a terminal 105 .
  • the terminal 105 has a communications connector 107 that may be placed in electrical contact with a corresponding communications connector 109 on the smart card 101 .
  • the terminal 105 and the smart card 101 may communicate in a contactless fashion.
  • FIG. 1 only shows the visible components of the smart card 101 , in particular the contact pad 109 .
  • a smart card 101 also contains several hidden components, notably a processor that is electrically connected to the contact pad 109 .
  • FIG. 2 is a schematic illustration of an exemplary architecture of a smart card processor 201 .
  • the smart card processor 201 has a central processing unit 203 , a read-only memory (ROM) 205 , a random access memory (RAM) 207 , a non-volatile memory (NVM) 209 , and a communications interface 211 for receiving input and placing output to a device, e.g., the terminal 105 and the host computer 103 , to which the smart card processor 201 is connected.
  • a device e.g., the terminal 105 and the host computer 103
  • the on-card software used to implement the methods described herein may be stored on the smart card 203 in the ROM 205 .
  • the CPU 203 operates according to instructions in the various software modules stored in the ROM 205 .
  • FIG. 3 is a block diagram of an exemplary software architecture 300 that one may find implemented on a smart card 101 .
  • the software architecture 300 includes several application programs 301 , e.g., application programs 301 , 301 ′, and 301 ′′. These are loaded onto the smart card by a loader 303 .
  • the application programs 301 would typically be loaded into the non-volatile memory 209 . However, in other scenarios an application program may be permanently written onto the smart card at manufacture by having it stored in the ROM 205 .
  • the application programs 301 are compiled into executable code.
  • the job control is managed by an operating system program 305 .
  • FIG. 4 is a block diagram illustrating message flow between a client program 403 executing on the host computer 103 and a server program 401 executing on a smart card 101 .
  • the client program 403 may issue a message 405 on an object, function or other data structure of the server program 401 .
  • the server program 401 may respond by sending a message 405 back to the client program 403 .
  • the message traffic between the server program 401 and the client program 403 may be either in a native communications protocol or in a legacy protocol. If the messages are transmitted using the legacy protocol, a communications module on the smart card transforms the incoming messages into a native protocol prior to dispatching the message to the server program 401 . This transformation is discussed in greater detail herein below.
  • FIG. 5 is a block diagram illustrating the development cycle of the client program 403 and the server program 401 .
  • modern application programs for smart cards are developed using special versions of high-level languages, e.g., Java or the programming languages supported by .Net from Microsoft Corporation.
  • the smart card versions of these programming languages are generally subsets of the full-fledged versions used to program conventional computers. Because the smart card versions are proper subsets of the full-languages, generally programs developed for smart cards using the high-level languages are compiled as conventional programs using a standard compiler 502 designed for that language. However, to ensure that the smart card programs execute correctly on a smart card, the programs also undergo a conversion step performed by a converter 503 .
  • the server program 401 is first written in a high-level language as one or more high-level language source files 501 .
  • These source files 501 are compiled and converted using a compiler 502 and converter 503 , respectively.
  • the compiler 502 and converter 503 produce the executable image of the server program 401 and a server stub file 505 , e.g., a .dll.
  • the compilation and conversion steps typically occur on a development computer 504 for subsequent distribution and loading onto smart cards.
  • the converter resides on the smart card and the conversion step is performed on the smart card.
  • the server program 401 is loaded onto the smart card 101 , step 507 .
  • the loader program 303 may perform the loading step 507 .
  • the client program 403 development path is similar. However, because the client program 403 does not execute on the smart card 101 , the client program 403 does not under go a conversion step.
  • the client program 403 like the server program 401 , is written in a high-level language into one or more client source files 509 . These source files 509 are compiled using a high-level language compiler 511 .
  • the server program 403 calls upon functionality in the server program 401 . To be able to do that, the client source files 509 are compiled against the server program 401 using the server stub file 505 .
  • the compiler produces the executable file of the client program 403 .
  • the compilation process may occur on a development machine 513 for subsequent installation, step 515 , onto the host computer 103 .
  • communication between the client program 403 and the server program 401 may be either in a native communications protocol or using a legacy communications protocol.
  • the development, compilation and conversion process according to the invention make the alternative of communicating in a legacy protocol possible.
  • the details of the development, compilation, and conversion process that enable the use of legacy communication protocols are described herein below. However, first we describe some of the mechanics of client-to-server communication between a host 103 and a smart card 101 .
  • the client and server programs are both developed using the .Net programming system (ECMA 335 standard).
  • the smart card 101 is a smart card developed to support programs developed using the .Net system. Such smart cards may be referred to as “.Net cards”.
  • the client and server programs are developed using the JAVA programming language.
  • the smart card 101 is a smart card developed to support programs developed using the JAVA programming language. Such cards are typically referred to as Java Card smart cards.
  • the .Net embodiment is explained for purposes of providing an example. The techniques described are also applicable the Java embodiment and alternative embodiments featuring other programming languages and systems.
  • Communications from the client-host program 403 to the on-card server 401 requires that the client program 403 has been compiled against an interface for the server program 401 .
  • the interface which is found in the server stub file 505 , is created using public methods prototypes of the .Net system and extend to the server class System.MarshalByRefObject.
  • Table I is a code snippet of an exemplary Server class (which may be compiled into the server program 401 .
  • TABLE 1 Server Code Example public class Server MarshalByRefObject ⁇ public void method1( ) ⁇ ... ⁇ public byte[ ] method2(int input) ⁇ ... ⁇ private int method3( ) ⁇ ... ⁇ ⁇
  • Table 2 is a code example illustrating how a client program 401 may invoke these methods: TABLE 2 Example client code invoking methods of a server program.
  • An instance represents the set of data on which the code logic must be applied.
  • MyMotherCodeInstance and MyFatherCodeInstance are two instances of the same code, and represent two different sets of data (one contains “myMotherName” and the other one contains “myFatherName”) on which the code logic defined by the “MyCode” type will apply.
  • client and server are instances of a client code and server code.
  • client program 403 is more accurately an instance of the client code
  • server program 401 is more accurately an instance of the server program.
  • a unique name is associated with each server instance.
  • the server instance name is also called a URI (Uniform Resource Identifier).
  • a URL Uniform Resource Locator
  • a URL describes fully the location of an instance on a particular computer (or other node).
  • a server URL contains the URI for the server instance. For example, in the URL http://123.456.789.455/folder1/TheServerOfMyFather the server instance name, i.e., the URI is TheSeruerOfMyFather and http://123.456.789/folder1 describes the location of that instance, i.e., it is the universal address of the instance.
  • the server instance name is linked to a class.
  • the communication between the client and the server may be either in the native communications protocol supported by the smart card or in a legacy protocol.
  • the mechanism that supports such support of legacy protocol communication relies on certain transformations performed in-part by the converter 503 and in-part by on-card logic supporting the legacy protocol.
  • One aspect of the mechanism to support legacy protocol is a mapping table 517 produced by the converter 503 . The structure, generation and use of the mapping table 517 are described herein below.
  • the native communications protocol is the Remote Procedure Call (RPC) communications protocol.
  • RPC Remote Procedure Call
  • the legacy protocol supported by that embodiment of the invention is the ISO-7816 APDU protocol.
  • ISO-7816 APDU is described in ISO7816-3 & ISO7816-4 specifications, the entire disclosure of which is incorporated herein by reference.
  • FIG. 6 is a schematic illustration of the structure of an RPC method invocation according to the invention.
  • An RPC method invocation consists of four components: a Server Reference Name 601 , a Class Name 603 , a Method Name 605 , and a Method Payload 607 . The first three of these form a Header 609 .
  • a given Server Reference Name (also called Instance Name) may not be card unique.
  • Class Name is used to uniquely identify the instance named “TheServerOfMyFather” whose underlying code logic is the “Server” class.
  • FIG. 7 is a flow-chart illustrating the processing of an incoming remote message 701 from a client program 403 to be processed by the smart card 101 .
  • the details of the processing of a remote message are discussed in greater detail herein below.
  • a communications layer 703 which is implemented as a systems function of the smart card 101 and stored in memory of the smart card processor 201 , e.g., in the ROM 205 or the NVM 209 , transforms the remote message 701 from a legacy protocol format to a native protocol format.
  • the legacy protocol supported by the smart card 101 is the ISO-7816 APDU protocol.
  • FIG. 8 is a block diagram illustrating the structure of an APDU message.
  • the APDU protocol consists of a four byte header 801 having the fields CLA 803 , INS 805 , P 1 807 and P 2 809 , a 1 byte payload length field P 3 811 , and a variable length payload field DATA 813 .
  • the client program 403 would initiate communication using the Select APDU command.
  • the Select APDU command directs the card to internally activate an instance, and to direct all subsequent APDU commands to the code associated with that instance.
  • the client program 403 may issue the commands: TABLE 6 Code for selecting an instance using the Select APDU header and code for invoking a function.
  • payload length 07 2/ debit operation of amount 0x54477 A08012340400054477
  • Debit payload: 00054477 P3: payload length 04
  • the APDU header 00A40400 is the instruction corresponding to the Select APDU command.
  • the CLA is 00
  • the INS is A4
  • the first parameter (P 1 ) is 04
  • the second parameter (P 2 ) is 00.
  • the client program includes a debit function to perform a debit operation on the selected instance.
  • the debit operation header CLA is A0
  • the INS is 80
  • the P 1 is 12, and the P 2 is 34.
  • the card Having received the Select APDU command, the card activates the A00000000003 instance (it could be linked to a particular account for example), and the card also becomes aware of the code that is associated with the instance name, e.g., the debit operation. Unlike in RPC mode, to a given instance name, a unique code logic can be associated. Therefore, the instance name must be a card unique feature.
  • mapping table between RPC method names and APDU headers is constructed at the conversion stage 503 .
  • This mapping table is constructed from annotations embedded in the server source files 501 . Annotations have the advantage that they do not modify the code logic while they provide a means to give extra information related to the code being annotated.
  • the converter 503 is operable to detect annotations relating to the transformation of APDU headers into RPC procedure calls.
  • the line “[APDU(“A0801234”)]” is an annotation.
  • the converter 503 can determine that the method1 method, i.e., the method having the name method1, corresponds to an APDU header “A0801234”.
  • annotations may be, as in the examples herein. Net attributes.
  • the examples herein may be readily adapted to the JAVA programming language by using Java annotations to implement the annotations rather than .Net attributes. Similar modifications may be available for other programming languages.
  • the APDU annotation may have up to four parameters:
  • the server source files 501 may also be annotated with one or two additional annotations, namely, the APDUParam annotation and the APDUException annotation.
  • the APDUParam annotation provides information to the communications layer 703 to replace a parameter value in an RPC call with a corresponding header value.
  • the APDUParam annotation directs the communications layer 703 to set the content of the second parameter (“param2”) to the value of the INS field in the APDU header.
  • the INS field 805 is the second byte of the APDU header. Consequently, in this example, the second parameter will be set to 40.
  • the APDUException annotation is used along side the [APDU] annotation to notify the communications layer 703 what status word to return upon abnormal execution of a method, i.e., a method exited via an exception.
  • the APDUException annotation directs the communications layer 703 to return 0x8888 if the method is exited with a FileNotFoundException (conversely, 0x6880 would be the return status upon normal execution).
  • mapping table 517 which maps APDU headers to RPC method names, provides information on parameter handling, and on exception handling.
  • the mapping table 517 may, for example, have the following structure:
  • FIG. 9 is a flow-chart illustrating one embodiment of the converter 503 to process a source file to construct a mapping table.
  • the processing may be on a line-by-line basis. Therefore, initially the process positions itself to read from the beginning of a source file to be processed, step 901 .
  • the mapping table 517 contains an entry with the total number of APDU Mapping Entries to be found in the table. Therefore, a counter is maintained and initialized to 0, step 903 .
  • step 905 the current line of the program source file is processed, step 911 .
  • the converter 503 performs many other processing steps. These steps may be performed in this step 911 . If the line contains an APDU annotation, step 913 , the annotation is parsed and added to the mapping table 517 , step 915 , and the counter incremented, step 917 . Step 915 is discussed in greater detail herein below in conjunction with FIG. 10 .
  • step 905 ends when the end-of-file has been encountered, step 905 , in which case the count of APDUEntries may be written to the mapping table 517 , step 907 , the mapping table is appended to the executable file, step 909 , and the process stopped, step 921 .
  • FIG. 10 is a flow-chart illustrating in detail the step 915 of FIG. 9 , i.e., the steps of building an APDU mapping entry structure from the APDU annotation, the APDUParam annotation if any, and the APDUExceptions annotation, if any.
  • Step 971 The APDU annotation contains the APDU Header and the APDU mask.
  • the first four bytes of the mapping table 517 entry would be “50401122”.
  • Step 973 if an APDU mask parameter has been provided, store it into the mapping table.
  • the APDU mask is used by the card to determine if an incoming APDU is within the range [APDU]-[APDU OR APDUMask]).
  • Step 975 When an APDU annotation has been encountered, the corresponding Method Name must be determined by looking forward to determine the method name. This task may be performed by scanning forward to find the next method name using the rules of the grammar for the high-level language being processed. The method name is then encoded, in this example, as a two byte string.
  • Step 977 The transfer direction is determined from the method prototype and recorded as one byte. If the method does not receive not return any data, then it is said to be Case1:
  • the Case notation is explained in ISO7816 specification.
  • the transfer-direction consists of the value: 1, 2, 3 or 4 indicating which Case applies.
  • Step 979 The APDU annotation may contain a field called “statusWord”. If so, record the value. E.g., in the example of Table 9, the statusWord value to be recorded is 6880. If there is no entry, record a default value. The quantity is recorded as 2 bytes.
  • Step 981 The APDU annotation may contain a field called “OnInvalidLe”. If so, record the value. E.g., in the example of Table 9, the OnInvalidLe value is “reject”. If there is no entry, record a default value. The quantity is recorded as 1 byte.
  • Step 983 Next determine and record the number of parameters. This is determined from the method prototype. For example:
  • Step 985 Next determine and record the remapping of the parameter list. This remapping is determined from the [APDUParam] annotation. There is one byte entry for each parameter, as determined in step 983 . If a parameter is not remapped, the entry is 0.
  • Step 987 The APDU annotation may be followed by one or more APDUException annotations.
  • Step 987 the number of APDUException annotations that follow the APDU annotation is determined and recorded.
  • Step 989 The APDU Exception annotation contains a mapping of exception type and status value to return upon encountering such an exception. Each such mapping will be determined and recorded.
  • mapping table 517 has been produced and appended to the executable file 401 of the server program.
  • the converter 503 contains logic operable to perform the process described in conjunction with and illustrated in FIGS. 9 and 10 .
  • FIG. 7 is a block diagram illustrating the components involved in processing an incoming message on the smart card 101 .
  • the smart card 101 contains a communications layer 703 for receiving a remote message 701 from a client 403 .
  • the remote message 701 may be either in a native communications protocol, e.g., in the preferred embodiment, in the RPC protocol, or it may be in a non-native legacy protocol, e.g., in the preferred embodiment, in the ISO-7816 APDU protocol.
  • the communications layer 703 consists of a native layer 705 and a legacy layer 707 .
  • the communications layer 703 determines, in the decision logic 706 , whether the remote message 701 is a legacy protocol message or a native protocol message,. If the remote message 701 is a legacy protocol message, the remote message 701 is passed to the legacy layer 707 for translation from the legacy protocol to the native protocol. However, if the remote message 701 is a native protocol message, the remote message 701 is passed directly to the native layer 705 for processing.
  • the message may be passed directly to the run time module 709 .
  • the run time module 709 provides a marshalling function that will prepare the method call accordingly to the runtime environment (set-up call instruction, push parameter values onto the stack, etc.)
  • the message once prepared accordingly to the runtime environment format, is transmitted to the server executable module 401 for processing.
  • the legacy layer 707 translates the message into a native protocol message. All valid legacy protocol messages would have been entered into the mapping table 517 generated during the compilation and conversion process that created the executable for the server program. Thus, the legacy layer 707 looks up the entry in the mapping table 517 .
  • the process of building an RPC call from an APDU message is largely the reverse process of the process to build the mapping table 517 of FIGS. 9 and 10 .
  • FIG. 11 is a flow-chart illustrating one embodiment of the transformation of an APDU message into an RPC message.
  • the APDUSelect command If the incoming message is an APDUSelect command, step 111 , then the communications layer 703 stores the server instance name specified in the APDUSelect command, step 113 . That is all the processing necessary for an APDUSelect command. Thus, the process can stop there, step 115 .
  • the APDU command is a call to a method of the server 401 , the APDU command is translated into an RPC message that can be passed on to the run time layer 709 .
  • mapping table 517 entry corresponding to the received APDU header is retrieved from the mapping table 517 , step 117 .
  • the mapping table entry and the received message 701 contain all the information necessary to produce an RPC method invocation.
  • the first item in an RPC method invocation is the Server Reference Name 601 .
  • the server reference name 601 was saved in step 113 when processing an APDUSelect command.
  • the RPC method invocation has a Class Name field 603 . Accordingly, the class of the server instance is determined, step 119 . Since there is a one-to-one relation between the server instance name and the class name when the APDU legacy protocol is used, the Class name is implicitly known by the system via the server instance name (using an internal system lookup).
  • the complete RPC method invocation may be built, step 121 . It consists of the server instance name, the class name, the method name (which was retrieved from the mapping table in step 117 ) and the method payload.
  • the method payload is received from the APDU message 701 as fields P 3 811 and DATA 813 .
  • parameters remapping is performed using the information present in the mapping table entry and finally the method is invoked and processed by the server target instance 401 .
  • nominal status word and exception status words or behavior upon invalid ISO7816 GetResponse length can be determined using the remaining information present in the mapping table entry.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer And Data Communications (AREA)
  • Stored Programmes (AREA)
US11/199,690 2005-07-22 2005-08-09 System and method for support of legacy communications protocols in a smart card Abandoned US20070033291A1 (en)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US11/199,690 US20070033291A1 (en) 2005-07-22 2005-08-09 System and method for support of legacy communications protocols in a smart card
EP06765640A EP1908252A1 (fr) 2005-07-22 2006-07-21 Systeme et procede pour la prise en charge de protocoles de communications classiques dans une carte intelligente
US11/996,265 US8799932B2 (en) 2005-07-22 2006-07-21 System and method for support of legacy communications protocols in a smart card
PCT/IB2006/002010 WO2007010380A1 (fr) 2005-07-22 2006-07-21 Systeme et procede pour la prise en charge de protocoles de communications classiques dans une carte intelligente

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US11/188,065 US20070033248A1 (en) 2005-07-22 2005-07-22 System and method for support of legacy communications protocols in a smart card
US11/199,690 US20070033291A1 (en) 2005-07-22 2005-08-09 System and method for support of legacy communications protocols in a smart card

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US11/188,065 Continuation-In-Part US20070033248A1 (en) 2005-07-22 2005-07-22 System and method for support of legacy communications protocols in a smart card

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US11/188,065 Continuation US20070033248A1 (en) 2005-07-22 2005-07-22 System and method for support of legacy communications protocols in a smart card

Publications (1)

Publication Number Publication Date
US20070033291A1 true US20070033291A1 (en) 2007-02-08

Family

ID=37054437

Family Applications (2)

Application Number Title Priority Date Filing Date
US11/199,690 Abandoned US20070033291A1 (en) 2005-07-22 2005-08-09 System and method for support of legacy communications protocols in a smart card
US11/996,265 Expired - Fee Related US8799932B2 (en) 2005-07-22 2006-07-21 System and method for support of legacy communications protocols in a smart card

Family Applications After (1)

Application Number Title Priority Date Filing Date
US11/996,265 Expired - Fee Related US8799932B2 (en) 2005-07-22 2006-07-21 System and method for support of legacy communications protocols in a smart card

Country Status (3)

Country Link
US (2) US20070033291A1 (fr)
EP (1) EP1908252A1 (fr)
WO (1) WO2007010380A1 (fr)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090249373A1 (en) * 2008-04-01 2009-10-01 Feitian Technologies Co., Ltd. Method for program protection based on .net card and a system thereof
US20100030846A1 (en) * 2006-07-28 2010-02-04 Gemalto Sa Method of synchronization between a mobile equipment unit and a smart card
US20140059108A1 (en) * 2012-08-27 2014-02-27 Microsoft Corporation Unified communication interface for distributed computing
US9128789B1 (en) * 2012-07-31 2015-09-08 Google Inc. Executing cross-cutting concerns for client-server remote procedure calls
US10623393B1 (en) 2018-10-02 2020-04-14 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5197664B2 (ja) * 2010-03-18 2013-05-15 株式会社東芝 Ｉｃカード、通信装置、コマンド処理方法、通信システム
US9225809B1 (en) 2011-08-04 2015-12-29 Wyse Technology L.L.C. Client-server communication via port forward
US8898769B2 (en) 2012-11-16 2014-11-25 At&T Intellectual Property I, Lp Methods for provisioning universal integrated circuit cards
US8959331B2 (en) 2012-11-19 2015-02-17 At&T Intellectual Property I, Lp Systems for provisioning universal integrated circuit cards
US9036820B2 (en) 2013-09-11 2015-05-19 At&T Intellectual Property I, Lp System and methods for UICC-based secure communication
US9124573B2 (en) 2013-10-04 2015-09-01 At&T Intellectual Property I, Lp Apparatus and method for managing use of secure tokens
US9208300B2 (en) 2013-10-23 2015-12-08 At&T Intellectual Property I, Lp Apparatus and method for secure authentication of a communication device
US9240994B2 (en) 2013-10-28 2016-01-19 At&T Intellectual Property I, Lp Apparatus and method for securely managing the accessibility to content and applications
US9313660B2 (en) 2013-11-01 2016-04-12 At&T Intellectual Property I, Lp Apparatus and method for secure provisioning of a communication device
US9240989B2 (en) 2013-11-01 2016-01-19 At&T Intellectual Property I, Lp Apparatus and method for secure over the air programming of a communication device
US9197717B2 (en) 2013-11-27 2015-11-24 At&T Intellectual Property I, Lp Server-side scheduling for media transmissions according to client device states
US9413759B2 (en) 2013-11-27 2016-08-09 At&T Intellectual Property I, Lp Apparatus and method for secure delivery of data from a communication device
US9713006B2 (en) 2014-05-01 2017-07-18 At&T Intellectual Property I, Lp Apparatus and method for managing security domains for a universal integrated circuit card

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020082847A1 (en) * 2000-12-21 2002-06-27 Jean-Jacques Vandewalle Automatic client proxy configuration for portable services
US7493605B2 (en) * 2004-12-29 2009-02-17 Mainsoft R&D Ltd Method and a software product for adapting a .Net framework compliant reflection mechanism to a java environment

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6253370B1 (en) * 1997-12-01 2001-06-26 Compaq Computer Corporation Method and apparatus for annotating a computer program to facilitate subsequent processing of the program
US6611817B1 (en) 1999-06-17 2003-08-26 International Business Machines Corporation Automated technique for code generation of datastream mappings
FR2803706B1 (fr) 1999-09-27 2002-03-08 Bull Cp8 Procede et architecture de pilotage a distance d'une station d'utilisateur via un reseau de type internet et leur application a un demonstrateur de carte a puce
US6807561B2 (en) * 2000-12-21 2004-10-19 Gemplus Generic communication filters for distributed applications
US7155705B1 (en) * 2001-11-26 2006-12-26 Cisco Technology, Inc. Techniques for binding an application with a data exchange format based on tags in comments
FR2846770B1 (fr) * 2002-11-04 2005-01-28 Oberthur Card Syst Sa Carte a microcircuit comportant des moyens de publication de ses objets informatiques
US7484095B2 (en) * 2003-01-16 2009-01-27 Sun Microsystems, Inc. System for communicating program data between a first device and a second device
US7281237B2 (en) * 2003-01-16 2007-10-09 Sun Microsystems, Inc. Run-time verification of annotated software code
US7519713B2 (en) * 2005-02-04 2009-04-14 Microsoft Corporation Mapping between object oriented and service oriented representations of a distributed application

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020082847A1 (en) * 2000-12-21 2002-06-27 Jean-Jacques Vandewalle Automatic client proxy configuration for portable services
US7493605B2 (en) * 2004-12-29 2009-02-17 Mainsoft R&D Ltd Method and a software product for adapting a .Net framework compliant reflection mechanism to a java environment

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100030846A1 (en) * 2006-07-28 2010-02-04 Gemalto Sa Method of synchronization between a mobile equipment unit and a smart card
US20090249373A1 (en) * 2008-04-01 2009-10-01 Feitian Technologies Co., Ltd. Method for program protection based on .net card and a system thereof
US8528008B2 (en) * 2008-04-01 2013-09-03 Feitian Technologies Co., Ltd. Method for program protection based on .NET card and a system thereof
US9128789B1 (en) * 2012-07-31 2015-09-08 Google Inc. Executing cross-cutting concerns for client-server remote procedure calls
US9723107B1 (en) 2012-07-31 2017-08-01 Niantic, Inc. Executing cross-cutting concerns for client-server remote procedure calls
US20140059108A1 (en) * 2012-08-27 2014-02-27 Microsoft Corporation Unified communication interface for distributed computing
US10623393B1 (en) 2018-10-02 2020-04-14 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US11297046B2 (en) 2018-10-02 2022-04-05 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US11924188B2 (en) 2018-10-02 2024-03-05 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards

Also Published As

Publication number Publication date
US20080222665A1 (en) 2008-09-11
WO2007010380A1 (fr) 2007-01-25
EP1908252A1 (fr) 2008-04-09
US8799932B2 (en) 2014-08-05

Similar Documents

Publication Publication Date Title
US8799932B2 (en) System and method for support of legacy communications protocols in a smart card
US6807561B2 (en) Generic communication filters for distributed applications
US7962925B2 (en) System and method for XML data binding
US7730499B2 (en) Protocol agnostic request response pattern
US6571388B1 (en) Building a custom software environment including pre-loaded classes
CN100476721C (zh) 提供模块化本机方法启用系统的方法、和装置和系统
US7240101B2 (en) Method and apparatus for efficiently reflecting complex systems of objects in XML documents
US20070168402A1 (en) System and method for pluggable url pattern matching for servlets and application servers
US20040103407A1 (en) Optimizing client code through automated server specialization
JPH11505947A (ja) スマートｉｃカードシステム
CN111176791A (zh) 一种基于多虚拟机区块链平台跨虚拟机调用方法
US7340748B2 (en) Automatic client proxy configuration for portable services
US11397626B2 (en) Accessing web applications
EP1678629A2 (fr) Cadre extensible pour exploitations de differents analyseurs et generatrices de langues de balisage dans un dispositif informatique
US20040154027A1 (en) Method and means for managing communications between local and remote objects in an object oriented client server system in which a client application invokes a local object as a proxy for a remote object on the server
CN113434147B (zh) 基于ProtoBuf协议的消息解析方法及装置
CN102388363A (zh) 以类别档案嵌入原生代码方式应用平台相依例行程序于虚拟机
CN110414651A (zh) 调试智能卡的方法及装置
US8112500B2 (en) Technique of relaying communications between client apparatus and server apparatus
KR100374526B1 (ko) 스마트 카드 및 그를 이용한 컴퓨터 프로그램 동작 방법
US20070033248A1 (en) System and method for support of legacy communications protocols in a smart card
CN101425120B (zh) 读卡器及其执行方法
US8881099B2 (en) Dynamic generation of wrapper classes to implement call-by-value semantics
US7246355B1 (en) Device and method for initializing an applicative programme of an integrated circuit card
US20190102230A1 (en) Managing split packages in a module system

Legal Events

Date Code Title Description
AS Assignment

Owner name: AXALTO INC., TEXAS

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:PREVOST, SYLVAIN;REEL/FRAME:016874/0623

Effective date: 20050722

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION

点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载