Effective Date: August 26, 1999

COORDINATED ISSUE
ALL INDUSTRIES
RESEARCH TAX CREDIT - INTERNAL USE SOFTWARE
UIL 41.51-10

ISSUE

Are X's activities related to the installation, customization, enhancement and

maintenance of a vendor-supplied software package excluded from the definition of
“qualified research” within the meaning of § 41(d)(1)1 of the Internal Revenue Code
because they fail to satisfy the three-part exception to the exclusion for internal use
software contained in the Conference Report to the Tax Reform Act of 1986 (the 1986
Act)?

CONCLUSION

X's activities related to the installation, customization, enhancement and maintenance

of a vendor-supplied software package may satisfy the three-part test for qualified
research under § 41(d)(1). X’s activities, however, do not satisfy the three-part
exception to the exclusion for internal use software contained in the Conference Report
to the 1986 Act and thus, are excluded from the definition of qualified research under
§ 41(d)(4)(E).

FACTS

X is a domestic, multi-regional corporation with net assets of $50,000,000. X currently

has 5,000 employees, including numerous computer professionals.

In 1989, X decided to upgrade a number of its administrative functions with the goal of
increasing corporate efficiency and reducing costs. X canvassed several software
development companies in search of an administrative software package that would
best satisfy X’s needs. After considering various software packages, X purchased from
Y corporation an on-line system that a number of X’s competitors used. The on-line
system X purchased included an extensive list of standard features and provided the
basic functionality that X needed.

1
Unless otherwise indicated, all section references are to the Internal Revenue Code of 1986.

Please note that the analysis of this paper's fact pattern is based upon the statute and the
legislative history and not upon the proposed regulations published in the Federal Register on January 2,
1997 (62 Fed. Reg. 81) and December 2, 1998 (63 Fed. Reg. 66,503). Although proposed regulations
do not have authoritative weight and should not be cited as authority, examiners may consider them in
reaching a determination. When the regulations become final, examiners must follow them, and this
paper will be revisited if it needs to be revised.
 -2-

X installed the Y software package in 1990. X continued to work on the Y system from
1990 through 1995. During this time, X’s work consisted of 40 projects which were
generally aimed at maintaining and customizing the Y system. These activities
included:

(1) Installing the Y system;

(2) Writing interface modules to connect the Y software with other

software at X;

(3) Converting data when X acquired a new subsidiary;

(4) Updating the Y system for regulatory changes;

(5) Installing new releases of the Y software;

(6) Testing to identify and correct bugs in the Y software to ensure

that it performed in accordance with specifications;

(7) “Retrofitting” with existing code new vendor code contained in new
releases of the Y software; and

(8) Customizing the Y software to meet specific needs of X, which

included modifying and/or adding screens and reports.

In order to complete the activities listed above, X spent approximately $75,000 per year
during the period 1990 through 1995, for a total of $450,000. X claimed the research
credit for the period 1990 through 1995 for the wages of its computer programmers and
analysts working on the Y system during this time.

The Y system reduced overall processing costs at X from $5.00 per account per month
to $1.00 per account per month. X represents that it was uncertain as to whether it
could effectively install, maintain and enhance the Y system so that it would meet X’s
needs and expectations. Specifically, X was uncertain as to (1) whether its
programmers could complete the tasks described above within the time and resource
constraints that X imposed; (2) whether X’s programmers and analysts had the requisite
ability to perform the software development tasks described above; and (3) whether the
programming tasks could be completed in X's computing environment (i.e., system
architecture).
 -3-

LAW

The research credit was originally enacted by the Economic Recovery Tax Act of 1981
(the 1981 Act) to provide an incentive to taxpayers to conduct certain types of product
development research activities and certain basic research. The definition of the term
“qualified research” was amended by the 1986 Act. Prior to amendment, the term
qualified research had the same meaning as the term “research or experimental” under
§ 174. The legislative history to the 1986 Act indicates that Congress believed that
taxpayers had applied the 1981 Act definition too broadly with some taxpayers claiming
the credit for virtually any expense relating to product development. Further, Congress
concluded that it was appropriate and desirable for the statutory research credit
provisions to include an express definition of the term “qualified research.” In 1986,
Congress narrowed the scope of the credit to technological advances in products and
processes, and revised and limited the definition of the term “qualified research” by
establishing additional qualifying requirements and adding several excluded activities.
S. Rep. No. 99-313, at 694-95 (1986); H.R. Rep. No. 99-426, at 178 (1985).

Section 41 allows taxpayers a credit against tax for increasing research activities.
Generally, the credit is an incremental credit equal to the sum of 20 percent of the
excess (if any) of the taxpayer's “qualified research expenses” for the taxable year over
the base amount, and 20 percent of the taxpayer's basic research payments. Under
§41(c)(4), however, taxpayers may elect to use the alternative incremental research
credit.

Section 41(b)(1) provides that the term “qualified research expenses” means the sum of
the following amounts which are paid or incurred by the taxpayer during the taxable
year in carrying on any trade or business of the taxpayer: (A) in-house research
expenses, and (B) contract research expenses.

Section 41(d)(1) provides that the term “qualified research” means research--

(A) with respect to which expenditures may be treated as expenses

under § 174,

(B) that is undertaken for the purpose of discovering information (i)

that is technological in nature, and (ii) the application of which is
intended to be useful in the development of a new or improved
business component of the taxpayer, and
(C) substantially all of the activities of which constitute elements of a
process of experimentation for a purpose described in § 41(d)(3).

Such term does not include any activity described in § 41(d)(4).

Section 41(d)(2)(A) provides that the tests for qualified research in § 41(d)(1) are to be
applied separately with respect to each business component of the taxpayer. Section
 -4-

41(d)(2)(B) provides that the term “business component” means any product, process,
computer software, technique, formula, or invention that is to be (i) held for sale, lease,
or license, or (ii) used by the taxpayer in a trade or business of the taxpayer.

Section 41(d)(3)(A) provides that, for purposes of § 41(d)(1)(C), research is to be

treated as conducted for a qualified purpose if it relates to (i) a new or improved
function, (ii) performance, or (iii) reliability or quality. Section 41(d)(3)(B) provides that
research is not to be treated as conducted for a qualified purpose if it relates to style,
taste, cosmetic, or seasonal design factors.

Section 41(d)(4) provides that the term “qualified research” does not include any of the
following: research after commercial production; adaptation of an existing business
component; duplication of an existing business component; surveys, studies, etc.;
research with respect to certain computer software; foreign research; research in the
social sciences, etc.; and funded research.

Section 41(d)(4)(E) provides that, except to the extent provided in regulations, qualified
research does not include any research with respect to computer software that is
developed by (or for the benefit of) the taxpayer primarily for internal use by the
taxpayer, other than for use in (i) an activity which constitutes qualified research
(determined with regard to this subparagraph), or (ii) a production process with respect
to which the requirements of § 41(d)(1) are met.

The legislative history to the 1986 Act indicates that Congress intended to limit the
credit for the costs of developing internal-use software to software meeting a high
threshold of innovation. The Conference Report provides:

Under a specific rule in the conference agreement, research with respect

to computer software that is developed by or for the benefit of the
taxpayer primarily for the taxpayer's own internal use is eligible for the
credit only if the software is used in (1) qualified research (other than the
development of the internal-use software itself) undertaken by the
taxpayer, or (2) a production process that meets the requirements for the
credit (e.g., where the taxpayer is developing robotics and software for the
robotics for use in operating a manufacturing process, and the taxpayer's
research costs of developing the robotics are eligible for the credit). Any
other research activities with respect to internal-use software are ineligible
for the credit except to the extent provided in Treasury regulations.
Accordingly, the costs of developing software are not eligible for the credit
where the software is used internally, for example, in general and
administrative functions (such as payroll, bookkeeping, or personnel
management) or in providing noncomputer services (such as accounting,
consulting, or banking services), except to the extent permitted by
Treasury regulations.
 -5-

The conferees intend that these regulations will make the costs of new or
improved internal-use software eligible for the credit only if the taxpayer
can establish, in addition to satisfying the general requirements for credit
eligibility, (1) that the software is innovative (as where the software results
in a reduction in cost, or improvement in speed, that is substantial and
economically significant); (2) that the software development involves
significant economic risk (as where the taxpayer commits substantial
resources to the development and also there is substantial uncertainty,
because of technical risk, that such resources would be recovered within
a reasonable period); and (3) that the software is not commercially
available for use by the taxpayer (as where the software cannot be
purchased, leased, or licensed and used for the intended purpose without
modifications that would satisfy the first two requirements just stated).
The conferees intend that these regulations are to apply as of the
effective date of the new specific rule relating to internal-use software; i.e.,
internal-use computer software costs that qualify under the three-part test
set forth in this paragraph are eligible for the research credit even if
incurred prior to issuance of such final regulations.

The specific rule in the conference agreement relating to internal-use

computer software is not intended to apply to the development costs of a
new or improved package of software and hardware developed together
by the taxpayer as a single product, of which the software is an integral
part, that is used directly by the taxpayer in providing technological
services in its trade or business to customers. For example, the specific
rule would not apply where a taxpayer develops together a new or
improved high technology medical or industrial instrument containing
software that processes and displays data received by the instrument, or
where a telecommunications company develops a package of new or
improved switching equipment plus software to operate the switches. In
these cases, eligibility for the incremental research tax credit is to be
determined by examining the combined hardware-software product as a
single product, and thus the specific rule applicable to internal-use
computer software would not apply to the combined hardware-software
product.

H.R. Conf. Rep. No. 99-841, at II-73-74 (1986). See Norwest v. Commissioner, 110
T.C. 454 (1998).

Under the rule in the Conference Report, Congress did not intend that the three-part
test in the legislative history would apply in lieu of the general requirements for credit
eligibility but, rather, intended that the general requirements for credit eligibility of §
41(d) also would have to be satisfied. See H.R. Conf. Rep. No. 99-841, at II-73. Thus,
the exclusion for internal use software and the exception to the exclusion for internal
use software operate to allow the otherwise qualified costs of developing internal use
 -6-

software to be eligible for the research credit only if the software meets a high threshold
of innovation. See Norwest Corp. v. Commissioner, 110 T.C. 454 (1998); United
Stationers, Inc. v. United States, 982 F. Supp. 1279 (N.D. Ill. 1997), aff’d, 163 F.3d 440
(7th Cir. 1998), cert. denied, 119 S. Ct. 2369 (1999).

The Conference Report also provides that Congress intended regulations incorporating
the three-part test in the legislative history as an exception to the exclusion for internal
use software from the definition of qualified research under § 41(d)(4)(E) would be
effective on the same date § 41(d)(4)(E) became effective. See H.R. Conf. Rep. No.
99-841, at II-73-74 (1986) and Notice 87-12, 1987-1 C.B. 432.

On January 2, 1997, the Service published in the Federal Register (62 Fed. Reg. 81)
proposed regulations under § 41 describing when computer software that is developed
by (or for the benefit of) a taxpayer primarily for the taxpayer's internal use can qualify
for the credit for increasing research activities. The proposed regulations follow the
legislative history to the 1986 Act and adopt the tests contained in the Conference
Report to the 1986 Act. H.R. Conf. Rep. No. 99-841, at II-73 (1986).

ANALYSIS

In order to qualify for the research credit under § 41, X must establish that its research
activities related to the installation, customization, enhancement and maintenance of a
vendor-supplied software package satisfy the definition of qualified research under §
41(d)(1) and that those activities satisfy the three-part exception to the exclusion for
internal use software contained in the Conference Report to the 1986 Act, and are not
otherwise excluded under § 41(d)(4). Assuming that X's research activities satisfy the
requirements for qualified research under § 41(d)(1), X next must establish that those
activities satisfy a higher threshold of innovation by showing that:

A. The software is innovative (the “innovativeness test”);

B. The software development involves significant economic risk (the

“significant economic risk test”); and

C. The software is not commercially available for use by the taxpayer

(the “commercial availability test”).

Because this coordinated issue paper addresses only the three-part exception to the
exclusion for internal use software contained in the Conference Report to the 1986 Act
and does not address the three-part test for qualified research under § 41(d)(1), an
assumption is made, solely for purposes of this paper, that the activities satisfy the
underlying requirements for qualified research in § 41(d)(1). The Service believes,
however, that some, if not all, of the activities would fail to satisfy the underlying
requirements for qualified research at § 41(d)(1). See Norwest v. Commissioner, 110
 -7-

T.C. 454 (1998). For a discussion of the three-part test for qualified research, please
refer to the coordinated issue paper for qualified research.

Before applying the three-part test for internal use software contained in the
Conference Report to the 1986 Act, however, it is necessary to determine if the
software at issue is "computer software that is developed by or for the benefit of the
taxpayer primarily for the taxpayer's own internal use.” Under the rule in the
Conference Report, internal use software includes software that is used internally for
general and administrative functions (such as payroll, bookkeeping, or personnel
management) or in providing noncomputer services (such as accounting, consulting, or
banking services) except to the extent permitted by Treasury regulations.” H.R. Conf.
Rep. No. 99-841, at II-73 (1986). See Norwest v. Commissioner, 110 T.C. 454 (1998).
Thus, software developed primarily for the taxpayer's internal use is treated as “internal
use software” even if the taxpayer intends to, or subsequently does, sell, lease, or
license the software. See United Stationers v. United States, 163 F.3d at 447
(suggesting a “totality of the circumstances” standard for determining whether software
projects are primarily for internal use).

Under the present facts, X acquired the Y software package for the purpose of
increasing corporate efficiency and reducing costs. The Y package was an on-line
administrative software package that included an extensive list of standard features and
provided the basic functionality that X needed. From 1990 through 1995, X undertook
40 projects which were aimed at generally maintaining and customizing the Y system.
Considering the “totality of the circumstances,” the description of the various projects
indicates that the Y software package was developed for use within the confines of X’s
business. Even if the Y package provided services that had a direct impact upon
customers, suppliers, and other third parties outside of X, X’s software development
activities related to the Y software package nevertheless remain within the scope of the
internal use software exclusion. See United Stationers, 163 F.3d 440 (7th Cir. 1998),
aff’g 982 F. Supp. 1279 (N.D. Ill. 1997). Therefore, X’s 40 projects related to the
installation, customization, enhancement and maintenance of the Y software package
are subject to the exclusion for internal use software contained in § 41(d)(4)(E).

A. The “Innovativeness Test”

In order to satisfy the “innovativeness test,” X must show that it attempted to develop
software that is innovative (as where the software results in a reduction in cost, or
improvement in speed, that is substantial and economically significant). In addressing
the “innovativeness test,” the Tax Court in Norwest determined that “the extent of the
improvements required by Congress with respect to internal use software is much
greater than that required in other fields.” Comparing the “innovativeness test” to the
“business component test” under § 41(d)(1), the Tax Court noted that the “business
component test” requires only a new or improved function, whereas the “innovativeness
test” requires change that is substantial and economically significant (emphasis added).
110 T.C. at 499. This is consistent with the “high threshold of innovation” for internal
 -8-

use software that Congress specified in the legislative history. H.R. Rep. No. 99-426, at
178 (1985); S. Rep. No. 99-313, at 694-95 (1986).

The requirement that the reduction in cost or improvement in speed must be substantial
focuses on the quantity of cost savings or the magnitude of the improvement in speed
that is attributable to the internal use software (and not the hardware). There is,
however, no bright line test for applying this requirement.

Under the present facts, X claims that the software it developed resulted in substantial
cost savings because the Y system reduced monthly processing costs by 80 percent
(i.e., processing costs went from $5.00 per account per month to $1.00). While a
bright-line test for substantial cost savings does not exist, X’s reduction in monthly
processing costs appears to be a substantial cost savings. Thus, X has satisfied this
aspect of the “innovativeness test.”

In addition, X must show that its development of the Y system resulted in cost savings
or improvements in speed that were not only substantial but also economically
significant. In general, this can be shown if the development of the software results in a
competitive advantage where the software provides cost savings and improvements in
speed relative to software performing similar functions elsewhere in the industry. See
Norwest, 110 T.C. at 516. For instance, a company may implement a software
package that is widely-used in the industry and may, as a result, enjoy substantial cost
savings or improvements in transaction processing speed. Under certain
circumstances, however, implementing a software package to reduce costs may not
necessarily be economically significant because the company may be simply reducing a
competitive disadvantage resulting from its current use of substandard software.
Further, any perceived cost savings or improvement in speed could be attributed solely
to the core package acquired from the vendor and not to any functional improvements
that X may have made.

X has not shown that the Y system resulted in any significant competitive benefits.
Rather, X was attempting simply to mitigate a competitive disadvantage arising from the
fact that many of X’s competitors had already successfully implemented the Y system
as of 1990. Although X may have realized substantial cost savings by reducing
processing costs and extending the life of the Y system through the end of 1995, this
did not provide X with a competitive advantage. See Norwest, 110 T.C. at 527 (finding
that extending the life of an outdated system is the sort of nonqualifying activity
Congress had in mind when it sought to narrow the definition of qualified research).
Accordingly, X has failed to establish that the software it developed provided
economically significant reductions in cost or improvements in speed.

Although X is unable to show that its development of the Y system resulted in an

economically significant reduction in cost or improvement in speed, X may still satisfy
the “innovativeness test” if it can show that its development of the Y system is, in fact,
innovative (that is, novel or unique). In light of the “high threshold of innovation”
 -9-

required for internal use software, X’s activities related to the development of the Y
system must be more innovative than activities that would merely satisfy the
requirements for qualified research under § 41(d)(1). The facts suggest that there was
nothing strikingly different, unusual, new or unique about X’s software development.

In summary, although X's modification of the Y system resulted in substantial cost

savings, these cost savings were not economically significant because X’s modification
of the Y system did not result in any significant competitive benefits or provide X with a
competitive advantage. Rather, X has merely shown that the Y system introduced to X
a functionality that, while new to X, was not new to the industry. Thus, X’s activities
related to the modification of the Y system are not the type of exceptional software
development activities that could be regarded as innovative. Accordingly, X's activities
do not meet the “innovativeness test.”

B. The “Significant Economic Risk Test”

In order to satisfy the “significant economic risk test,” X must show that its software
development activities involved significant economic risk (as where the taxpayer
commits substantial resources to the development and there is a substantial
uncertainty, because of technical risk, that such resources would be recovered within a
reasonable period). Comparing the “significant economic risk test” to the “process of
experimentation test” under § 41(d)(1), the Tax Court in Norwest noted that the
“process of experimentation test” requires only uncertainty, whereas the “significant
economic risk test” requires substantial uncertainty and thus, a higher threshold of
technological advancement in the development of internal use software than in other
fields. 110 T.C. at 500.

In determining if X committed substantial resources to the development of the Y

system, all facts and circumstances are considered, including but not limited to the
following:

(1) The amount X spent on the Y software projects as compared to

X's net assets;

(2) The number of hours X's computer programmers spent on the Y

software projects as compared to the number of hours X's
computer programmers spent on overall software development per
year;

(3) The amount X paid or budgeted for the Y software project as

compared to X's total annual information technology (IT) budget;

(4) The amount X paid or budgeted for the Y software project as

compared to the amount X paid or budgeted for all of its research
projects during the same period; and
 -10-

(5) The level of management approval, if any, X required under its

budgetary procedures before it committed funds to a software
project to the extent that the approval process defines X’s own
assessment of what X considers to be a substantial commitment of
resources.

In analyzing whether X committed substantial resources to the development of the Y

system, X must show that its installation, maintenance and customization activities on
the Y system for the period 1990 through 1995 represented a single research activity
(or, business component), to the extent all 40 projects relative to the Y system were
interrelated. Assuming it is one research activity, the combined cost of X's efforts on
the Y system during 1990 through 1995 must be examined to determine if X committed
substantial resources to this software development activity.

There is no bright-line test for determining if substantial resources have been

committed to developing software. Under these facts, X, a company with $50 million in
net assets, committed $75,000 a year for six years for a total economic outlay of
$450,000 for the development of the Y system. X’s expenditures on the Y system
represents less than 1 percent of X’s net assets. Accordingly, it does not appear that
the taxpayer committed substantial resources to the development of the Y system.

In order to satisfy the “significant economic risk test,” X must also show that there was
substantial uncertainty, because of technical risk, that the resources X expended would
be recovered within a reasonable period. Substantial uncertainty for purposes of the
“substantial economic risk test” is caused by technical risk, not business risk. Further,
whether or not X can complete its development activities within certain business-related
constraints (that is, on time and within budget) is a business risk, not a technical risk.

Technical risk arises when the solution, or method of arriving at the solution, is not
readily apparent to skilled and experienced programmers after they have analyzed the
problem using known software development techniques and parameters. X is expected
to possess information that is common knowledge, at the time of the development
activity, to professional software developers familiar with the area of technology in
question. The fact that X may not have a sufficiently qualified staff to complete the
programming effort does not give rise to technical risk. To the extent that technical risk
is evaluated objectively, the critical issue is therefore whether skilled and experienced
programmers in the field of computer science can complete the programming task.

Technical risk also arises when there is some question as to whether the software can
be developed, and not whether the software will produce the desired efficiency. See
United Stationers, 163 F.3d at 446, 448. For example, a software system’s design may
be premised upon the assumption that orders will be filled in the same order that they
are received. The possibility that this may not be the best way to satisfy customer
demand is a business risk. Conversely, the possibility that reasonably competent
 -11-

software developers cannot build a system that fills orders in the order they are
received is a technical risk.

The following factors are some of the factors that may be relevant for purposes of
determining if technical risk is the cause of substantial uncertainty that a company’s
commitment of resources to the development of a software system will not be
recovered within a reasonable period:

(1) What was the size and complexity of the programming task and the
project as a whole;

(2) Did the programming task use existing technologies and known
programming methods;

(3) Had similar programming tasks been completed before;

(4) Did the software system provide functionality not offered in any
other software;

(5) Did the company attempt to employ existing technology in a new

and dynamic way;

(6) Was the programming task successfully completed;

(7) If the project failed, was abandoned, or was significantly delayed,

did technical risks, as opposed to business-related risks,
contributed to this outcome; and

(8) Did the company consider and account for technical risk in deciding
to fund the software system development activities, and in
monitoring the progress of the development activities.

In applying the above factors to the present facts, X's development efforts do not
appear to satisfy the “significant economic risk test.” Specifically, X was uncertain if X’s
own programmers could complete the Y development project within the time and
resource constraints that X imposed. This uncertainty is a business-related risk.
Moreover, X’s own programmers successfully completed all development work on the Y
system using known techniques and existing technology.

Further, there is no indication under the present facts that X faced any specific technical
challenges. The vendor-acquired Y system was designed to be installed, modified and
maintained by the customer. X’s activities related to the installation, customization,
enhancement and maintenance of the Y system are very similar to the activities at issue
in Norwest, in which the Tax Court determined that such activities were routine software
development activities. Although X's computing environment (i.e., operating system
 -12-

software, applications and hardware) differs from that of other companies using the Y
system, this fact does not establish that undertaking the installation and maintenance of
the Y system involved technical risk. Also, the fact that X's programmers could not
precisely copy the efforts of other programmers because of differences in X's
computing environment is not sufficient evidence of technical risk.

Generally, expenses incurred in developing software cannot be recouped until the

software development has been completed and the software has been deployed.
Ascertaining what constitutes a “reasonable period” for the recoupment of expenses
incurred in developing software depends upon being able to predict, in the first
instance, the period of time needed to complete a software development project, or a
software development project completion date. If the technical risk associated with a
project creates substantial uncertainty as to when software development is likely to be
completed, then this aspect of the test is satisfied. In other words, technical risk must
be so great that it would prevent a reasonably competent software developer from
confidently predicting a completion date for a project. This requirement is an objective
standard. Thus, a reasonable period of time for the development of a software system
does not relate to self-imposed business time constraints, but rather to the reasonable
time of those in the field of computer science. Norwest, 110 T.C. at 528.

In light of the routine nature of the work performed on the Y system, it is unlikely that X
could not confidently predict a completion date for each aspect of this software
development. To the extent that X’s competitors successfully completed similar
development work, it is likely that X also would be able to develop this software.

In summary, X's software development activities for the Y software package did not
involve significant economic risk. There is no indication that X committed substantial
resources to the development of the Y system and there is no substantial uncertainty,
because of technical risk, that such resources would be recovered within a reasonable
period of time.

C. The “Commercial Availability Test”

In order to satisfy the “commercial availability test,” X must show that the software it
developed was not commercially available for use by X (as where the software cannot
be purchased, leased, or licensed and used for the intended purpose without
modifications that would satisfy the first two requirements of the three-part test
contained in the Conference Report. Because the software package X purchased and
modified was a commercially available administrative software system, the question for
purposes of applying the “commercial availability test” is whether X's modifications meet
the innovativeness and significant economic risk tests discussed above. Because the
modifications and enhancements X made to the Y software system during 1990 through
 -13-

1995 do not meet the “innovativeness test” and “significant economic risk test,” X's
modifications to the Y software system did not meet the “commercial availability test.”