IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`Eric J. Robb
`In re Patent of:
`6,936,611 Attorney Docket No.: 39907-0011IP1
`U.S. Patent No.:
`March 27, 2007
`
`Issue Date:
`Appl. Serial No.: 10/417,596
`
`Filing Date:
`Apr. 17, 2003
`
`Title:
`BARRIER MOVEMENT OPERATOR HUMAN
`INTERFACE METHOD AND APPARATUS
`
`
`
`DECLARATION OF DR. NATHANIEL J. DAVIS IV
`
`I, Dr. Nathaniel J. Davis IV, declare as follows:
`
`
`
`
`1.
`
`A summary of my background and qualifications as a technical expert
`
`for this IPR is provided below. A complete listing of my qualifications and
`
`background are detailed in my curriculum vitae, which is attached hereto as
`
`Exhibit B.
`
`2.
`
`I received a B.S. and an M.S. in Electrical Engineering from Virginia
`
`Polytechnic Institute and State University in 1976 and 1977, respectively. I
`
`received a Ph.D. in Electrical Engineering in 1985 from Purdue University.
`
`3.
`
`In December 2016, I retired from my position as Professor and
`
`Department Head in the Department of Electrical and Computer Engineering at the
`
`Air Force Institute of Technology (“AFIT”), Wright-Patterson Air Force Base in
`
`Ohio. Upon my retirement, I was appointed as a Professor Emeritus at AFIT. My
`
`responsibilities as Professor included teaching courses in the field of electrical and
`
`1
`
`CHAMBERLAIN 2006
`Techtronic v. Chamberlain
`IPR2017-00073
`
`

`

`computer engineering and conducting research in these areas. As Department
`
`Head, I was responsible for the academic and research direction as well as the
`
`administration of the 38-faculty department. In 2009, I received the Air Force
`
`Award for Meritorious Civilian Service for visionary improvements to my
`
`department’s organization, administration, and graduate degree curricula. I
`
`received the Air Force Civilian Career Service Award upon retirement.
`
`4.
`
`I serve as a consultant and researcher for nationally known companies
`
`and institutions. I am currently a Senior Member of the Institute of Electrical and
`
`Electronics Engineers (IEEE). I am also a member of the IEEE Computer Society.
`
`My research efforts at Virginia Tech (from 1989 to 2005) resulted in grants and
`
`equipment donations totaling in excess of $5 million. During my previous tenure
`
`as a professor at the Air Force Institute of Technology from 1985 to 1989, I
`
`worked on research projects totaling $2.8 million. These efforts focused on
`
`computer architecture, digital design, computer networks, and embedded
`
`microprocessors, (among others). Throughout my tenure as an electrical and
`
`computer engineering professor, I have taught undergraduate and graduate courses
`
`in these same subject areas.
`
`5.
`
`From 1981 to 1982, I was an Instructor in the Department of
`
`Electrical and Computer Engineering at the Air Force Institute of Technology,
`
`Wright-Patterson Air Force Base in Ohio. From April 1988 to December 1988 I
`
`2
`
`

`

`was an Adjunct Assistant Professor in the Department of Computer Science and
`
`Engineering at Wright State University, in Dayton, Ohio. From 1985 to 1989 I
`
`was an Assistant Professor in the Department of Electrical and Computer
`
`Engineering at the Air Force Institute of Technology, Wright-Patterson Air Force
`
`Base in Ohio, on tenure track to have been effective October 1, 1989. From 1989
`
`to 2005 I held the position of Associate Professor and then Professor (beginning in
`
`2002) in the Bradley Department of Electrical and Computer Engineering at
`
`Virginia Polytechnic Institute and State University, and from the Fall of 2000 to
`
`2004 held the position of Assistant Department Head. From 2005 to present I have
`
`held the position of Professor and Head of the Department of Electrical and
`
`Computer Engineering, Air Force Institute of Technology (as stated above).
`
`6.
`
`In 1987, I revised the technology assessment portion of the U.S.
`
`Army’s Joint Tactical Fusion Program Management Office’s Preplanned Product
`
`Improvement Implementation Plan. The topical areas in the technology
`
`assessment included: interconnection networks, parallel computer architectures,
`
`VLSI circuit design capabilities, application algorithm development, and mass
`
`storage devices. I have also worked on computer network design research and
`
`development projects for the Federal Bureau of Investigation, the Department of
`
`the Navy, and the Commonwealth of Virginia State Police (among others).
`
`3
`
`

`

`7.
`
`From 2010-2014, I was a member of the Air Force High Performance
`
`Computing Review Panel, tasked to evaluate proposals for use of Air Force and
`
`Department of Defense supercomputer resources (panel disbanded in 2015). In
`
`2007, I was a member of the Army Science and Technology Basic Research
`
`Review panel. Under the direction of the Director for Research and Laboratory
`
`Management for the Department of the Army, this panel reviewed all basic
`
`research projects being conducted by Army laboratories and recommended the
`
`continuance or termination of each project.
`
`8.
`
`From December 2011 to August 2012, I was a member of the Mission
`
`Support Panel for the Air Force Chief Scientist’s Cyber Vision 2025 Cyber S&T
`
`strategy team. This team, spanning all Air Force major commands and its research
`
`and development community, was instrumental in the development of education
`
`and training strategies and priorities for the next decade that will improve the cyber
`
`workforce and its operational capabilities within the Air Force.
`
`9.
`
`From January 2013 to May 2013, I also served on the Education and
`
`Training Team for the Air Force Chief Scientist’s Global Horizons Study. The
`
`purpose of the study was to identify, forecast, and capitalize on global trends in
`
`education and training that will impact the Air Force in the next decade.
`
`10.
`
`I am a program evaluator for electrical and computer engineering
`
`programs for ABET, Inc., the recognized accreditor for college and university
`
`4
`
`

`

`programs in applied science, computing, engineering, and technology. I was
`
`nominated for this position by my engineering professional society, the IEEE. As a
`
`program evaluator, I evaluate university programs in electrical or computer
`
`engineering and, on behalf of ABET, make determinations as to whether these
`
`programs meet the criteria for accreditation. Since 2007, I have completed
`
`assessment visits to 9 different universities.
`
`11.
`
`In January 2011, the US Patent and Trademark Office issued patent
`
`7,877,621, “Detecting software attacks by monitoring electric power consumption
`
`patterns,” for which I am a co-inventor. This patent describes detecting malicious
`
`attacks launched against a mobile computing device by monitoring the device’s
`
`power consumption for anomalous behavior.
`
`12.
`
`I have authored or co-authored over 70 technical articles in archival
`
`journals and conferences. I have co-authored two book chapters. The topics of my
`
`publications generally focused on computer systems to include computer
`
`architecture, to include embedded computer systems and input/output mechanisms;
`
`parallel processing computer systems; the performance of local area networks
`
`(LAN) and wide area networks (WAN); and computer and network security. In
`
`addition, I have provided expert witness testimony in cases involving embedded
`
`computer systems that are similar to the ones envisioned in the ’611 patent. While
`
`on the faculty at Virginia Tech, I led a team of graduate and undergraduate
`
`5
`
`

`

`students tasked to design the on-board flight computer for a microsatellite that was
`
`launched by NASA and used to measure the effects of atmospheric scintillation on
`
`radio communication. This work entailed the design of the computer control
`
`system as well as the input/output structures for the satellite - a much more
`
`complex system than what is employed in the barrier control mechanisms of the
`
`’611 patent.
`
`13. My more than 30 years of experience with computer hardware,
`
`architectures and networks in academic and practical situations as well as my
`
`hands on experience, has given me a detailed appreciation of the technology
`
`involved with the ’611 patent. In particular, I have experience with embedded
`
`microprocessors systems that has particularly prepared me to draw conclusions
`
`concerning the purported infringement of the ’611 patent.
`
`14.
`
`I am not currently and have not at any time in the past been an
`
`employee of The Chamberlain Group, Inc. I have been engaged in the present
`
`matter to provide my independent analysis of the issues raised in the petition for
`
`inter partes review of the ’611 patent. I received no compensation for this
`
`declaration beyond my normal hourly compensation based on my time actually
`
`spent studying the matter, and my compensation does not depend on the outcome
`
`of this inter partes review of the ’611 patent.
`
`6
`
`

`

`I. Materials Considered
`
`15.
`
`In writing this Declaration, I have considered the following: my own
`
`knowledge and experience, including my work experience in the fields of
`
`semiconductor device design and fabrication; my industry experience with those
`
`subjects; and my experience in working with others involved in those fields. I
`
`have also analyzed the following publications and materials, in addition to other
`
`materials I cite in my declaration:
`
`Exhibit No.
`1001
`1002
`1003
`1004
`
`1005
`
`1006
`
`1007
`2002
`2003
`2004
`
`
`
`Description
`U.S. Patent No. 7,196,611 (“the ’611 patent”)
`Patent Prosecution History of U.S. Patent No. 7,196,611
`Declaration of Stuart Lipoff
`U.S. Patent No. 6,184,641 to Crimmins with additional Exhibit A
`attached
`Moore-o-Matic Owner’s Manual for Chain-Drive Garage Door
`Operator Models XX325, XX333, and XX350 (“Moore-o-
`Matic”)
`LiftMaster Garage Door Owner’s Manual for Industrial Door
`Operator Models J, H, and HJ with Logic Control v. 2.0
`(“LiftMaster”)
`U.S. Patent Pub. No. 2002/0170685 to Weik et al. (“Weik”)
`Deposition Transcript of Stuart Lipoff
`Exhibits to Deposition Transcript of Stuart Lipoff
`Zilog Z8 User Manual
`
`7
`
`

`

`16. Although for the sake of brevity this Declaration refers to selected
`
`portions of the cited references, it should be understood that one of ordinary skill in
`
`the art would view the references cited herein in their entirety and in combination
`
`with other references cited herein or cited within the references themselves. The
`
`references used in this Declaration, therefore, should be viewed as being
`
`incorporated herein in their entirety.
`
`II.
`
`Person of Ordinary Skill in the Art
`17.
`I am familiar with the content of the ’611 patent, which, I have been
`
`informed by counsel, has an earliest possible filing date of Apr. 17, 2003 (the
`
`“Critical Date”). Additionally, I have reviewed the other references cited above in
`
`this declaration. Counsel has informed me that I should consider the prior art
`
`references through the lens of one of ordinary skill in the art related to the ’611
`
`patent at the time of the invention.
`
`18.
`
`In my opinion, a person of skill in the art pertaining to the ’611 patent
`
`would have had at least an undergraduate degree in computer or electrical
`
`engineering (or equivalent education) along with at least two years of industry
`
`experience working with embedded computer systems or related technologies
`
`involving microcontrollers. I note that superior education would compensate for a
`
`deficiency in work experience, and vice-versa.
`
`8
`
`

`

`III. The ’611 Patent
`
`19. The ’611 patent describes a novel barrier movement operator (e.g.,
`
`garage door opener) having a controller and a connected remote input/output unit
`
`that displays status of portions of the barrier movement operator, as well as faults
`
`identified in the barrier movement operator’s operation. ’611 patent at Abstract,
`
`2:41-3:67. The ability to detect status of the barrier movement operator and to
`
`identify faults in its operation, and to display both status and faults to users via the
`
`remote input/output unit, improves the barrier movement operator’s safety and
`
`convenience. See id. at 1:6-29, 2:41-3:67.
`
`20. Claim 1 of the ’611 patent recites:
`
`1. A barrier movement operator comprising:
`a controller, responsive to user input signals and
`operational signals for selectively energizing a motor to
`open and close a barrier;
`the
`to
`a remote
`input/output unit connected
`controller and remote therefrom for receiving user inputs
`and for displaying status of portions of the barrier
`movement operator;
`the controller for identifying faults in the operation
`of the barrier movement operator; and
`apparatus for communicating the identities of faults
`in the operation of the barrier movement operator to the
`
`9
`
`

`

`remote input/output unit and for displaying the identified
`faults at the remote input/output unit.
`
`IV. Claim Construction
`21.
`I understand that, for the purposes of my analysis in this matter, the
`
`claims of the ’611 Patent must be given their broadest reasonable interpretation
`
`consistent with the specification. Stated another way, it is contemplated that the
`
`claims are understood by their broadest reasonable interpretation except where
`
`construed in the specification. I also understand that this “broadest reasonable
`
`interpretation” is with respect to how one of ordinary skill in the art would
`
`interpret the claim language. I have followed these principles in my analysis. In a
`
`few instances, I have discussed my understanding of the claims in the relevant
`
`paragraphs below.
`
`V. Analysis
`A. Crimmins does not teach “communicating the identities of faults”
`22. Crimmins fails to teach “communicating the identities of faults” as
`
`recited in claim 1. Petitioner argues that this feature is met by Crimmins’
`
`“controller that is programmed to blink, flash, or turn on an LED on a wall unit to
`
`indicate various faults.” Petition, p. 47. As described below, the behavior of the
`
`LED described in Crimmins and interpreted by Petitioner’s expert does not
`
`“communicat[e] the identities” of the alleged faults because one could not discern
`
`10
`
`

`

`which fault occurred from the LED behavior. Thus, in my opinion, the Crimmins
`
`reference does not teach this feature.
`
`23. The Petition summarizes the LED behavior of Crimmins in a table on
`
`pages 43-44. See Petition, pp. 43-44. Each row of the table presents assembly
`
`code from Exhibit A in the left column, an alleged “fault” in the middle column,
`
`and a description of the alleged LED behavior in the right column, as shown in this
`
`example:
`
`Petition, p. 43 (annotated)
`
`
`
`24. This table lists five alleged faults. See id. at 43-44. Three of these
`
`faults are described as eliciting the same LED behavior (“LED On”). See id. at 44
`
`(last three rows of table with “LED On” in the right hand column). Because all
`
`three alleged faults are represented by the same LED behavior, it is not possible for
`
`a user to identify which of the three faults occurred based on that behavior. Thus,
`
`11
`
`

`

`with respect to these three alleged faults, Crimmins does not teach
`
`“communicating the identities of faults” as recited in the claim.
`
`25. The remaining two rows in the table describe the LED “blinking”
`
`every quarter of a second for an “Overflow Condition,” and the LED “flashing” for
`
`a “Service Cycle Has Expired” condition. These two rows are shown below:
`
`Petition, p. 43.
`
`
`
`26. The Petition states that “Crimmins’s controller enables the diagnostic
`
`LED to communicate fault conditions by flashing the LED at a specific rate (e.g.,
`
`one blink per 1/4 second) [or] flashing the LED.” Petition, p. 46. Petitioner and its
`
`expert incorrectly conclude that the LED behaviors for these two alleged faults
`
`must be different. However, a review of the assembly source code reveals that the
`
`“Service Cycle Has Expired” routine actually calls the same routine for flashing
`
`12
`
`

`

`the LED, i.e., the “Overflow Condition” routine, indicating that the LED behavior
`
`for both alleged faults is the same.
`
`27. Portions of a line of assembly source code after a semi-colon (“;”) are
`
`comments that do not affect the execution behavior of the code. These portions of
`
`the code have been omitted for the present analysis.
`
`28. The “Overflow Condition” routine includes the following lines of
`
`source code:
`
`29. The “Service Cycle Has Expired” routine includes the following lines
`
`
`
`of source code:
`
`30. The “Overflow Condition” routine includes a label (“OverFlow”)
`
`
`
`indicated below:
`
`31. This label allows other portions of the code to “jump” to this routine
`
`during execution using an instruction called “Jump Relative” or “JR.” See Zilog
`
`
`
`13
`
`

`

`Manual, p 197. The “JR” instruction is provided with a condition code and a label
`
`to which to jump. If the condition indicated by the condition code is true, the “JR”
`
`instruction jumps to the line in the assembly program denoted by the specified
`
`label, and execution continues from that line. See Zilog Manual, p 197.
`
`32. As shown below, the “Service Cycle Has Expired” routine includes a
`
`“JR” instruction that will cause a jump to the label for the “Overflow Condition”
`
`routine:
`
`
`
`33.
`
`In this routine, the first line (“CP ServiceFlash,#0FFH”) compares in
`
`the “ServiceFlash” register to the hexadecimal value “FF” (255 in decimal). See
`
`Zilog Manual, p 177 (definition of “CP” instruction). The second line (“JR EQ,
`
`OverFlow”) jumps to the label “OverFlow” if the previous compare instruction
`
`indicated that the two values were equal. See Zilog Manual, p 197.
`
`34. Accordingly, the “Service Cycle Has Expired” routine simply
`
`performs a conditional jump to the “Overflow Condition” routine, indicating that
`
`the “Overflow Condition” routine will be executed for both alleged faults. See
`
`also Lipoff Transcript, 67:20-68:2 (Question: “Does that line call the Overflow
`
`routine?” Lipoff: “It would seem to, yes.”). Because the assembly code controls
`
`14
`
`

`

`the LED behavior, a POSITA would understand that executing the same assembly
`
`code for two alleged faults means that the LED behavior for those two alleged
`
`faults will be the same. If the LED behavior is the same for both faults, there is no
`
`way to discern which fault has occurred based on the behavior. Thus, with respect
`
`to these two remaining alleged faults, Crimmins does not teach “communicating
`
`the identities of faults” as recited in the claim.
`
`35. Therefore, in my opinion, Crimmins, at most, teaches that the LED
`
`exhibits one behavior (“LED on”) in response to a first set of alleged faults
`
`(“System Error,” “Button Debounce,” and “Most Significant Byte Over Run”), and
`
`another behavior (“LED flashing”) in response to a second set of alleged faults
`
`(“Service Cycle Has Expired” and “Overflow Condition”). These two LED
`
`behaviors thus indicate, at most, that an alleged fault from either the first set or the
`
`second set of alleged faults has occurred. However, the described LED behaviors
`
`do not indicate a specific one of the alleged faults within the set that has occurred.
`
`Thus, the LED behavior of Crimmins does not disclose “communicating the
`
`identities of faults” as recited in claim 1.
`
`B. Crimmins does not describe that the controller pulses the LED a
`number of times corresponding to an error code
`36. Petitioner states that “a PHOSITA would have understood that
`
`Crimmins discloses the same structure because Crimmins’s controller will pulse
`
`the LED a number of times corresponding to an error code.” Petition, p. 47. The
`
`15
`
`

`

`Petition cites to the table on pages 43 and 44 to support this conclusion. Id.
`
`However, this table does not say anything about an error code, or a particular
`
`number of times that the LED is pulsed corresponding to the error code. See id.;
`
`The only LED behaviors described in the table are “LED On,” “LED Blinking
`
`Every 1/4 Second,” and “LED Flashing.” See Petition, pp. 43-44. None of these
`
`behaviors relates to the number of times the LED is pulsed. See id.
`
`37. Petitioner does not cite to any specific portion of the Crimmins
`
`reference or to any other evidence to support its conclusion that “Crimmins’s
`
`controller will pulse the LED a number of times corresponding to an error code,”
`
`and a review of Crimmins reference did not reveal any such functionality described
`
`therein. Accordingly, in my opinion, Crimmins does not teach that the controller
`
`“will pulse the LED a number of times corresponding to an error code.”
`
`C. The proposed combination of Crimmins and Weik does not teach
`a “display apparatus at the remote input/output unit on which the error
`codes from the controller can be displayed”
`38.
`In its analysis of claim 8, the Petition states that “Crimmins discloses
`
`this display apparatus by disclosing an LED on a wallmounted control unit that
`
`blinks, flashes, or is switched on to display various faults,” and thus concludes that
`
`Crimmins and Weik render claim 8 obvious. Petition, p. 74. Accordingly,
`
`Petitioner relies only on Crimmins as teaching claim 8.
`
`16
`
`

`

`39. Crimmins' single LED does not teach a “display apparatus at the
`
`remote input/output unit on which the error codes from the controller can be
`
`displayed.” As described above, the single LED described in Crimmins cannot
`
`communicate the identities of the alleged faults. Further, as also previously
`
`discussed above, neither the Petitioner nor its expert cite to any supporting
`
`evidence for the conclusion that a “PHOSITA would have understood that ...
`
`Crimmins’s controller will pulse the LED a number of times corresponding to an
`
`error code." Petition, p. 47 (emphasis added).
`
`40. Accordingly, in my opinion, the proposed combination of Crimmins
`
`and Weik does not teach “display apparatus at the remote input/output unit on
`
`which the error codes from the controller can be displayed” as recited in claim 8 of
`
`the ’611 patent.
`
`VI. Legal Principles
`A.
`41.
`
`Anticipation
`I have been informed that a patent claim is invalid as anticipated
`
`under 35 U.S.C. § 102 if each and every element of a claim, as properly construed,
`
`is found either explicitly or inherently in a single prior art reference. Under the
`
`principles of inherency, if the prior art necessarily functions in accordance with, or
`
`includes the claimed limitations, it anticipates.
`
`17
`
`

`

`42.
`
`I have been informed that a claim is invalid under 35 U.S.C. § 102(a)
`
`if the claimed invention was known or used by others in the U.S., or was patented
`
`or published anywhere, before the applicant’s invention. I further have been
`
`informed that a claim is invalid under 35 U.S.C. § 102(b) if the invention was
`
`patented or published anywhere, or was in public use, on sale, or offered for sale in
`
`this country, more than one year prior to the filing date of the patent application
`
`(effective filing date). And a claim is invalid, as I have been informed, under 35
`
`U.S.C. § 102(e), if an invention described by that claim was described in a U.S.
`
`patent granted on an application for a patent by another that was filed in the U.S.
`
`before the date of invention for such a claim.
`
`B. Obviousness
`I have been informed that a patent claim is invalid as “obvious” under
`
`43.
`
`35 U.S.C. § 103 in light of one or more prior art references if it would have been
`
`obvious to a POSITA, taking into account (1) the scope and content of the prior art,
`
`(2) the differences between the prior art and the claims, (3) the level of ordinary
`
`skill in the art, and (4) any so called “secondary considerations” of non-
`
`obviousness, which include: (i) “long felt need” for the claimed invention, (ii)
`
`commercial success attributable to the claimed invention, (iii) unexpected results
`
`of the claimed invention, and (iv) “copying” of the claimed invention by others.
`
`For purposes of my analysis above and because I know of no indication from the
`
`18
`
`

`

`patent owner or others to the contrary, I have applied a date of August 13, 1996, as
`
`the date of invention in my obviousness analyses, although in many cases the same
`
`analysis would hold true even at an earlier time than August 13, 1996.
`
`44.
`
`I have been informed that a claim can be obvious in light of a single
`
`prior art reference or multiple prior art references. To be obvious in light of a
`
`single prior art reference or multiple prior art references, there must be a reason to
`
`modify the single prior art reference, or combine two or more references, in order
`
`to achieve the claimed invention. This reason may come from a teaching,
`
`suggestion, or motivation to combine, or may come from the reference or
`
`references themselves, the knowledge or “common sense” of one skilled in the art,
`
`or from the nature of the problem to be solved, and may be explicit or implicit
`
`from the prior art as a whole. I have been informed that the combination of
`
`familiar elements according to known methods is likely to be obvious when it does
`
`no more than yield predictable results. I also understand it is improper to rely on
`
`hindsight in making the obviousness determination.
`
`
`
`19
`
`

`

`VII. ADDITIONAL REMARKS
`
`I currently hold the opinions expressed in this declaration. But my analysis
`
`may continue, and I may acquire additional information and/or attain supplemental
`
`insights that may result in added observations which could modify my opinions.
`
`I hereby declare that all statements made of my own knowledge are true and
`
`that all statements made on information and belief are believed to be true. I further
`
`declare that these statements were made with the knowledge that willful false
`
`statements and the like so made are punishable by fine or imprisonment, or both,
`
`under Section 1001 of the Title 18 of the United States Code and that such willful
`
`false statements may jeopardize the validity of the application or any patents issued
`
`thereon.
`
`
`
`Dated:
`
`
`
`
`
`
`8/2/2017
`
`
`
`
`
`
`
`
`
`By:
`
`
`
`
`
`
`
`______________________
`Dr. Nathaniel J. Davis IV
`
`
`20
`
`

`

` 
` 
` 
` 
` 
` 
` 
` 
`
`EXHIBIT B 
`
`EXHIBIT B
`
`21
`
`21
`
`

`

`Curriculum Vitae
`
`Nathaniel J. Davis IV, Ph.D.
`4515 South State Route 202
`Tipp City, Ohio 45371
`
`
`
`
`
`
`Biographical Information
`
`
`College Level Education
`
`Ph.D. (Electrical Engineering), 1985, Purdue University, West Lafayette, Indiana. Period attended:
`1982-1985.
`
`M.S. (Electrical Engineering), 1977, Virginia Polytechnic Institute and State University, Blacksburg,
`Virginia. Period attended: 1976-1977.
`
`B.S. (Electrical Engineering), 1976, Virginia Polytechnic Institute and State University, Blacksburg,
`Virginia. Period attended: 1972-1976.
`
`
`
`Academic Employment
`
`January 2017 – Present:
`Appointed as Professor Emeritus upon retirement from Federal civil service, Department of Electrical
`and Computer Engineering, Air Force Institute of Technology, Wright-Patterson AFB, Ohio.
`
`August 2005 – December 2016:
`Professor and Head, Department of Electrical and Computer Engineering, Air Force Institute of
`Technology, Wright-Patterson AFB, Ohio. Responsible for the academic and research direction as well
`as the administration of the 38-faculty department.
`
`August 1989 – August 2005:
`Professor, Bradley Department of Electrical Engineering, Virginia Polytechnic Institute and State
`University, Blacksburg, Virginia. Tenure granted in 1995. Promoted to Professor in 2002.
` Assistant Department Head 2000 – 2004. Responsible for the academic programs within the
`department and the department’s 850 undergraduate and 600 graduate students. These
`responsibilities
`included program assessment activities
`(ABET), course
`scheduling
`(approximately 300 course sections per year), instructor assignments, supervision and guidance
`of the department’s graduate and undergraduate counselors, resolution of admissions review
`disputes, and resolution of student complaints.
`
`
`
`22
`
`

`

`September 1985 - August 1989:
`Assistant Professor, Department of Electrical and Computer Engineering, Air Force Institute of
`Technology, Wright-Patterson Air Force Base, Ohio. Selected for promotion to the rank of Associate
`Professor (with tenure), to have been effective October 1, 1989.
`
`April 1988 - December 1988:
`Adjunct Assistant Professor, Department of Computer Science and Engineering, Wright State University,
`Dayton, Ohio.
`
`March 1981 - July 1982:
`Instructor, Department of Electrical and Computer Engineering, Air Force Institute of Technology,
`Wright-Patterson Air Force Base, Ohio.
`
`
`
`Professional Non-Academic Employment Experience
`
`August 1989 – February 2000:
`Lieutenant Colonel, U. S. Army Reserve Individual Mobilization Augmentation Program; assigned to the
`CECOM Night Vision and Electro-optics Laboratory, Fort Belvoir Virginia as a Research and
`Development Coordinator. During annual two-week summer training periods, assisted in the
`development of land mine training simulators compatible with other MILES simulators, provided a
`critical assessment of the next-generation soldier environmental support system, led the development of
`neural network parallel computer systems for land mine detection and classification, and provided
`technical support for humanitarian demining operations. Transferred to the Retired Reserve in February
`2000.
`
`June 1977 - August 1989:
`Commissioned Officer in the United States Army Signal Corps. Attained the rank of Major. In addition
`to the academic experience noted above, active duty assignments included:
`
`
`August 1982 - August 1985:
`Doctoral student, Purdue University. Attended school under an Army fellowship program.
`
`
`
`June 1977 - June 1980:
`Assigned to the XVIII Corps (Airborne), Fort Bragg, North Carolina as a communications-
`electronics officer. Directed the employment of a 65-soldier communications platoon. Led
`efforts in the planning, the installation, and the operation of UHF and microwave communication
`systems for ten company and battalion field training exercises. Provided direct administrative
`assistance to the Commander, 35th Signal Brigade (Corps) (Airborne), a 3,000-soldier tactical
`Signal Corps brigade.
`
`
`June 1976 - May 1977:
`Master's Degree student and Graduate Teaching Assistant, Virginia Polytechnic Institute and State
`University, Blacksburg, Virginia.
`
`
`
`
`2
`
`23
`
`

`

`Scholarly Activities
`
`
`Teaching Experience
`
` I
`
` have taught a wide-range of electrical and computer engineering courses. The focus of these courses
`has been on the design and use of computer systems. In each of these courses, major subsystems of a
`computer's architecture were explored and design alternatives were investigated. Sophomore-level
`courses provided a broad-based introduction to the computer engineering field while the more advanced
`courses dealt with state-of-the-art and emerging computer architectures, to include computer architecture,
`high-performance uniprocessors, massively parallel processing systems, computers embedded within
`larger systems, distributed computing systems, and computer-communications networks.
`
`
`Thesis, Dissertation, and Project Advising:
`
`Undergraduate Research Projects:
`
`Alexander Kourakas
`Project title: “Using the MC68HC11 Microcontroller.” Completed as part of the Engineering
`Fundamentals course EF 1006, Introduction to Engineering, Spring 1994 semester.
`
`Elvin L. Taylor, Jr.
`Project title: “Design of a Queueing Model Based on an FDDI Network.” Completed under the National
`Science Foundation Research Experience for Undergraduates program while attending Virginia Tech
`during the 1993 summer sessions. Mr. Taylor was a rising senior at the time of the project. He later
`completed his MS program at Virginia Tech as a recipient of an NSF graduate fellowship.
`
`Project title: “Design and construction of two micro satellites to be launched as part of the space
`shuttle’s hitchhiker program.” This independent study research project supported a team of 4-8
`undergraduate students during the Spring 99 – Spring 01 semesters. The goal of the project was to
`specify and design the on-board flight computer for HokieSat, a USAF/NASA-sponsored microsatellite
`constructed in the Aerospace and Ocean Engineering Department.
`
`Theresa Nelson and Almohanad Fayez
`Project title: “Laboratory Development for ENGE 1104, Exploring the Digital Future.” This project was
`done in the Summer 2004 semesters and was supported in part by an NSF curriculum development grant.
`The project focused on the development of course material for ENGE 1104. ENGE 1104 w