Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
The IDS filed 8/14/2024 was received and considered.
Claims 1-5 are pending.
Drawings
New corrected drawings in compliance with 37 CFR 1.121(d) are required in this application because small text in Figs. 2-3 is difficult to read, presumably related to conversion. Applicant is advised to employ the services of a competent patent draftsperson outside the Office, as the U.S. Patent and Trademark Office no longer prepares new drawings. The corrected drawings are required in reply to the Office action to avoid abandonment of the application. The requirement for corrected drawings will not be held in abeyance.
Claim Objections
Claims 1-5 are objected to because of the following informalities: In claim 1, “each of the card and the host provide of an SCP key identity” should be replaced with “each of the card and the host provide an SCP key identity”. Claims 2-5 inherit the deficiency. Appropriate correction is required.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-5 are rejected under 35 U.S.C. 103 as being unpatentable over “GlobalPlatform Technology Secure Channel Protocol '04' Card Specification v2.3 – Amendment K Version 0.0.0.24” (GlobalPlatform), in view of JP 2018082246 A (referencing provided machine translation) to Naoto.
Regarding claim 1, GlobalPlatform discloses a procedure for initiating a secure communication session between a card (SD, p. 22, Fig. 4-1) and a host (OCE, p. 22, Fig. 4-1), a static encryption key being assigned to the card and stored in the card (Key-ENC is available to the card for creating static Secure Channel keys (p. 28, §5.2), each of the card and the host providing a key version number (OCE selects Key Version Number, p. 21, §4.2 and Security Domain uses Keyset Version Number to generate session keys, p. 21, §4.2) and a key identifier of said static key (static keys are stored with Key Version Number and Key Identifier, p. 46, §7.4, table 7-11), the procedure comprising steps at the card: receive, from the host, an INITIALIZE UPDATE command comprising a host challenge (INITIALIZE UPDATE comprises Host Challenge, p. 22, Fig. 4-1), which is a value unique to the session (Host Challenge is random data unique to this Secure Channel Session, p. 21); generate a card challenge (Security Domain, on receipt of this challenge, generates its Card Challenge, p. 21), which is a value unique to the session (Card Challenge is random data unique to this Secure Channel Session, p. 21), herein processing at least the card’s static encryption key (Card Challenge is calculated with Static Key Key-ENC, p. 30, §6.1.1), key diversification data (key diversification data is returned to the OCE/host, p. 22, §4.3; see also p. 43) and a sequence counter (Card Challenge is calculated with a sequence counter, p. 30, §6.1.1) with a first cryptographic function (Card Challenge is calculated using the Data Derivation Protocol Function with the Static Key Key-ENC and the Derivation Constant set to “card challenge generation”, p. 30, §6.1.1); generate a session key (S-ENC) (Session keys S-ENC, S-MAC generated every time a Secure Channel is initiated and are used in the mutual authentication process; encryption key S-ENC is derived from Key-ENC, p. 28, §5.2; S-MAC is derived from Key-MAC, p. 28, §5.2), herein processing the card’s static encryption key (Key-ENC, p. 28, §5.2), the host challenge and the card challenge with a second cryptographic function (inputs to the key derivation includes the concatenation of the Host Challenge and the Card Challenge, p. 28, §5.2; uses Data Derivation scheme defined in Section 3.2.1, p. 28, §5.2); calculate a card cryptogram using the session key (S-ENC) (S-MAC; Card Cryptogram is calculated using the Data Derivation Protocol Function using the session MAC key, p. 30, §6.1.2); send to the host an INITIALIZE UPDATE reply in which the card cryptogram, the sequence counter and the card challenge are comprised (Card Cryptogram, sequence number and Card Challenge are returned to OCE, p. 22, §4.3), to enable the host to verify the card cryptogram (OCE verifies Card Cryptogram, p. 21, §4.2, p. 23, ¶1; ), wherein: to generate the card challenge, in addition said key version number and said key identifier are processed with the first cryptographic function (Card Challenge is calculated using the Data Derivation Protocol Function with the Static Key Key-ENC and the Derivation Constant set to “card challenge generation”, and the input data set to the concatenation of the sequence counter and the AID of the application invoking the SecureChannel interface, p. 30, §6.1.1, where Static Key-ENC is referenced by version number, p. 21, §4.2 “and the static keys indicated by the Keyset Version Number provided by the OCE”), the INITIALIZE UPDATE command doesn’t comprise said key identifier (p. 42, §7.2, Table 7-3). GlobalPlatform lacks wherein: each of the card and the host provide of an SCP key identity associated with said key version number and said key identifier of the card’s static encryption key; the INITIALIZE UPDATE command comprises the SCP key identity, and doesn’t comprise said key version number and said key identifier. However, Naoto, in an analogous art (GlobalPlatform card specification, ¶2), teaches the GlobalPlatform SCP utilizing a host that generates a random number (host challenge) and sends an INITIALIZE UPDATE command to a card, the command including the host challenge and key version information (sometimes called the "key version number"), which is a value indicating the key version (¶9). Naoto further teaches that it was known for each host (¶9) and SD card (¶14; see also ¶¶38-41) to store multiple key versions, where default key versions are set together with logical channel numbers that identify them, and when an INITIALIZE UPDATE command containing "0x00" (SCP key Identity) as the key version number is received, secure processing is performed using the key of the default key version identified by the logical channel number that corresponds to the established communication path (logical channel) (¶41). Naoto teaches that, by setting logical channel numbers according to how different default key versions are used, multiple default key versions can be used without explicitly specifying the key version number in the INITIALIZE UPDATE command (¶41). In a similar scenario, Naoto further teaches a default key table associating an AID (Application ID) that identifies an application with a default key (key version number, where the default key table is referenced by the SD when it receives an INITIALIZE UPDATE command containing "0x00" as the key version number from external device 2, and the SD selects a key corresponding to the default key (key version number) corresponding to the application to which the command is sent (¶43, ¶¶50-51; see also ¶44 describing setting the AID corresponding to the key). Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify GlobalPlatform to utilize 0x00 in place of the key version number in the INITIALIZE UPDATE message, such that each of the card and the host provide of an SCP key identity associated with said key version number and said key identifier of the card’s static encryption key (0x00 value, referencing default key); the INITIALIZE UPDATE command comprises the SCP key identity, and doesn’t comprise said key version number (INITIALIZE UPDATE command comprises 0x00 in place of key version number). One of ordinary skill in the art would have been motivated to perform such a modification to implicitly specify the correct static key by using a known substitution, as was taught as an alternative to explicitly specifying the key in Naoto.
Regarding claim 2, GlobalPlatform, as modified, teaches wherein the SCP key identity (0x00, per Naoto ¶41) is comprised in a data field of said INITIALIZE UPDATE command (0x00 is received in key version number field of INITIALIZE UPDATE command, as modified by Naoto ¶41).
Regarding claim 3, GlobalPlatform, as modified, teaches wherein: the field P1 of said INITIALIZE UPDATE command comprises, instead of a key version number, a fixed value (0x00 is received in key version number field of INITIALIZE UPDATE command, as modified by Naoto ¶41), but lacks particularly 0xFF. However, a skilled artisan would have found it obvious to utilize a different value, such as 0xFF to reference the use of the default key table of Naoto, as the value itself does not affect the procedure followed in Naoto. Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to further modify GlobalPlatform such that the field P1 comprises 0xFF. One of ordinary skill in the art would have been motivated to perform such a modification to indicate to the Security Domain/card that a default static key should be used, as taught by Naoto.
Regarding claim 4, GlobalPlatform disclose wherein the card comprises a card application (p. 22, applications use services of the Security Domain; see also p. 7, §.1.1, disclosing SCP between on-card and off-card applications)1, and wherein the session is initiated between the card application and the host (application invokes the SecureChannel interface, p. 30, §6.1.1, third bullet), and wherein: to generate the card challenge, in addition an application identifier, AID, of the card application is processed with the first cryptographic function (Card Challenge is calculated using the Data Derivation Protocol Function with the Static Key Key-ENC and the Derivation Constant set to “card challenge generation”, and the input data set to the concatenation of the sequence counter and the AID of the application invoking the SecureChannel interface, p. 30, §6.1.1, where Static Key-ENC is referenced by version number, p. 21, §4.2 “and the static keys indicated by the Keyset Version Number provided by the OCE”).
Regarding claim 5, GlobalPlatform discloses wherein each of the card and the host provides some or all of the following security parameters: Security parameter tag (authentication tag, p. 37, §6.9.2); length (for key derivation, a key length is utilized, p. 15, §3.2.1.2; p. 28, length of session key as a parameter, §5.2.1; length of challenges, p. 30, §6.1.1, third bullet); length of SCP key identity; SCP key identity (0x00 value, as modified by Naoto); length of key version and/or key identifier; key version and/or key identifier (static keys are stored with Key Version Number and Key Identifier, p. 46, §7.4, table 7-11). Further, while not explicitly stated as a parameter, a skilled artisan would have understood that the length of SCP key identity and length of key version and/or key identifier would be known to a party storing such values.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
“YubiKey 5 Series Technical Manual” (Yubico) teaches an Initialize Update command comprising a Transport Key set identifier (SCP key identity, p. 35, §9.6, step 1; relevant to “the INITIALIZE UPDATE command comprises the SCP key identity, and doesn’t comprise said key version number and said key identifier”), selecting a Transport Key set in memory based on the identifier and deriving session keys for Encryption and MAC using the selected Transport Key set (p. 35, §9.6, step 2). Yubico further teaches that each key set is identified by the key version defined when the set is imported into the YubiKey and that each individual key also has an id, but that serves solely to identify the specific key within the set - ENC, MAC or DEK (p. 55, §14.2). Yubico teaches that session keys are all dynamically generated at the start of each session, using the Secure Channel Encryption and MAC Transport Keys, as well as the challenge sent from the client at the session start (p. 34, §9.5), but does not teach to generate the card challenge, in addition said key version number and said key identifier are processed with the first cryptographic function.
US 20240370547 A1 (GOUABAU; Frederic et al.) teaches an Initialize Update command (Fig. 3, 33) and a response (Fig. 2, 35), the Initialize Update command comprising a key version number KVN, where the card is populated with key data associated with a KVN and ICC identifier (¶¶77-78; see also ¶¶95-97 for authentication sequence).
US 6005942 A (Chan; Alfred et al.) teaches a key set identifier identifying a key set, where different key set identifiers are used to differentiate different key versions (col. 30, lines 34-65) and where the MAC is compute using the key and algorithm references identified in the Initialize Update response (col. 29, lines 25-31)
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL J SIMITOSKI whose telephone number is (571)272-3841. The examiner can normally be reached Monday - Friday, 7:00-3:00.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Carl Colin can be reached at 571-272-3862. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Michael Simitoski/ Primary Examiner, Art Unit 2493
December 22, 2025
1 This is interpretation is consistent with “GlobalPlatform Technology Card Specification Version 2.3.1” (March 2018), p. 75, §6.5.1.1, p. 76, §6.5.1.6 and p. 163, §11.3.3.1.3, table 11-30.