NXP USA, Inc.

B-417311: May 9, 2019

Additional Materials:

Contact:

Ralph O. White
(202) 512-8278
WhiteRO@gao.gov

Kenneth E. Patton
(202) 512-8205
PattonK@gao.gov

 

Office of Public Affairs
(202) 512-4800
youngc1@gao.gov

NXP USA, Inc., of Washington, D.C., protests the rejection of the proposals it submitted in response to request for proposals (RFP) No. 040ADV-18-R-0003, issued by the Government Publishing Office (GPO) for passport eCovers. NXP complains that the agency unreasonably evaluated its proposals as unacceptable.

We deny the protest.

DOCUMENT FOR PUBLIC RELEASE
The decision issued on the date below was subject to a GAO Protective Order. This redacted version has been approved for public release.

Decision

Matter of:  NXP USA, Inc.

File:  B-417311

Date:  May 9, 2019

Grant H. Willis, Esq., Cherie J. Owen, Esq., and Alexander M. Yabroff, Esq., Jones Day, for the protester.
Craig D. Barrett, Esq., Government Publishing Office, for the agency.
Mary G. Curcio, Esq., and Laura Eyester, Esq., Office of the General Counsel, GAO, participated in the preparation of the decision.

DIGEST

Agency reasonably eliminated proposals from consideration for award where proposals did not demonstrate that protester’s proposed approach met all solicitation

requirements. 

DECISION

NXP USA, Inc., of Washington, D.C., protests the rejection of the proposals it submitted in response to request for proposals (RFP) No. 040ADV-18-R-0003, issued by the Government Publishing Office (GPO) for passport eCovers.  NXP complains that the agency unreasonably evaluated its proposals as unacceptable.

We deny the protest.

BACKGROUND

The solicitation, issued by GPO on March 16, 2018, contemplated the award of multiple indefinite-delivery, indefinite-quantity contracts for passport eCovers.  Agency Report (AR), Tab 1, RFP, at 1-2.  The passport eCovers will be used to support the government’s effort to produce electronically enabled passports, known as ePassports.  RFP, Statement of Work (SOW), at 5.  The eCovers will contain an integrated circuit (IC or chip) with an antenna assembly embedded in the fabric cover.  Id.  GPO will provide the ePassports, with the eCovers, to the Department of State (State).  RFP, List of Attachments, attach. G, Random Unique Identifier (RUID) Requirements, at 2. 

As provided to State, the chip embedded in the eCover will contain no information except for a unique identifier (UID), which is a fixed number used for inventory management purposes.  Id.  State, however, will be able to input a passport holder’s personal data into the chip (i.e., personalization).  Id.  Once personalization is complete, the chip will be locked and activated.  Id.  Once the chip is locked and activated, an RUID will be activated.  Id.  RUIDs are required because there is a possibility the ePassport holder can be tracked using the UID, since it is a fixed number.  Id.  Therefore, each time the ePassport’s locked chip is accessed, it will present a different RUID.[1]  Id. at 3. 

The RFP provided for contracts for the eCovers to be awarded on a lowest-price, technically acceptable basis.  RFP, Evaluation Factors for Award, at 2.  The non-price evaluation factors were technical capability and past performance.  Id. at 3.  A proposal that failed to receive a pass for any evaluation factor or subfactor, or was insufficiently detailed or failed to meet any of the government’s requirements, would be deemed technically unacceptable and not considered for award.  Id. at 3-4. 

One evaluation subfactor, identification of technical compliance, stated that the government would review all proposals for compliance with the standards and requirements set forth in the RFP.  Id. at 4.  In this regard, as part of the technical proposal, offerors were required to submit a compliance matrix that listed 178 technical capability requirements that were detailed in the statement of work and attachments of the RFP.  AR, Tab 5, Compliance Matrix, at 49-86;[2] RFP, Instructions, at 14, 17.  Offerors were required to complete the compliance matrix by providing the proposal section, page, and line number identifying the location of the information that demonstrated compliance with each of the 178 requirements.  See AR, Tab 5, Compliance Matrix, at 49-86. 

As relevant to this protest, several of the compliance matrix line items concerned the chip that will be inserted into the passport eCover.  The solicitation established the following six requirements pertaining to the chip’s RUID, and designated them matrix line items 173 through 178:

173  The chip/integrated circuit (IC) RUID shall present a different UID each time the locked chip/IC is accessed.

174  To support inventory management needs, prior to locking the chip/IC, the UID shall be fixed.

175  The RUID function shall be activated when the chip/IC is personalized and locked.

176  In order to be considered random, the ePassport shall present an RUID that cannot be associated with UIDs used in sessions that precede or follow the current session.

177  Each chip/IC shall use its onboard hardware random number generator (RNG) module, thereby utilizing a true RNG base to derive an RUID.

178  The RUID solution shall not affect [International Organization for Standardization (ISO)] 14443 or ISO 7816 interoperability for Basic Access Control and Passive Authentication as referenced below . . . .

AR, Tab 5, Compliance Matrix, at 85-86. 

NXP submitted three proposals in response to the solicitation (each with a different partner or partners).  See AR, Tab 7, NXP Proposal 1, at 144; Tab 8, NXP Proposal 2, at 1077; Tab 9, NXP Proposal 3, at 1991.  GPO rejected all three proposals after assigning each a failing rating for compliance matrix line items 173-178.  AR, Tab 10, Consensus Evaluation Forms. 

After receiving a debriefing, NXP protested to our Office.

DISCUSSION

NXP challenges GPO’s evaluation and rejection of all three of its proposals.  In this regard, NXP argues that the agency’s evaluation of each proposal was inconsistent.  NXP also argues that its proposals demonstrated that all of the requirements in the compliance matrix were met.  We have considered all of NXP’s arguments and, although we address only a portion of the arguments below, we find that none provide a basis for sustaining the protest.

In reviewing protests challenging the rejection of a proposal for consideration for award, it is not our role to reevaluate proposals; rather our Office examines the record to determine whether the agency’s judgment was reasonable and in accordance with the solicitation criteria and applicable procurement statutes and regulations.  Wolverine Servs. LLC, B-409906.3, B-409906.5, Oct. 14, 2014, 2014 CPD ¶ 325 at 3.  Further, it is the offeror’s responsibility to submit a well-written proposal, with adequately detailed information which clearly demonstrates compliance with the solicitation and allows a meaningful review by the procuring agency.  CACI Techs., Inc., B-296946, Oct. 27, 2005, 2005 CPD ¶ 198 at 5.  A protester’s disagreement with the agency’s judgment does not establish that the evaluation was unreasonable.  WAI-Stoller Servs., LLC; Portage, Inc., B-408248.13 et al., May 29, 2015, 2015 CPD ¶ 201 at 7.  In a negotiated procurement, a proposal that fails to conform to the material terms and conditions of the solicitation is considered unacceptable and may not form the basis for award.  Wolverine Servs. LLC, supra.

Inconsistent Evaluation

NXP first complains that the agency’s evaluation of its proposals was inconsistent and therefore unreasonable.  Protest at 5.  The protester specifically asserts in this regard that the agency assigned its proposals a pass rating for matrix line items that included the same requirements in matrix line items 173-178 for which GPO assigned NXP’s proposals a fail rating.  Id.

The protester raises numerous examples of this allegedly inconsistent evaluation.  We do not address each of the protester’s examples.  For the most part, we find that the protester is attempting to use the protest process to re-write its proposal.  In this regard, as noted above, the solicitation specifically instructed offerors to identify, by section number, page number and line item, where in its proposal it demonstrated compliance with each matrix line item.  AR, Tab 5, Compliance Matrix, at 49-86.  Thus, offerors were on notice that the agency would determine whether the proposal demonstrated that the offeror could meet each compliance matrix line item based on the specific proposal reference provided by the protester for that line item.  The protester’s examples of an inconsistent evaluation, however, are situations in which the protester is arguing that the agency unreasonably evaluated one matrix line item as pass and another for the same requirement as fail, when the proposal references the protester included are different for each of the matrix line items. 

For example, NXP asserts that because GPO found its proposal acceptable for matrix line item 89, it was unreasonable for the agency to find that its proposal did not demonstrate compliance with matrix line item 178.  Protest at 6-7; Comments at 5.  GPO states that NXP failed to identify where in its proposals the evaluators could find the offeror’s response to the requirement for matrix line item 178, as required by the solicitation.  Memorandum of Law, Mar. 15, 2019, at 5-6. 

Matrix line item 89 of the RFP required offerors to demonstrate that the operating system will support ISO 7816[3] and ISO 14443.[4]  AR, Tab 5, Compliance Matrix, at 67.  In response, NXP referenced lines in section 2.4.10, IC Operating System, in the three proposals.  AR, Tab 7, NXP Proposal 1, at 212; Tab 8, NXP Proposal 2, at 1145; Tab 9, NXP Proposal 3, at 2065.  Section 2.4.10 in proposals 1 and 2 directed the evaluators to other sections of NXP’s proposals pertaining to the ePassport user manual and administrator guide, as well as the ePassport personalization guide.  See, e.g., AR, Tab 7, NXP Proposal 1, at 157.[5]  Section 2.4.10 of proposal 3 directed evaluators to portions of the eTravel Next Administration Manual and eTravel Next Personalization Manual located in another section of the proposal.  AR, Tab 9, NXP Proposal 3, at 2010.

Matrix line item 178 required offerors to demonstrate that “[t]he RUID solution shall not affect ISO 14443 or ISO 7816 interoperability for Basic Access Control and Passive Authentication as referenced” in documents pertaining to International Civil Aviation Organization (ICAO) 9303.[6]  AR, Tab 5, Compliance Matrix, at 86; RFP, List of Attachments, attach. F, Disable GET DATA Requirements, at 2.  In response, NXP referenced section 7.5, Testing Results.[7]  AR, Tab 7, NXP Proposal 1, at 221; Tab 9, NXP Proposal 3, at 2074.  More specifically, the referenced line of section 7.5 of the proposal stated that “[c]ompliance of the [DELETED] solution is tested according to ISO/[International Electrotechnical Commission (IEC)] 14443 and BSI-TR03110.”[8]  Id.  at 321; see Tab 9, NXP Proposal 3, at 2116 (providing only test results).

As indicated above, the protester did not reference the same sections of its proposal to demonstrate compliance with the requirements in matrix line items 89 and 178.  For matrix line item 89, NXP ultimately referred evaluators to a user manual and a personalization guide, while for matrix line item 178, NXP’s proposal referred evaluators to a proposal section on testing.  Compare AR, Tab 7, NXP Proposal 1, at 157 and 321; Tab 9, NXP Proposal 3, at 2010 and 2116.  An offeror has the burden of submitting an adequately written proposal, and runs the risk that its proposal will be evaluated unfavorably when it fails to do so.  The Arbinger Co.--Advisory Opinion, B-413156.21, Oct. 14, 2016, 2017 CPD ¶ 100 at 4-5.  Thus, even if the requirements were the same--an issue we need not reach--since the protester did not reference the same sections of its proposal for both matrix line items 89 and 178, there is no basis to find that the evaluation was inconsistent or unreasonable.[9]

Matrix Line Items 173-178

NXP next argues that the agency unreasonably evaluated its proposal as unacceptable for matrix items 173 through 178.  NXP contends that the proposal references it included for these matrix items demonstrate that NXP’s offered solution met the stated requirements.  Protest at 7.  As discussed below, we find that the agency reasonably concluded that the proposals submitted by NXP did not include a reference that demonstrated that the solutions proposed would meet the requirements of compliance matrix lines 174 and 178.  Since an offeror was required to meet all of the government’s requirements to be technically acceptable, RFP, Evaluation Factors for Award, at 3-4, and since NXP’s proposals were not acceptable for compliance items 174 and 178, the agency reasonably eliminated the proposals from consideration for award. 

Compliance matrix 174 required offerors to demonstrate the following:  “To support inventory management needs, prior to locking the chip/IC the UID shall be fixed.”  AR, Tab 5, Compliance Matrix, at 86.  In its compliance matrix, NXP lists section 2.4.3 (page 8, line 2) for all three proposals to demonstrate that it meets this requirement.  AR, Tab 7, NXP Proposal 1, at 221; Tab 8, NXP Proposal 2, at 1154; Tab 9, NXP Proposal 3, at 2074.[10]  Section 2.4.3 of the protester’s proposals further referenced sections 2.16 and 3.1 of the data sheet that NXP provided in section 7.11.1 of its proposal for the chip it is using.  AR, Tab 7, NXP Proposal 1, at 152; Tab 8, NXP Proposal 2, at 1086; Tab 9, NXP Proposal 3, at 2008.  Section 2.16 provides:

The optional [DELETED] is fully compatible with ISO/IEC 14443A.  [DELETED]  A true anti-collision method (according to ISO/IEC 14443-3) enables multiple cards to be handled simultaneously.  [DELETED].  A tutorial software library for ISO/IEC 14443-3 and ISO/IEC 14443-4 is available to support OS creators in easy integration of the [DELETED] into current system solutions.

AR, Tab 7, NXP Proposal 1, at 435; Tab 8, NXP Proposal 2, at 1306; Tab 9, NXP Proposal 3, at 2355.  Section 3.1 provides a list of features and benefits of the chip that NXP intends to use.  AR, Tab 7, NXP Proposal 1, at 440; Tab 8, NXP Proposal 2, at 1311; Tab 9, NXP Proposal 3, at 2355.  Neither of these sections discuss whether the UID is fixed before the chip is locked.  Further, to the extent these provisions indicate that the solution is fully compatible with ISO 14443A, neither section discussed ISO 14443A in the context of whether the UID is fixed before the chip is locked.  Since the agency asked for a specific reference showing that the matrix line item would be met, we have no reason to find the agency’s evaluation was unreasonable.[11] 

In addition, NXP argues that its proposals unambiguously satisfy the requirement stated in compliance matrix line items 178 that the RUID solution not affect ISO 14443, ISO 7816, or ICAO 9303 interoperability.  Protest at 10-11.  NXP contends that line item 178 effectively requires--and NXP’s proposal demonstrates--that its proposed solutions comply with ISO 14443, ISO 7816, and ICAO 9303.  Id. at 10.  In this regard, NXP asserts that its proposals explain that “[c]ompliance of the . . . solution is tested according to ISO/IEC 14443.”  Comments at 8 (quoting AR, Tab 7, NXP Proposal 1, at 321).  NXP also asserts that its proposals state that its solution is compliant with ISO/IEC 7816 and ISO/IEC 14443.  Id. (citing AR, Tab 7, NXP Proposal 1, at 901).

As noted above, compliance matrix line item 178 stated that “[t]he RUID solution shall not affect ISO 14443 or ISO 7816 interoperability for Basic Access Control and Passive Authentication as referenced” in ICAO 9303.  AR, Tab 5, Compliance Matrix, at 86.  NXP’s proposals stated in the compliance matrix that compliance with the requirement in matrix line item 178 is demonstrated at section 7.5, Testing Results.[12]  AR, Tab 7, NXP Proposal 1, at 221; Tab 8, NXP Proposal 2, at 1154; Tab 9, NXP Proposal 3, at 2074.  The relevant language in section 7.5 states that “Compliance of the . . . solution is tested according to ISO/IEC 14443.”  AR, Tab 7, NXP Proposal 1, at 321; Tab 8, NXP Proposal 2, at 1154;  see also Tab 9, NXP Proposal 3, at 2116 (providing only test results). 

While this language identified by compliance matrix line item 178 may be interpreted to mean that NXP’s RUID solution will be tested to ensure it does not affect ISO 14443 interoperability for basic access control and passive authentication, section 7.5 of the protester’s proposals does not address ISO 7816 or ICAO 9303.  See id.  The sections of NXP’s proposals that the protester identifies in its protest and comments as demonstrating compliance with ISO 7816 and ICAO 9303 were located in other sections of the protester’s proposals.  These sections of the proposal were not identified in the compliance matrix submitted to the agency with respect to matrix line item 178.  Compare e.g., AR, Tab 7, NXP Proposal 1, at 221 with id. at 901. 

In this regard, the government is not required to search throughout NXP’s proposal for information demonstrating compliance with specific requirements, where the solicitation instructed offerors to identify the location of the information.  See Dewberry Crawford Grp.; Partner 4 Recovery, B-415940.10 et al., July 2, 2018, 2018 CPD ¶ 297 at 13 (agency not required to search for information about protester’s quality control plan in other parts of the proposal).  Accordingly, we find no basis to conclude that the agency’s decision that NXP’s proposals did not demonstrate that NXP would meet the requirements of compliance matrix line item 178 was unreasonable.

The protest is denied. 

Thomas H. Armstrong
General Counsel



[1] A random number generator (RNG) is used to provide the RUID.  RFP, List of Attachments, attach. G, RUID Requirements, at 3.  An RNG is a program that generates a series of numbers at random such that each number is selected independently of any numbers in the series.  RFP, List of Attachments, attach. O, Glossary, at 9.

[2] With the exception of Tab 1 of the RFP, the agency report was submitted with Bates numbering.  Our citations to the agency report in this decision refer to the Bates numbers, as applicable.

[3]ISO 7816 is an international standard related to electronic identification cards accessed by contacts, close coupling, and/or radio frequency.  See https://www.iso.org/standard/54550.html (last visited May 2, 2019).

[4] ISO 14443 is an international standard related to proximity cards and security devices used for personal identification, as well as the transmission protocols for communicating with the devices.  See https://www.iso.org/standard/73596.html (last visited May 2, 2019).

[5] Although we have reviewed all of NXP’s proposals, because NXP states that proposals 1 and 2 are “virtually identical” with respect to the protested issues, Protest at 4, for simplicity our discussion will cite solely to proposal 1.

[6] ICAO 9303 provides specifications for machine readable travel documents.  See https://www.icao.int/publications/pages/publication.aspx?docnum=9303 (last visited May 2, 2019).

[7] More specifically, proposal 1 cited to section 7.5, page 87, line 2.  AR, Tab 7, NXP Proposal 1, at 221.  Proposal 3 cited to section 7.5, page 85, line 2.  AR, Tab 9, NXP Proposal 3, at 2074.

[8] BSI-TR03110 refers to British Standards Institute Technical Guideline TR-03110 “Advanced Security Mechanisms for Machine Readable Travel Documents – Extended Access Control (EAC).” 

[9] To the extent the agency assigned the protester’s proposals a pass rating for matrix line items that included the same requirements in matrix line items 173-178 for which GPO assigned NXP’s proposals a fail rating, as discussed below, NXP’s proposals nonetheless did not meet the requirements of matrix line item 174 and 178.  NXP is therefore ineligible for award in any case. 

[10] The protester asserts that its proposals show it will meet the requirement of compliance matrix item 174 because section 2.7.2 of its proposals state that the IC chips and eCovers are [DELETED] other than reading the ISO/IEC UID.  Protest at 8.  However, the protester did not reference section 2.7.2 of its proposals in its compliance matrices for item 174.  Thus, this argument does not provide a basis to find that the agency unreasonably evaluated the proposals. 

[11] We also note that the protester has not provided any information which demonstrates that because a solution complies with ISO 14443A, the UID will be fixed before the chip is locked.  It is the protester’s burden to demonstrate that its proposal is compliant with the solicitation requirements. 

[12] All three of NXP’s proposals referenced section 7.5, page 85 or 87, line 2 in response to matrix line item 178.  AR, Tab 7, NXP Proposal 1, at 221; Tab 8, NXP Proposal 2, at 1154; Tab 9, NXP Proposal 3, at 2074.

Jun 26, 2019

Jun 25, 2019

Jun 24, 2019

Jun 21, 2019

Jun 20, 2019

Looking for more? Browse all our products here