TurboCompliance

A submission to the NIST PEER competition by Nicholas LeBlanc

Summary

One of the greatest barriers to compliance with the Bayh-Dole regulations is complexity. While

the regulations may seem straightforward in theory, there are a host of complicating details in

practice. Tech transfer compliance administrators need help recalling, deciphering, and

navigating these finer details to maintain satisfactory levels of compliance. The solution I

propose here guides the institutional user through an online interface using conditional logic to

reduce the cognitive load & time costs of reporting, similar to the way TurboTax has streamlined

tax reporting for US citizens. It represents a novel solution to long-standing administrative

barriers to Bayh-Dole reporting and compliance.

Statement of Problem

Summaries of the Bayh-Dole reporting requirements can easily be found. Many law firms

working with institutions generating federally-funded IP have produced overviews of the

Bayh-Dole reporting obligations, and these are circulated within the tech transfer community.

However, there is a host of supplemental details not typically considered in these overviews,

and yet these details impact tech transfer offices’ ability to report. Here are several examples:

Grant number formats as provided in award documents are often rejected in iEdison. For

instance, the NSF frequently lists grant numbers in the format AB-1234567 in their grant

documentation, but iEdison accepts only the format AB1234567. iEdison will reject the

submission if the dash is included.

Educational grants are explicitly excluded from the Bayh-Dole requirements. But

identifying those grants is not easy: NSF grants stemming from their Graduate Research

Fellowships often begin with a specific prefix, and NIH training grants have an Activity

Code in the “T” series. This information is seldom communicated clearly to tech transfer

administrators.

Although the Air Force is listed as an iEdison agency, they have no legal authority to use

iEdison. Reports should still be submitted by email & forms DD 882. Many institutions

were misled by the Air Force’s presence in the iEdison system and were reporting solely

through iEdison, leading to non-compliance.

Aside from the details above, challenges also arise when doing compliance clean-up. Tech

Transfer offices are known for their relatively high turnover rates, which leads to interruptions in

accumulation and transmission of institutional knowledge among staff. Administrators often find

themselves entering missed data or fixing errors in incorrectly reported data from previous

years. These tasks require time & cognitive energy that administrators seldom have -- amid a

flurry of disparate duties, it is challenging to assess a complex compliance situation and remedy

the issues in the available time. I know from experience just how many hours Bayh-Dole

clean-up can consume, and much of that time is spent simply analyzing the case.

For example, a licensing officer may ask the compliance admin to waive a specific foreign filing
to the funding agency. Logging into iEdison, the staff member sees that the patent family had

not been reported, only the disclosure. Investigating further, they discover that there are several

disclosures listed on this patent family. A number of questions must be addressed to become

compliant:

● How does one manage patents with multiple disclosures in iEdison?

○ Are all the disclosures listed federally funded? What if not all disclosures have

the same sponsor?

○ How do you select which disclosure to be the parent?

● If the provisional is expired, should it be reported?

○ What if the government support clause on the provisional is incorrect?

● Should the expired PCT be reported?

○ What if the PCT’s government support clause is incorrect?

Unavoidably, doing the reporting required will take time. But simply figuring out which questions

to ask can take a significant amount of time, and time is in short supply among most compliance

admins.

What could be done to reduce the cognitive energy and time required to remediate compliance

situations like the one above, and to manage all the minute details of compliance procedure?

Proposed Solution

For an answer, I propose TurboCompliance, modeled after the popular TurboTax program (this

is a working name only; a better selection could be chosen in the future). TurboTax takes the

headache out of complying with the US tax code, which is more complex than the Bayh-Dole

regulations, by using a clean, web-based interface and conditional logic to guide the user

through preparing a tax return. TurboTax has shifted the burden of expertise and skill in

navigating the tax code from the individual to the algorithm powering the application. I propose a

similar algorithm to guide the compliance admin through the compliance process. The user

provides input in the form of information about the disclosure (date of disclosure, sponsor, grant

number), the algorithm provides the logic to determine which steps should be taken, and the

output is a list of recommended actions that constitute the best approach to becoming

compliant.

In an ideal scenario, TurboCompliance could be integrated into the new iEdison rebuild, so that

the user’s input could be turned into an actual iEdison report. But given that the iEdison rebuild

is well underway, it may not be feasible to integrate TurboCompliance with the new iEdison. In

that case, TurboCompliance would function as a guided tutorial that the user could complete

while performing the compliance steps (whether in iEdison or by filling out a form DD 882). No

longer must the compliance admin puzzle over what to do to remedy compliance issues.

Instead, they can rely on TurboCompliance to simplify the decision-making process and

produce a straightforward set of steps to execute with confidence.

I should note that the issues addressed by TurboCompliance are among the driving forces

behind AUTM’s annual compliance course. Tech transfer administrators recognize that there is

no formal training that covers these issues, and so they gather annually to train one another,

share best practices, and in many cases, try to divine the best way to approach thorny
scenarios. At the most recent 2020 compliance meeting, one participant explicitly asked for a

visual aid that would guide her through the decision-making process. One of the panelists

replied that she once made a printout 3-4 feet in length to try to map out her process, but the

tool wasn’t practical. This is precisely the need that TurboCompliance will fill.

TurboCompliance will merge agency requirements with institutional best practices. That is, the

system will combine input from the agencies and the regulations themselves with “on the

ground” recommendations from institutions.The latter can be obtained by a request for

information similar to the RFI issued prior to the redesign of iEdison. NIST could likewise consult

the leaders of the AUTM compliance group and solicit feedback during the annual AUTM

compliance course to build a system based on the prevailing consensus and best practices. To

date, no such system is available to compliance professionals.

Several concerns should now be addressed:

Is this solution practical / implementable?

Yes. If TurboTax can simplify the US federal & state tax codes into an easy-to-use interface

governed by conditional logic, then the much simpler Bayh-Dole regulations should also be

amenable to a similar solution.

How will TurboCompliance increase compliance?

Tech transfer administrators often struggle to find the time and energy to manage the minutiae

of compliance and compliance remediation. By greatly reducing those up-front “costs”,

compliance admins will be more likely and more able to report subject invention disclosures,

patents, and utilization reports. It’s like having an in-house compliance expert available to assist

you, without the additional personnel costs.

How would success be measured?

As with any solution, NIST could track the number of iEdison notification messages generated

on average per quarter (or year) for each institution before and after the release of

TurboCompliance. Results could also be aggregated for all registered iEdison institutions, or

aggregated by institution size.

Additionally, TurboCompliance would require a user account and identifying information about

each disclosure the system is used for. NIST could compare compliance (number of iEdison

notifications is a starting metric) for those disclosures against compliance on disclosures not

entered into TurboCompliance. A greater rate of compliance among disclosures using

TurboCompliance would gauge the level of the application’s success.

Below is a plain-English sample of steps that would be operationalized into code and a

web-based user interface. These steps represent an initial sketch and would be further

developed and refined based on RFI responses and discussion with AUTM members, and they

typify the information envisaged in the TurboCompliance application.

1. Funding agencies & grant numbers
a. Collect agency information

i. Provide comprehensive multiple-choice menu of federal funding agencies

1. Include “Other” option.

a. If only “Other” is selected, direct the user to contact the

agency directly. End the session.

b. Collect grant numbers.

i. The grant number field should be responsive to the agency selected -- the

field should automatically modify its format to reflect the agency selected.

OR Compare grant numbers against acceptable iEdison formats for each

agency. In cases of mismatch, provide the user with a list of accepted

formats.

ii. Provide instructions to the user for certain cases.

1. “T” series NIH grants:

2. NSF graduate fellowships: Instruct the user that this is a training

grant and likely not subject to Bayh-Dole.

2. Direct the user to the appropriate reporting method.

a. If iEdison agencies are listed among the agencies provided by the user, direct

them to the iEdison website and continue the session.

b. If non-iEdison agencies are provided, provide a link to the most current version of

the DD 882 form. Provide instructions to the user on how to fill out the form

(ideally a short video animation, but a simple list with screenshots would be

tremendously helpful).

c. If only non-iEdison agencies are provided, terminate the session.

3. Date Check:

a. Ask the user to enter the date of disclosure.

i. Give help text defining the date of disclosure. Provide information on

common practices from institutions regarding how this date is determined

(e.g., the “perfected disclosure” date used by most universities).

b. Ask the user to enter the bar date, if any.

i. Define the bar date and provide hints on determining it.

c. Ask the user to enter the grant date(s).

i. Provide instructions to enter the date of the last supplement awarded

before the invention was disclosed.

4. Indicate a “New Bayh-Dole” or “Old Bayh-Dole” value based on 3.c.

a. The following steps represent the “New Bayh-Dole” fork of the decision tree. A

comparable fork for “Old Bayh-Dole” would likewise be developed.

5. Elicit a status decision from the user.

a. Does the user wish to elect title now, waive now, or only report?

i. If “elect title”, provide both iEdison and DD 882 instructions, with graphics

/screenshots.

1. Perform a date comparison to determine if the user is still within

the window to elect title.

2. Has a patent application already been filed?

a. If so, instruct the user to elect title effective the day prior to

the patent application filing. Proceed to the patent reporting

steps.

b. If not, provide instructions regarding the filing deadlines

based on the data already entered (e.g., account for any
bar dates).

In sum, TurboCompliance would leverage the power of algorithms, conditional logic, and

compliance best practices to guide compliance professionals through the reporting process for

every federally-funded disclosure. Compliance professionals will be able to approach

compliance with greater confidence, less confusion, and with the assurance that they’re using

time efficiently. The full realization of this idea would require input from multiple stakeholders

and investment in software development, but would meet a long standing need in the tech

transfer community.